commit da3165ece5d7784c9d970f9573f164ee767f607d Author: Alexandre Frade Date: Mon Aug 10 00:14:17 2026 +0000 Linux 6.18.44-rt-xanmod1 Signed-off-by: Alexandre Frade commit 3a2180dd4bbec79d6a27f5a5eb4f1f36b1254d42 Merge: 93ee63dfc0db ad6ed82a8a85 Author: Alexandre Frade Date: Mon Aug 10 00:13:03 2026 +0000 Merge branch '6.18' into 6.18-rt commit ad6ed82a8a85341df05e6fba817ff56a4cdaf4cf Author: Alexandre Frade Date: Mon Aug 10 00:10:43 2026 +0000 Linux 6.18.44-xanmod1 Signed-off-by: Alexandre Frade commit 3412e4a7152c2841c39636c0992176a043bdf883 Merge: 054f69ce6232 1efe5d048a39 Author: Alexandre Frade Date: Mon Aug 10 00:08:12 2026 +0000 Merge tag 'v6.18.44' into 6.18 This is the 6.18.44 stable release commit 1efe5d048a391de3ead2804b2e7f86376c356cc5 Author: Greg Kroah-Hartman Date: Sun Aug 9 20:25:30 2026 +0200 Linux 6.18.44 Link: https://lore.kernel.org/r/20260807143424.272339768@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Wentao Guan Tested-by: Shuah Khan Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Miguel Ojeda Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 358b5dcf1fd7f7e627d8d6fa3e6690a4b20562c7 Author: Thomas Zimmermann Date: Tue Apr 21 09:29:05 2026 +0200 drm/tegra: fbdev: Do not assign to struct drm_fb_helper.info commit d23bd83f3e47a928e783c0d6a004737519dc77dc upstream. That field already contains the value being assigned. No need to do this twice. Signed-off-by: Thomas Zimmermann Fixes: 63c971af4036 ("drm/fb-helper: Allocate and release fb_info in single place") Cc: linux-tegra@vger.kernel.org Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260421073646.144712-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit e7731507270c2c63f00cfbf210fe96b964e9b42e Author: Bart Van Assche Date: Fri Apr 3 13:53:54 2026 -0700 drm/fb-helper: Fix a locking bug in an error path commit bd64240dc88caaf7b96dd869f36f165f51b52039 upstream. The name of the function __drm_fb_helper_initial_config_and_unlock() and also the comment above that function make it clear that all code paths in this function should unlock fb_helper->lock before returning. Add a mutex_unlock() call in the only code path where it is missing. This has been detected by the Clang thread-safety analyzer. Cc: Thomas Zimmermann Cc: Christian König # radeon Cc: Dmitry Baryshkov # msm Cc: Javier Martinez Canillas Fixes: 63c971af4036 ("drm/fb-helper: Allocate and release fb_info in single place") Signed-off-by: Bart Van Assche Signed-off-by: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Link: https://patch.msgid.link/20260403205355.1181984-1-bvanassche@acm.org Signed-off-by: Greg Kroah-Hartman commit 7bc7af179916bd4964179d03fdd41e4aa46b7143 Author: Andrei Kuchynski Date: Fri Jul 17 10:46:14 2026 +0000 usb: typec: ucsi: Correct teardown ordering in ucsi_init() error path commit fb0bf289f5d529336ef490c8273e88a8a8b29f69 upstream. The commit 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") consolidated port teardown into the ucsi_unregister_port() helper. However, it introduced an ordering problem in the ucsi_init() error path. Fix this by ensuring ucsi_unregister_port() is called before we unregister their corresponding lockdep keys. Cc: stable@vger.kernel.org Fixes: 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") Reported-by: "Borah, Chaitanya Kumar" Closes: https://lore.kernel.org/all/22064276-6c56-411a-9f20-6917ceeb865f@intel.com/ Signed-off-by: Andrei Kuchynski Tested-by: Chaitanya Kumar Borah Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260717104614.325250-1-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 10be509fa8fd95d1e47d40d1f68b0b26dfe9d572 Author: Oliver Hartkopp Date: Fri Aug 7 09:52:11 2026 +0200 can: isotp: fix timer drain order, wakeup handling and tx_gen ordering commit 050f010f920da17c1044a4f174766ad553e770b6 upstream. This patch is a follow-up to commit cf070fe33bfb ("can: isotp: serialize TX state transitions under so->rx_lock") which addresses following sashiko-bot findings: - isotp_sendmsg(): drain so->txfrtimer first so a stale callback can't re-arm echotimer after the claim - isotp_release(): wake so->wait after forcing ISOTP_SHUTDOWN so a sleeping sendmsg() claim isn't stranded - isotp_sendmsg(): have both wait_event_interruptible() calls in isotp_sendmsg() also wake on ISOTP_SHUTDOWN and do not return claim to IDLE to avoid corrupting a concurrent isotp_release() process. - isotp_sendmsg(): handle potential claim of a new transfer when the wait_event_interruptible() call returns in CAN_ISOTP_WAIT_TX_DONE mode. Don't touch timers and states of the new transfer if a new thread incremented so->tx_gen before getting the lock at err_event_drop. - isotp_sendmsg(): handle a stuck can_send() and omit timer and state changes if a new transfer was claimed. wait_tx_done() returns the error recorded in so->tx_result[], tagged with the caller's own generation. - isotp_tx_timeout(): on a claimed timeout, record the ECOMM error for the timed-out transfer's own generation in so->tx_result[]; sk->sk_err is raised unconditionally, same as every other error path here. - isotp_tx_gen_done()/isotp_tx_timeout(): always read tx.state (acquire) before tx_gen - the reverse order let a weakly ordered CPU pair a fresh tx.state with a stale tx_gen/tx_result slot. - isotp_sendmsg(): wait_tx_done: drain sk_err via sock_error() once we have read the result from so->tx_result[], so an already-reported error doesn't stay latched for a later poll()/SO_ERROR. Also align the remaining lock-free so->tx.state/rx.state/cfecho accesses and use skb->hash as unique loopback echo frame indicator. Fixes: cf070fe33bfb ("can: isotp: serialize TX state transitions under so->rx_lock") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260724181525.43556-1-socketcan@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Signed-off-by: Greg Kroah-Hartman commit 0902f06a6c0bbc1e4a08899d327eedc3fda4261d Author: Oliver Hartkopp Date: Fri Aug 7 09:52:10 2026 +0200 can: use skb hash instead of private variable in headroom commit d4fb6514ff8ed6912a71294e6b66a5d59ee88007 upstream. The can_skb_priv::skbcnt variable is used to identify CAN skbs in the RX path analogue to the skb->hash. As the skb hash is not filled in CAN skbs move the private skbcnt value to skb->hash and set skb->sw_hash accordingly. The skb->hash is a value used for RPS to identify skbs. Use it as intended. Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260201-can_skb_ext-v8-1-3635d790fe8b@hartkopp.net Signed-off-by: Paolo Abeni Signed-off-by: Oliver Hartkopp Signed-off-by: Greg Kroah-Hartman commit 157b1e3384d7d37f59c0c2b2ff2af8f557db1daa Author: Zongyao Bai Date: Sat Aug 1 21:49:15 2026 -0400 drm/xe/pt: Reset current_op in xe_pt_update_ops_init() [ Upstream commit 6384271ac1ac0099198d15df79212a19ebdb929d ] xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op->bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vger.kernel.org Fixes: e8babb280b5e ("drm/xe: Convert multiple bind ops into single job") Suggested-by: Matthew Auld Cc: stable@vger.kernel.org Assisted-by: GitHub-Copilot:claude-sonnet-4.6 Signed-off-by: Zongyao Bai Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260714232433.2737533-1-zongyao.bai@intel.com (cherry picked from commit 046045543e530605c441063535e7dca0075369a6) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b1a71151317c4682342bcaf543fc85d03cddcd9f Author: Oak Zeng Date: Sat Aug 1 21:49:14 2026 -0400 drm/xe: Add page reclamation info to device info [ Upstream commit 9b1a0e0a15c97987fdf56a615f3d13995bafd042 ] Starting from Xe3p, HW adds a feature assisting range based page reclamation. Introduce a bit in device info to indicate whether device has such capability. Signed-off-by: Oak Zeng Signed-off-by: Brian Nguyen Reviewed-by: Shuicheng Lin Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20251212213225.3564537-15-brian3.nguyen@intel.com Stable-dep-of: 6384271ac1ac ("drm/xe/pt: Reset current_op in xe_pt_update_ops_init()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6107b64cfccef21c48922bbd2d057c5482b2d8bb Author: Matthew Brost Date: Sat Aug 1 21:49:13 2026 -0400 drm/xe: Stub out new pagefault layer [ Upstream commit 620a09fb0bddf387f418663478b48ca4ba62b6d6 ] Stub out the new page fault layer and add kernel documentation. This is intended as a replacement for the GT page fault layer, enabling multiple producers to hook into a shared page fault consumer interface. v2: - Fix kernel doc typo (checkpatch) - Remove comment around GT (Stuart) - Add explaination around reclaim (Francois) - Add comment around u8 vs enum (Francois) - Include engine instance (Stuart) v3: - Fix XE_PAGEFAULT_TYPE_ATOMIC_ACCESS_VIOLATION kernel doc (Stuart) Signed-off-by: Matthew Brost Reviewed-by: Lucas De Marchi Tested-by: Francois Dugast Link: https://patch.msgid.link/20251031165416.2871503-2-matthew.brost@intel.com Stable-dep-of: 6384271ac1ac ("drm/xe/pt: Reset current_op in xe_pt_update_ops_init()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 184de3d31f72845edde39ef20cf3a48290248088 Author: Matthew Brost Date: Sat Aug 1 21:49:12 2026 -0400 drm/xe: Use SVM range helpers in PT layer [ Upstream commit 9ea9b45701ab50049a722450abc28346d1121e6e ] We have helpers SVM range start, end, and size. Use them in the PT layer rather than directly looking at the struct. Signed-off-by: Matthew Brost Reviewed-by: Himal Prasad Ghimiray Link: https://lore.kernel.org/r/20251022230122.922382-1-matthew.brost@intel.com Stable-dep-of: 6384271ac1ac ("drm/xe/pt: Reset current_op in xe_pt_update_ops_init()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit df1582c0a101e2e2f133dd331d2a3258bb6a7518 Author: Jani Nikula Date: Sat Aug 1 20:07:04 2026 -0400 drm/i915/vrr: require valid min/max vfreq for VRR [ Upstream commit f8a9262c7a6fc2de9802e14b0228114f0333869e ] Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo Fixes: 117cd09ba528 ("drm/i915/display/dp: Compute VRR state in atomic_check") Cc: stable@vger.kernel.org # v5.12+ Cc: Ankit Nautiyal Reviewed-by: Ankit Nautiyal Link: https://patch.msgid.link/20260625131040.1051272-1-jani.nikula@intel.com Signed-off-by: Jani Nikula (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 894d4a7395662059d2c6009fd17e1598af06405e Author: Ville Syrjälä Date: Sat Aug 1 20:07:03 2026 -0400 drm/i915/vrr: Check HAS_VRR() first in intel_vrr_is_capable() [ Upstream commit 4b274b0b61ab2a529e5c22e9aa033f3028e639fc ] There's no point in doing all the other checks in intel_vrr_is_capable() if the platform doesn't support VRR at all Check HAS_VRR() before wasting time on the other checks. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20251020185038.4272-23-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal Stable-dep-of: f8a9262c7a6f ("drm/i915/vrr: require valid min/max vfreq for VRR") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 21976fe5258494ac38b63d103be81bf1180ae4ae Author: Matthew Brost Date: Sat Aug 1 12:59:13 2026 -0400 drm/xe: Wait on external BO kernel fences in exec IOCTL [ Upstream commit af80e2bfde9312c76b60cf9274248dce0410b30d ] Before arming a user job, xe_exec_ioctl() only added the VM's dma-resv KERNEL slot as a dependency. That slot covers rebinds and the kernel operations of the VM's private BOs, but not external BOs (bo->vm == NULL), which carry their kernel operations (evictions, moves, ...) in their own dma-resv KERNEL slot. The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for memory management operations that must complete before the BO or its backing store may be used: any accessor is required to wait on the KERNEL fences before touching the resv. By skipping the external BOs' KERNEL slots, the exec path violated that contract and could schedule a user job while a kernel operation on an external BO mapped by the VM was still in flight, racing against it and potentially reading or writing memory that was being moved. Replace the VM-only dependency with an iteration over every object locked by the exec, adding each object's KERNEL slot as a job dependency. This covers the VM resv (rebinds and private BOs) as well as every external BO, mirroring the drm_gpuvm_resv_add_fence() call that later publishes the job fence to the same set of objects. Long-running mode continues to skip this, as before. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Matthew Brost Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20260702215805.4011228-1-matthew.brost@intel.com (cherry picked from commit a6b842acf3ddd1efc53a56de9260cfa718fb35e7) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b8ad916ba4e18e428693ffd89ae66ac9754b5558 Author: Thomas Hellström Date: Sat Aug 1 12:59:12 2026 -0400 drm/exec: Remove the index parameter from drm_exec_for_each_locked_obj[_reverse] [ Upstream commit ce44b78512e9102aea54ff6b6e521d6c8de9f31c ] Nobody makes any use of it. Possible internal future users can instead use the _index variable. External users shouldn't use it since the array it's pointing into is internal drm_exec state. v2: - Use a unique id for the loop variable (Christian) Assisted-by: GitHub Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström Reviewed-by: Christian König Link: https://patch.msgid.link/20260520101616.41284-2-thomas.hellstrom@linux.intel.com Stable-dep-of: af80e2bfde93 ("drm/xe: Wait on external BO kernel fences in exec IOCTL") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d256dac008d1d9e6378aa1a5454e89a8292d174c Author: Himal Prasad Ghimiray Date: Sat Aug 1 10:03:59 2026 -0400 drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC [ Upstream commit 7bc597ce74bab4153b2009c92eccf889e9d74044 ] When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO's tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference Reported-by: Martin Hodo Fixes: c1bb69a2e8e2 ("drm/xe/svm: Consult madvise preferred location in prefetch") Cc: Matthew Brost Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost Link: https://patchwork.freedesktop.org/patch/msgid/20260624174943.2808767-2-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8fa8b0a4637299090f764f372c4a15463786314a Author: Arvind Yadav Date: Sat Aug 1 10:03:58 2026 -0400 drm/xe/vm: Prevent binding of purged buffer objects [ Upstream commit 4f44961eab8474a47de419113e1d46095f9b44e0 ] Add purge checking to vma_lock_and_validate() to block new mapping operations on purged BOs while allowing cleanup operations to proceed. Purged BOs have their backing pages freed by the kernel. New mapping operations (MAP, PREFETCH, REMAP) must be rejected with -EINVAL to prevent GPU access to invalid memory. Cleanup operations (UNMAP) must be allowed so applications can release resources after detecting purge via the retained field. REMAP operations require mixed handling - reject new prev/next VMAs if the BO is purged, but allow the unmap portion to proceed for cleanup. The check_purged flag in struct xe_vma_lock_and_validate_flags distinguishes between these cases: true for new mappings (must reject), false for cleanup (allow). Cc: Himal Prasad Ghimiray Cc: Matthew Brost Reviewed-by: Thomas Hellström Signed-off-by: Arvind Yadav Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260326130843.3545241-6-arvind.yadav@intel.com Stable-dep-of: 7bc597ce74ba ("drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1ba553ee0b521c035f02ca8f125dea16b9d6abef Author: Arvind Yadav Date: Sat Aug 1 10:03:57 2026 -0400 drm/xe/bo: Add purgeable bo state tracking and field madv to xe_bo [ Upstream commit b67427f939ccf038a658badb02dd948c7b516248 ] Add infrastructure for tracking purgeable state of buffer objects. This includes: Introduce enum xe_madv_purgeable_state with three states: - XE_MADV_PURGEABLE_WILLNEED (0): BO is needed and should not be purged. This is the default state for all BOs. - XE_MADV_PURGEABLE_DONTNEED (1): BO is not currently needed and can be purged by the kernel under memory pressure to reclaim resources. Only non-shared BOs can be marked as DONTNEED. - XE_MADV_PURGEABLE_PURGED (2): BO has been purged by the kernel. Accessing a purged BO results in error. Follows i915 semantics where once purged, the BO remains permanently invalid ("once purged, always purged"). Add madv_purgeable field to struct xe_bo for state tracking of purgeable state across concurrent access paths Cc: Thomas Hellström Cc: Himal Prasad Ghimiray Reviewed-by: Matthew Brost Signed-off-by: Arvind Yadav Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260326130843.3545241-3-arvind.yadav@intel.com Stable-dep-of: 7bc597ce74ba ("drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0015b054b06d38442050e43682a40742a96291e8 Author: Nitin Gote Date: Sat Aug 1 10:03:56 2026 -0400 drm/xe: add xe_migrate_resolve wrapper and is_vram_resolve support [ Upstream commit be97fd06458d66a53aefb6d9429db0df734c81c0 ] Introduce an internal __xe_migrate_copy(..., is_vram_resolve) path and expose a small wrapper xe_migrate_resolve() that calls it with is_vram_resolve=true. For resolve/decompression operations we must ensure the copy code uses the compression PAT index when appropriate; this change centralizes that behavior and allows callers to schedule a resolve (decompress) operation via the migrate API. v3: Fix kernel-doc warnings v2: (Matt) - Simplify xe_migrate_resolve(), use single BO/resource; remove copy_only_ccs argument as it's always false. Cc: Matthew Brost Cc: Matthew Auld Reviewed-by: Matthew Brost Signed-off-by: Nitin Gote Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260304123758.3050386-7-nitin.r.gote@intel.com Stable-dep-of: 7bc597ce74ba ("drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 005b9b44316063564a83d6a3911b8ff67b3ed308 Author: Xin Wang Date: Sat Aug 1 10:03:55 2026 -0400 drm/xe/pat: Add helper to query compression enable status [ Upstream commit b2bce0e551e89af37cfcb1b1158d80f369eeea3f ] Add xe_pat_index_get_comp_en() helper function to check whether compression is enabled for a given PAT index by extracting the XE2_COMP_EN bit from the PAT table entry. There are no current users, however there are multiple in-flight series which will all use this helper. CC: Nitin Gote CC: Sanjay Yadav CC: Matt Roper Suggested-by: Matthew Auld Signed-off-by: Xin Wang Reviewed-by: Matt Roper Reviewed-by: Nitin Gote Reviewed-by: Matthew Auld Reviewed-by: Sanjay Yadav Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20251110221458.1864507-2-x.wang@intel.com Stable-dep-of: 7bc597ce74ba ("drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3cb42a973f889f13204f220612eb0be89f90a661 Author: Leo Li Date: Wed Aug 5 12:33:14 2026 -0400 drm/amd/display: Exit idle optimizations before programming [ Upstream commit 8419331e64d92a8de5fc4feef0e305f201fb8b33 ] [Why] We need to exit PSR/IPS before programming. Before calling DC for programming in amdgpu_dm_commit_planes(), there's a vblank_control_workqueue flush. This waits for IPS and PSR exit. (See drm_vblank_on/off() > amdgpu_dm_crtc_set_vblank() --queue_work()-> amdgpu_dm_crtc_vblank_control_worker()) Prior to the tagged "Fixes:" change, drm_vblank_get() was called before the workqueue flush. This ordering ensures that PSR exit occurred before programming. After the "Fixes:" change, drm_vblank_get() is called after the workqueue flush, leading to programming while idle optimizations are still active. This can lead to incorrect flip_pending detection used by vblank event delivery. [How] Split the vblank_get() component of `dm_arm_vblank_event()` into `dm_arm_vblank_event_pre_programming()`, which is called before programming. Call it before the vblank_control_workqueue flush. Includes a drive-by cleanup of prepare_flip_isr(): the only caller is dm_arm_vblank_event() and it's simple enough to roll-in. v2: Fix checkpatch formatting warning on drm_arm_vblank_event_pre_programming() arg alignment. Fixes: 48ab86360af1 ("drm/amd/display: check GRPH_FLIP status before sending event") Cc: stable@vger.kernel.org Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4141#note_3583205 Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/5527 Assisted-by: Codex:gpt-5.6-sol Assisted-by: Claude:opus-5 Suggested-by: David Weber Signed-off-by: Leo Li Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Alex Deucher (cherry picked from commit 05984e29520a28c27f5a2388742c957a6a87ee7a) (cherry picked from commit 8419331e64d92a8de5fc4feef0e305f201fb8b33) Signed-off-by: Sasha Levin commit dbbe08d73b8bcedf0eb8bacb4b3c43b09c92c032 Author: Leo Li Date: Wed Jul 29 13:57:48 2026 -0400 drm/amd/display: check GRPH_FLIP status before sending event [ Upstream commit 48ab86360af117123eb1b15e38f068acf3826400 ] [Why] After unifying DCN interrupt sources under VUPDATE_NO_LOCK, we have two remaining issues to clean up: 1. On DCN, flip completion is now delivered from VUPDATE_NO_LOCK (dm_crtc_high_irq_handler) instead of GRPH_PFLIP. But VUPDATE_NO_LOCK fires every frame, regardless of whether a flip has latched. 2. There is a window during commit where a flip is armed (pflip_status = SUBMITTED) but not yet programmed into HW. If the VUPDATE_NO_LOCK fires in that window, its handler would deliver a flip event to userspace before HW has latched to it. If userspace then renders to what it believes is now the back buffer (but HW is still latched to it!), it will cause display corruption. This issue seemed to have been introduced by: commit 1159898a88db ("drm/amd/display: Handle commit plane with no FB.") Enabling replay or psr extended the duration of this window, and hence made corruption more likely to be observed. [How] * Move acrtc->event/pflip_status arming to after update_planes_and_stream_adapter() has programmed the flip into HW. This closes the window where pflip_status is SUBMITTED but the flip is not yet programmed. * Add dc_get_flip_pending_on_otg(), which reads the HUBP flip-pending status straight from HW for the pipe(s) bound to an OTG instance. It is keyed only by otg_inst and does not take or mutate a dc_plane_state, so it is safe to call from the OTG interrupt handler without racing a concurrent commit that may be modifying plane state. * Optimistically query for flip-pending after programming, in the event that HW latched to the new fb between programming start and arming event. If it latched, send the vblank event immediately, rather than wait for the next vblank IRQ. * In the VUPDATE_NO_LOCK handler, only deliver flip completion once dc_get_flip_pending_on_otg() reports the flip is no longer pending. Otherwise leave the flip armed and retry on the next vupdate. * For DCE, maintain the existing behavior of arming flips before programming, and relying on GRPH_FLIP to fire at HW latch. v2: * Drop flip_programmed completion object, instead move event/pflip_status arming after programming. * For DCN, optimistically query for flip pending immediately after programming, and if it latched, send event right away. v3: * Fix event timestamps on optimistic flip latch detection, where it's possible for it to run *before* the vupdate IRQ updates the timestamp. * Add more docstrings for DCN vblank handling. * Clean up if conditions in dm_arm_vblank_event(). * Code style cleanup on braces surrounding multi-line statements. Fixes: 9b47278cec98 ("drm/amd/display: temp w/a for dGPU to enter idle optimizations") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/3787 Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4141 Assisted-by: Copilot:claude-opus-4.8 Tested-by: Mario Limonciello (AMD) Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Leo Li Signed-off-by: Alex Deucher (cherry picked from commit f64a9be5653689ff43e148cd8a6483077488c8e5) Cc: stable@vger.kernel.org # 8382cd234981: drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit b485bfb45555163bfa5f565d6a3415fcb3035b02 Author: Tejas Upadhyay Date: Fri Jul 31 20:45:07 2026 -0400 drm/xe/guc: Fix buffer overflow in steered register list allocation [ Upstream commit 632ecc90e1ca5d3b6822bb4d08f84a175b6c42c0 ] The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) Fixes: b170d696c1e2 ("drm/xe/guc: Add XE_LP steered register lists") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/8049 Cc: Zhanjun Dong Cc: stable@vger.kernel.org Assisted-by: GitHub-Copilot:claude-opus-4.6 Reviewed-by: Zhanjun Dong Link: https://patch.msgid.link/20260612070401.543305-2-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f) Signed-off-by: Matthew Brost Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 30b2d0843a4101934109c1e7f9240b153d631c10 Author: Timur Kristóf Date: Fri Jul 31 12:25:27 2026 -0400 drm/amdgpu: Respect placement requirements in amdgpu_gtt_mgr functions [ Upstream commit 8882f8897e554053af9e72f4c2da8b1e2cce56c7 ] When testing intersection and compatibility, respect the actual placement requirements. This is a pre-requisite for ensuring that UVD CS BOs do not cross 256M segments. Fixes: ded910f368a5 ("drm/amdgpu: Implement intersect/compatible functions") Suggested-by: Christian König Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit bc06579ca29dee9c245a41b12e39c7bb6938af5d) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e06c39cc1c48dca68a5ffd971c23025a52d46634 Author: Tvrtko Ursulin Date: Fri Jul 31 12:00:49 2026 -0400 drm/amdgpu: Fix context pstate override handling [ Upstream commit c1dc4ccb82c9e56325d8e7514ca4c90bd1efb351 ] There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. Signed-off-by: Tvrtko Ursulin Fixes: 79610d304133 ("drm/amdgpu: fix pstate setting issue") Cc: Chengming Gui Cc: Alex Deucher Cc: "Christian König" Signed-off-by: Alex Deucher (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27) Cc: # v6.1+ Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4d49ca777cf1ae8d17b4b1a6090aaa13b0986dec Author: Thomas Zimmermann Date: Thu Jul 30 22:41:01 2026 -0400 drm/tegra: fbdev: Remove offset into framebuffer memory [ Upstream commit a18b6e30ecd69096beda4a0c96d2570900c3879a ] The screen_buffer field in struct fb_info contains the kernel address of the first byte of framebuffer memory. Do not add the display offset. This offset only describes scrolling during scanout. Signed-off-by: Thomas Zimmermann Fixes: de2ba664c30f ("gpu: host1x: drm: Add memory manager and fb") Cc: dri-devel@lists.freedesktop.org Cc: linux-tegra@vger.kernel.org Cc: # v3.10+ Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260421073646.144712-3-tzimmermann@suse.de Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3f58077457985c622c014f438d8e00dbd03db338 Author: Thomas Zimmermann Date: Thu Jul 30 22:41:00 2026 -0400 drm/fb-helper: Allocate and release fb_info in single place [ Upstream commit 63c971af40365ee706c7e24f6a7900d693518f09 ] Move the calls to drm_fb_helper_alloc_info() from drivers into a single place in fbdev helpers. Allocates struct fb_info for a new framebuffer device. Then call drm_fb_helper_single_fb_probe() to create an fbdev screen buffer. Also release the instance on errors by calling drm_fb_helper_release_info(). Simplifies the code and fixes the error cleanup for some of the drivers. Regular release of the struct fb_info instance still happens in drm_fb_helper_fini() as before. v2: - remove error rollback in driver implementations (kernel test robot) - initialize info in TTM implementation (kernel test robot) Signed-off-by: Thomas Zimmermann Acked-by: Christian König # radeon Acked-by: Dmitry Baryshkov # msm Acked-by: Javier Martinez Canillas Link: https://patch.msgid.link/20251027081245.80262-1-tzimmermann@suse.de Stable-dep-of: a18b6e30ecd6 ("drm/tegra: fbdev: Remove offset into framebuffer memory") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 165613191ad9d034bf17c00e3a142f9561597ec5 Author: Mike Rapoport (Microsoft) Date: Thu Aug 6 23:34:59 2026 -0400 userfaultfd: prevent registration of special VMAs [ Upstream commit 3c58f641e813c3c71039f8fd4d4e2a3aab713288 ] Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL. Link: https://lore.kernel.org/20260618095017.2553004-1-rppt@kernel.org Fixes: 54007f818206 ("mm: Introduce VM_SHADOW_STACK for shadow stack memory") Signed-off-by: Mike Rapoport (Microsoft) Reported-by: vova tokarev Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes Cc: Al Viro Cc: Christian Brauner Cc: Jan Kara Cc: Linus Torvalds Cc: Mike Rapoport Cc: Oleg Nesterov Cc: Peter Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 02d378828af8bb74f6c2f4d2bee3c77cf16c861e Author: Fan Wu Date: Thu Aug 6 09:17:40 2026 -0400 wifi: brcmfmac: drain bus_reset work on device removal [ Upstream commit 43b25879f004c98defa2776bedc6ca4763c51945 ] brcmf_fw_crashed() and the debugfs "reset" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs "reset" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. This issue was found by an in-house static analysis tool. Fixes: 4684997d9eea ("brcmfmac: reset PCIe bus on a firmware crash") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Assisted-by: Codex:gpt-5.6 Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260718024353.3147201-3-fanwu01@zju.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d6f322d68abfdb89926fd9ad9291b65cc0bb6cc9 Author: Niklas Söderlund Date: Thu Aug 6 08:46:34 2026 -0400 media: uapi: rkisp: Correct name version enum [ Upstream commit c4c01c4fd4a3916ffdfb35ad9f511c48e289f51c ] The name of the enum to hold the mapping of parameter buffer versions have a typo in the name, correct it. While this is a uAPI header the impact should be minimal as the enum is only used as a collection for the one version number supported. Fixes: e9d05e9d5db1 ("media: uapi: rkisp1-config: Add extensible params format") Cc: stable@vger.kernel.org Signed-off-by: Niklas Söderlund Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260501190339.3449193-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil [ Adjusted context to keep the tree's `RKISP1_EXT_PARAM_BUFFER_V1 = 1` initializer instead of upstream's `V4L2_ISP_PARAMS_VERSION_V1`, which does not exist in this tree. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5c6d5d2484cab62e6c42511e060c60b138ba4838 Author: Bryan O'Donoghue Date: Tue Aug 4 20:08:33 2026 -0400 media: qcom: camss: Fix RDI streaming for CSID 340 [ Upstream commit cc1c35619c9895f918f9e388e3caa6ab2ff2fbe7 ] Fix streaming from CSIDn RDI1 and RDI2 to VFEn RDI1 and RDI2. A pattern we have replicated throughout CAMSS where we use the VC number to populate both the VC fields and port fields of the CSID means that in practice only VC = 0 on CSIDn:RDI0 to VFEn:RDI0 works. Fix that for CSID 340 by separating VC and port. Fix to VC zero as a bugfix we will look to properly populate the VC field with follow on patches later. Fixes: f0fc808a466a ("media: qcom: camss: Add CSID 340 support") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Reviewed-by: Vladimir Zapolskiy Reviewed-by: Loic Poulain Signed-off-by: Bryan O'Donoghue Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f730ee0ef8facc47baede1e5778baa5c97d9d1b1 Author: Loic Poulain Date: Tue Aug 4 20:08:32 2026 -0400 media: qcom: camss: csid-340: Fix unused variables [ Upstream commit 0b61ce8dc4a71ea7baa19275c655677c612dde6d ] The CSID driver has some unused variables and function parameters that are no longer needed (due to refactoring). Clean up those unused elements: - Remove the `vc` parameter from `__csid_configure_rx()`. - Drop the unused `lane_cnt` variable. - Adjust call to `__csid_configure_rx()` accordingly. Signed-off-by: Loic Poulain Reviewed-by: Bryan O'Donoghue Reviewed-by: Vladimir Zapolskiy Signed-off-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Stable-dep-of: cc1c35619c98 ("media: qcom: camss: Fix RDI streaming for CSID 340") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 276420a86e75f57642b633c1f7e4ee96a6ce9708 Author: Jackson Lee Date: Tue Aug 4 06:47:12 2026 -0400 media: chips-media: wave5: Support CBP profile [ Upstream commit f8505f9d6b223a26854003bfdba1a0772457886d ] Constrained Baseline Profile (CBP) and Baseline Profile (BP) have been treated as the same. Introduce the ability to differentiate between the two. 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 Tested-by: Brandon Brnich Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3f7b3728dd9011c915cbeaea77274ebe8366550d Author: Andrei Kuchynski Date: Thu Jul 30 15:29:52 2026 -0400 usb: typec: ucsi: Fix race condition and ordering in port unregistration [ Upstream commit 7aa7d4bf9d3fa9a6a47b640ad103ab433b7ff261 ] A synchronization issue exists during port unregistration where pending partner work items can race against workqueue destruction, leading to use-after-free conditions: cros_ec_ucsi cros_ec_ucsi.3.auto: error -ETIMEDOUT: PPM init failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:__queue_work+0x83/0x4a0 Call Trace: __cfi_delayed_work_timer_fn+0x10/0x10 run_timer_softirq+0x3b6/0xbd0 sched_clock_cpu+0xc/0x110 irq_exit_rcu+0x18d/0x330 fred_sysvec_apic_timer_interrupt+0x5e/0x80 Fix this by ensuring strict ordering and proper serialization during teardown: 1. Move ucsi_unregister_partner() to the beginning of the teardown sequence and protect it under the connector mutex lock. 2. Ensure all pending partner tasks are explicitly flushed and finished before the workqueue is destroyed. 3. Switch from mod_delayed_work() to a cancel_delayed_work() and queue_delayed_work() sequence. This guarantees that items currently marked as pending won't be scheduled an additional time, preventing a double release of resources which leads to the following crash: Oops: general protection fault, probably for non-canonical address 0xdead000000000122: 0000 [#1] SMP NOPTI Workqueue: cros_ec_ucsi.3.auto-con2 ucsi_poll_worker RIP: 0010:ucsi_poll_worker+0x65/0x1e0 Call Trace: process_scheduled_works+0x218/0x6d0 worker_thread+0x188/0x3f0 __cfi_worker_thread+0x10/0x10 kthread+0x226/0x2a0 To ensure these rules are applied identically across both the normal teardown and the ucsi_init() error paths, consolidate the cleanup logic into a new helper, ucsi_unregister_port(). Cc: stable Fixes: b9aa02ca39a4 ("usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking") Fixes: b13abcb7ddd8 ("usb: typec: ucsi: Fix NULL pointer access") Fixes: fac4b8633fd6 ("usb: ucsi: Ensure connector delayed work items are flushed") Signed-off-by: Andrei Kuchynski Reviewed-by: Benson Leung Link: https://patch.msgid.link/20260707141736.1635698-1-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 58d9caa64f9c61721a0c35dc080b752bbb5ba625 Author: Sergey Senozhatsky Date: Thu Jul 30 15:29:51 2026 -0400 usb: typec: ucsi: split connector lock classes [ Upstream commit 8c22256bbafad3dc5fdbe9f684d045b67ff06a68 ] Lockdep detects a possible recursive locking scenario during ucsi init: [ 5.418616] ============================================ [ 5.418634] WARNING: possible recursive locking detected [ 5.418706] -------------------------------------------- [ 5.418725] kworker/4:1/82 is trying to acquire lock: [ 5.418759] ffff888119a34648 (&con->lock){+.+.}-{3:3}, at: ucsi_init_work+0x1a78/0x2eb0 [typec_ucsi] [ 5.418801] but task is already holding lock: [ 5.418835] ffff888119a34080 (&con->lock){+.+.}-{3:3}, at: ucsi_init_work+0x1a78/0x2eb0 [typec_ucsi] [ 5.418884] other info that might help us debug this: [ 5.418904] Possible unsafe locking scenario: [ 5.418937] CPU0 [ 5.418956] ---- [ 5.418991] lock(&con->lock); [ 5.419013] lock(&con->lock); [ 5.419033] *** DEADLOCK *** [ 5.419387] Call Trace: [ 5.419406] [ 5.419425] dump_stack_lvl+0x61/0xa0 [ 5.419448] print_deadlock_bug+0x4a6/0x650 [ 5.419483] __lock_acquire+0x62b6/0x7f50 [ 5.419507] lock_acquire+0x11b/0x390 [ 5.419654] __mutex_lock+0xbc/0xcd0 [ 5.419741] ucsi_init_work+0x1a78/0x2eb0 [ 5.419785] ? worker_thread+0xf53/0x2bc0 [ 5.419819] worker_thread+0xff4/0x2bc0 [ 5.419842] kthread+0x2a7/0x330 [ 5.419863] ? __pfx_worker_thread+0x10/0x10 [ 5.419896] ? __pfx_kthread+0x10/0x10 [ 5.419916] ret_from_fork+0x38/0x70 [ 5.419936] ? __pfx_kthread+0x10/0x10 [ 5.419969] ret_from_fork_asm+0x1b/0x30 [ 5.419991] [ 5.420009] ---[ end trace 0000000000000000 ]--- The problem is that all connector locks belong to the same lockdep lock class, so the following loop: for (i = 0; i < ucsi->cap.num_connectors; i++) ucsi_register_port(connector[i]) mutex_lock(&connector[i]->lock) looks like a recursive acquire of the same mutex. Put each connector lock into a dedicated lock class so that lockdep doesn't see it as a possible recursion. Signed-off-by: Sergey Senozhatsky Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260515060042.136083-1-senozhatsky@chromium.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2bf24a7e190aae0ea47c78099938ae056c622e44 Author: Chuck Lever Date: Thu Aug 6 01:40:06 2026 +0800 net/handshake: Drain pending requests at net namespace exit [ Upstream commit ea5fe6a73ca57e5150b8a38b341aef2636eb72f0 ] The arguments to list_splice_init() in handshake_net_exit() are reversed. The call moves the local empty "requests" list onto hn->hn_requests, leaving the local list empty, so the subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the handshake_req allocation. Pass the source and destination in the documented order (list_splice_init(list, head) moves list onto head) so the pending list is transferred to the local scratch list and drained through handshake_complete(). Fixing the splice direction exposes a list-corruption race. After the splice each req->hr_list still has non-empty link pointers, threading the stack-local scratch list rather than hn_requests. A concurrent handshake_req_cancel() -- for example, from sunrpc's TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls remove_pending(), and sees !list_empty(&req->hr_list). __remove_pending_locked() then list_del_init()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run list_del() on an entry hits LIST_POISON instead. Have remove_pending() check HANDSHAKE_F_NET_DRAINING under hn_lock and report not-found when drain is in progress. The drain has already taken ownership; handshake_complete()'s existing test_and_set on HANDSHAKE_F_REQ_COMPLETED still arbitrates between drain and cancel for who calls the consumer's hp_done. Use list_del_init() rather than list_del() in the drain so req->hr_list does not carry LIST_POISON after drain releases the entry. The DRAINING guard in remove_pending() makes cancel return false, but cancel still falls through to test_and_set_bit on HANDSHAKE_F_REQ_COMPLETED and drops the request's hr_file reference. Without another pin, if that is the last reference, sk_destruct frees the request while it is still linked on the drain loop's local list. Pin each request's hr_file under hn_lock before releasing the list, and drop that drain pin after the loop finishes with the request. Fixes: 3b3009ea8abb ("net/handshake: Create a NETLINK service for handling handshake requests") Signed-off-by: Chuck Lever Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260525-handshake-file-pin-v3-8-66c616906ead@oracle.com Signed-off-by: Paolo Abeni (cherry picked from commit ea5fe6a73ca57e5150b8a38b341aef2636eb72f0) Signed-off-by: Wentao Guan Signed-off-by: Sasha Levin commit 6e7b52bd1394829c9cb4e5728dd64e41fa2d7d65 Author: Chuck Lever Date: Thu Aug 6 01:40:04 2026 +0800 net/handshake: Close the submit-side sock_hold race [ Upstream commit 5da98f55b13173c08f003011b76531b25c821c07 ] handshake_req_submit() publishes the request via handshake_req_hash_add() and __add_pending_locked(), drops hn_lock, and calls handshake_genl_notify() (which can sleep) before taking sock_hold() on req->hr_sk. A fast tlshd ACCEPT followed by DONE can drive handshake_complete()'s sock_put() into the window between the spin_unlock and the late sock_hold(); on a system where the consumer's fd held the only sk reference, the late sock_hold() then operates on an sk whose refcount has reached zero. The preceding two patches install an explicit file reference on struct handshake_req. That file pins sock->file, which pins the embedded struct socket, which defers inet_release()'s sock_put(). As long as hr_file is held, sk cannot reach refcount zero from the consumer side, and the submit-side sock_hold() with its matching sock_put() calls in handshake_complete() and handshake_req_cancel() is now redundant. Drop all three. The file reference already keeps each request's socket alive, and the lifetime story is contained in a single get_file()/fput() pair. Fixes: 3b3009ea8abb ("net/handshake: Create a NETLINK service for handling handshake requests") Signed-off-by: Chuck Lever Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260525-handshake-file-pin-v3-6-66c616906ead@oracle.com Signed-off-by: Paolo Abeni (cherry picked from commit 5da98f55b13173c08f003011b76531b25c821c07) Signed-off-by: Wentao Guan Signed-off-by: Sasha Levin commit 68eba6519cbd6359fb554a9720f3a3b6b2eba23f Author: Chuck Lever Date: Thu Aug 6 01:40:02 2026 +0800 net/handshake: hand off the pinned file reference to accept_doit [ Upstream commit f4251190e58b209999c1ba9e6d2976136a1be055 ] handshake_req_next() removes the request from the per-net pending list and drops hn_lock before handshake_nl_accept_doit() reads req->hr_sk->sk_socket and dereferences sock->file (once in FD_PREPARE() and again in get_file()). In that window a consumer running tls_handshake_cancel() followed by sockfd_put() (svc_sock_free) or __fput_sync() (xs_reset_transport) releases sock->file. sock_release() then runs sock_orphan(), zeroing sk_socket, and frees the struct socket. The accept-side code either reads NULL through sk_socket or chases freed memory. The submit-side sock_hold() does not prevent this. sk_refcnt protects struct sock, but struct socket and sock->file are independently refcounted via the file descriptor the consumer owns. Pinning sk leaves sock and sock->file unprotected. Retarget the accept-side dereferences at req->hr_file, which was pinned at submit time, instead of req->hr_sk->sk_socket->file. Pinning on its own is not sufficient: a consumer that cancels between handshake_req_next() returning and accept_doit reaching FD_PREPARE() takes the !remove_pending() branch in handshake_req_cancel() and drops hr_file before the accept side takes its own reference. Hand off an additional file reference inside handshake_req_next(), under hn_lock, so the accept side operates on a reference that no concurrent handshake_req_cancel() can revoke. FD_PREPARE() consumes that handed-off reference, either by transferring it to the new fd in fd_publish() or by dropping it in the cleanup destructor on error; the explicit get_file() that previously balanced FD_PREPARE() is therefore redundant and goes away. Update handshake_req_cancel_test2 and _test3 to simulate the FD_PREPARE() consumption with an fput() so the kunit file-count assertions stay balanced. Reported-by: Chris Mason Fixes: 3b3009ea8abb ("net/handshake: Create a NETLINK service for handling handshake requests") Signed-off-by: Chuck Lever Reviewed-by: Hannes Reinecke Link: https://patch.msgid.link/20260525-handshake-file-pin-v3-5-66c616906ead@oracle.com Signed-off-by: Paolo Abeni (cherry picked from commit f4251190e58b209999c1ba9e6d2976136a1be055) Signed-off-by: Wentao Guan Signed-off-by: Sasha Levin commit b913801ad9b9a51437d84d030ec6843e08976bd6 Author: Chuck Lever Date: Thu Aug 6 01:40:00 2026 +0800 net/handshake: Take a long-lived file reference at submit [ Upstream commit 09dba37eee70d0596e26645015f1aa95a9848e9d ] handshake_nl_accept_doit() needs the file pointer backing req->hr_sk->sk_socket to survive the window between handshake_req_next() and the subsequent FD_PREPARE() and get_file(). The submit-side sock_hold() does not provide that. sk_refcnt keeps struct sock alive, but struct socket is owned by sock->file: when the consumer fputs the last file reference, sock_release() tears the socket down regardless of any sock_hold. Add an hr_file pointer to struct handshake_req and acquire an explicit reference on sock->file during handshake_req_submit(). handshake_complete() and handshake_req_cancel() release the reference on the completion-bit-winning path. The submit error path must also release the file reference, but after rhashtable insertion a concurrent handshake_req_cancel() can discover the request and race the error path. Gate the error-path cleanup -- sk_destruct restoration, fput, and request destruction -- with test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED), the same serialization handshake_complete() and handshake_req_cancel() already use. When cancel has already claimed ownership, the submit error path returns without touching the request; socket teardown handles final destruction. The accept-side dereferences are not yet retargeted; that change comes in the next patch. Signed-off-by: Chuck Lever Link: https://patch.msgid.link/20260525-handshake-file-pin-v3-4-66c616906ead@oracle.com Signed-off-by: Paolo Abeni (cherry picked from commit 09dba37eee70d0596e26645015f1aa95a9848e9d) Signed-off-by: Wentao Guan Signed-off-by: Sasha Levin commit 5ddfc47e1228d207602d945f63e6869ede081ef9 Author: Wang Liang Date: Thu Aug 6 01:39:58 2026 +0800 net/handshake: Fix null-ptr-deref in handshake_complete() [ Upstream commit dabac51b8102e1643d8e297a8e6948dab190aa4c ] A null pointer dereference in handshake_complete() was observed [1]. When handshake_req_next() return NULL in handshake_nl_accept_doit(), function handshake_complete() will be called unexpectedly which triggers this crash. Fix it by goto out_status when req is NULL. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTI RIP: 0010:handshake_complete+0x36/0x2b0 net/handshake/request.c:288 Call Trace: handshake_nl_accept_doit+0x32d/0x7e0 net/handshake/netlink.c:129 genl_family_rcv_msg_doit+0x204/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg+0x436/0x670 net/netlink/genetlink.c:1195 genl_rcv_msg+0xcc/0x170 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x14c/0x430 net/netlink/af_netlink.c:2550 genl_rcv+0x2d/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x878/0xb20 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x897/0xd70 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa39/0xbf0 net/socket.c:2592 ___sys_sendmsg+0x121/0x1c0 net/socket.c:2646 __sys_sendmsg+0x155/0x200 net/socket.c:2678 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x5f/0x350 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: fe67b063f687 ("net/handshake: convert handshake_nl_accept_doit() to FD_PREPARE()") Reviewed-by: Chuck Lever Reported-by: Dan Carpenter Closes: https://lore.kernel.org/kernel-tls-handshake/aScekpuOYHRM9uOd@morisot.1015granger.net/T/#m7cfa5c11efc626d77622b2981591197a2acdd65e Signed-off-by: Wang Liang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251212012723.4111831-1-wangliang74@huawei.com Signed-off-by: Paolo Abeni (cherry picked from commit dabac51b8102e1643d8e297a8e6948dab190aa4c) Signed-off-by: Wentao Guan Signed-off-by: Sasha Levin commit 97e745b4ea0557e671b7431c5c1d37184ba04325 Author: Christian Brauner Date: Thu Aug 6 01:39:56 2026 +0800 net/handshake: convert handshake_nl_accept_doit() to FD_PREPARE() [ Upstream commit fe67b063f687d8f32c466778aad57508bc1c618a ] Link: https://patch.msgid.link/20251123-work-fd-prepare-v4-27-b6efa1706cfd@kernel.org Signed-off-by: Christian Brauner (cherry picked from commit fe67b063f687d8f32c466778aad57508bc1c618a) Signed-off-by: Wentao Guan Signed-off-by: Sasha Levin commit f00dd592abe77fcf1f1e40772834cf982c682406 Author: Christian Brauner Date: Thu Aug 6 01:39:54 2026 +0800 file: ensure cleanup [ Upstream commit d2ea4d254d04a89e17504af0230c7268e3cac6bf ] Brown paper bag time. This is a silly oversight where I missed to drop the error condition checking to ensure we clean up on early error returns. I have an internal unit testset coming up for this which will catch all such issues going forward. Reported-by: Chris Mason Reported-by: Jeff Layton Fixes: 011703a9acd7 ("file: add FD_{ADD,PREPARE}()") Signed-off-by: Christian Brauner Reviewed-by: Jeff Layton Signed-off-by: Linus Torvalds (cherry picked from commit d2ea4d254d04a89e17504af0230c7268e3cac6bf) Signed-off-by: Wentao Guan Signed-off-by: Sasha Levin commit 10827847c40c18d5fa2c49e5791ca2b854439c17 Author: Christian Brauner Date: Thu Aug 6 01:39:52 2026 +0800 file: add FD_{ADD,PREPARE}() [ Upstream commit 011703a9acd76edc7c85d80dbccb6e50dba53aad ] I've been playing with this to allow for moderately flexible usage of the get_unused_fd_flags() + create file + fd_install() pattern that's used quite extensively. How callers allocate files is really heterogenous so it's not really convenient to fold them into a single class. It's possibe to split them into subclasses like for anon inodes. I think that's not necessarily nice as well. My take is to add two primites: (1) FD_ADD() the simple cases a file is installed: fd = FD_ADD(O_CLOEXEC, open_file(some, args))); if (fd >= 0) kvm_get_kvm(vcpu->kvm); return fd; (2) FD_PREPARE() that captures all the cases where access to fd or file or additional work before publishing the fd is needed: FD_PREPARE(fdf, open_flag, file_open_handle(&path, open_flag)); if (fdf.err) return fdf.err; if (copy_to_user(/* something something */)) return -EFAULT; return fd_publish(fdf); I've converted all of the easy cases over to it and it gets rid of an aweful lot of convoluted cleanup logic. It's centered around struct fd_prepare. FD_PREPARE() encapsulates all of allocation and cleanup logic and must be followed by a call to fd_publish() which associates the fd with the file and installs it into the callers fdtable. If fd_publish() isn't called both are deallocated. It mandates a specific order namely that first we allocate the fd and then instantiate the file. But that shouldn't be a problem nearly everyone I've converted uses this exact pattern anyway. There's a bunch of additional cases where it would be easy to convert them to this pattern. For example, the whole sync file stuff in dma currently retains the containing structure of the file instead of the file itself even though it's only used to allocate files. Changing that would make it fall into the FD_PREPARE() pattern easily. I've not done that work yet. There's room for extending this in a way that wed'd have subclasses for some particularly often use patterns but as I said I'm not even sure that's worth it. Link: https://patch.msgid.link/20251123-work-fd-prepare-v4-1-b6efa1706cfd@kernel.org Signed-off-by: Christian Brauner (cherry picked from commit 011703a9acd76edc7c85d80dbccb6e50dba53aad) Signed-off-by: Wentao Guan Signed-off-by: Sasha Levin commit 10065fb891651d9541e7a5a2db84c1e656ece4f9 Author: Kiryl Shutsemau (Meta) Date: Wed Aug 5 14:45:25 2026 +0100 mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios [ Upstream commit e923bd21058ea02fd0dcd3549d151d143fd036e5 ] __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure() passes when splitting a poisoned tail of a shmem THP that reaches past i_size during truncation, it too is gone from the page cache; so once @folio is unlocked no locked, in-cache folio pins the inode, and a concurrent final iput() can evict and RCU-free it before i_mmap_unlock_read() touches i_mmap_rwsem: BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline] __folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 Freed by task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870 Do every mapping dereference while @folio still pins the inode: drop i_mmap_rwsem right after remap_page(), before the loop that unlocks and frees the after-split folios, and clear @mapping so the exit path does not unlock it again. shmem_uncharge() and remap_page() already run before that point, so after this nothing past the unlock loop touches the inode or the mapping. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked. Link: https://lore.kernel.org/20260716095424.471052-1-kirill@shutemov.name Fixes: baa355fd3314 ("thp: file pages support for split_huge_page()") Signed-off-by: Kiryl Shutsemau (Meta) Reported-by: Hao Zhang Closes: https://lore.kernel.org/linux-mm/20260710071344.GA106129@zh-pc Co-developed-by: Hao Zhang Signed-off-by: Hao Zhang Acked-by: David Hildenbrand (Arm) Reviewed-by: Zi Yan Reviewed-by: Baolin Wang Reviewed-by: Miaohe Lin Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Cc: Signed-off-by: Andrew Morton (cherry picked from commit e923bd21058ea02fd0dcd3549d151d143fd036e5) Signed-off-by: Kiryl Shutsemau (Meta) Signed-off-by: Sasha Levin commit be11b4bf498a38671743da800cc24be9f43b17b7 Author: Kiryl Shutsemau (Meta) Date: Wed Aug 5 14:43:52 2026 +0100 fs/proc/task_mmu: fix PAGEMAP_SCAN written state for unpopulated ptes [ Upstream commit 07b4377bdbe74a3ec0c8da5849d014f70e003384 ] PAGEMAP_SCAN reports an unpopulated pte differently depending on which path serves the request. The PAGE_IS_WRITTEN fast path in pagemap_scan_pmd_entry() reports a pte_none as written (and, under PM_SCAN_WP_MATCHING, arms a marker); pagemap_page_category() returns 0 for the same pte_none. A request that cannot take the fast path (an extra category bit, category_anyof_mask or category_inverted) therefore reports the pte as clean and skips arming it. A range that was populated and then MADV_DONTNEED'd reads as written via one mask and clean via another, and in the latter case is not re-armed for the next round -- an incremental-dump consumer (e.g. CRIU) using a richer mask drops the zapped range and stops tracking writes to it. Report pte_none as written in pagemap_page_category() too. A pte_none carries no uffd-wp marker, i.e. it is not write-protected -- the same condition under which the present and swap cases already report PAGE_IS_WRITTEN. The fast path applies no VMA test, so neither does this. The hugetlb and fully-unpopulated-PMD (no page table) scans have no PAGE_IS_WRITTEN fast path, so they do not exhibit the per-entry divergence and are left unchanged. Add a pagemap_ioctl selftest that populates a range, drops it with MADV_DONTNEED, and checks that the fast path and the generic (category_anyof_mask) path both report every page written. Link: https://lore.kernel.org/20260707151349.92143-1-kirill@shutemov.name Fixes: 12f6b01a0bcb ("fs/proc/task_mmu: add fast paths to get/clear PAGE_IS_WRITTEN flag") Signed-off-by: Kiryl Shutsemau Cc: Muhammad Usama Anjum Cc: David Hildenbrand Cc: Jann Horn Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Pedro Falcato Cc: Peter Xu Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Assisted-by: Claude:claude-fable-5 Cc: Signed-off-by: Andrew Morton (cherry picked from commit 07b4377bdbe74a3ec0c8da5849d014f70e003384) [ kas: fix only; selftest hunk dropped (pagemap_ioctl.c differs on this tree). Add the pte_none early-return before the pte_present branch ] Signed-off-by: Kiryl Shutsemau (Meta) Signed-off-by: Sasha Levin commit 2b9a07002c2f296aa6a9c591213933d3492e3089 Author: Kiryl Shutsemau (Meta) Date: Wed Aug 5 14:43:46 2026 +0100 mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork() [ Upstream commit 83abe2fd5b3aeb3123b5408a5a91709c5538fb23 ] copy_hugetlb_page_range() clears the uffd-wp bit of migration and hwpoison entries with huge_pte_clear_uffd_wp(), which operates on the present-PTE bit position. Swap entries keep the uffd-wp state elsewhere -- the migration branch reads and sets it with pte_swp_uffd_wp() and pte_swp_mkuffd_wp() -- and the present-PTE position falls into the swap payload. On x86-64 it lands in the inverted swap offset, where a naturally-aligned hugetlb PFN always has the affected bit set, so the clear advances the encoded PFN by two pages. No userfaultfd needs to be involved: the clear is guarded only by the child VMA not being uffd-wp registered, so a plain fork() with an in-flight hugetlb migration entry (or a poisoned hugetlb page) corrupts the entry copied into the child. Instrumenting the clear and forking after MADV_HWPOISON on a 2MB anon hugetlb page shows: offset before=120e00 offset after =120e02 The fallout is mostly latent: rmap walks match migration entries by folio range and remove_migration_pte() rebuilds the PTE from the folio, so a within-folio PFN skew heals once migration completes. But any path that re-encodes the corrupted offset -- e.g. hugetlb_change_protection() rewriting a writable migration entry via make_readable_migration_entry(swp_offset(entry)) -- propagates it. Migration entries legitimately carry uffd-wp, so clear it with pte_swp_clear_uffd_wp(), matching copy_nonpresent_pte() and move_huge_pte(). A hwpoison entry, on the other hand, never carries the uffd-wp bit: it is installed fresh by make_hwpoison_entry() (try_to_unmap_one() does not preserve uffd-wp on the hwpoison path) and hugetlb_change_protection() leaves hwpoison entries untouched. There was nothing to clear there, only the corruption, so drop the clear entirely. Link: https://lore.kernel.org/20260708090110.136162-1-kirill@shutemov.name Fixes: bc70fbf269fd ("mm/hugetlb: handle uffd-wp during fork()") Signed-off-by: Kiryl Shutsemau Reported-by: Sashiko AI review Closes: https://lore.kernel.org/all/20260703140011.99E601F000E9@smtp.kernel.org/ Suggested-by: David Hildenbrand Acked-by: David Hildenbrand (Arm) Assisted-by: Claude:claude-fable-5 Cc: Muchun Song Cc: Oscar Salvador Cc: Peter Xu Cc: Signed-off-by: Andrew Morton (cherry picked from commit 83abe2fd5b3aeb3123b5408a5a91709c5538fb23) [ kas: adapt to the pre-softleaf idiom ] Signed-off-by: Kiryl Shutsemau (Meta) Signed-off-by: Sasha Levin commit fc0c76b0450f200a894811ee789ecedbcfdbaeb9 Author: Ashutosh Dixit Date: Tue Aug 4 19:46:14 2026 -0700 drm/xe/rtp: Ensure locking/ref counting for OA whitelists [ Upstream commit ef78e2a22f72c892fd6663f0760abd208d49a3e2 ] Since multiple OA streams might be open in parallel on a gt, ensure that proper locking is in place. Also ensure that OA registers are whitelisted when the first OA stream is open and de-whitelisted after the last OA stream is closed. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260615224227.34880-10-ashutosh.dixit@intel.com Signed-off-by: Sasha Levin commit 9783d8662b5658e9efdb3a0934cd0ce382816878 Author: Ashutosh Dixit Date: Tue Aug 4 19:46:13 2026 -0700 drm/xe/oa: (De-)whitelist OA registers on OA stream open/release [ Upstream commit 63ddb3ad08ff4e89c108499dfec5e9be5ddc25c9 ] Whitelist OA registers on stream open and de-whitelist on stream close/release. Whitelisting is only done when 'stream->sample' is true. 'stream->sample' is only true when (a) xe_observation_paranoid is set to false by system admin, or (b) the process is perfmon_capable(). This therefore enforces the OA register whitelisting security requirements. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260615224227.34880-9-ashutosh.dixit@intel.com Signed-off-by: Sasha Levin commit f5966d9006623b4a7c754f807fca84ee2b976457 Author: Ashutosh Dixit Date: Tue Aug 4 19:46:12 2026 -0700 drm/xe/rtp: (De-)whitelist OA registers for all hwe's for a gt [ Upstream commit ebba7ce65252a4ab0e3794ff14854df2afca5c08 ] Whitelist or de-whitelist OA registers for all hwe's on the gt on which the OA stream is opened. This simplifies the case where an oa unit has 0 attached hwe's (but which monitors OA events on the associated GT). Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260615224227.34880-8-ashutosh.dixit@intel.com Signed-off-by: Sasha Levin commit d43abc858f08269b605d6400455aaf7933775df3 Author: Ashutosh Dixit Date: Tue Aug 4 19:46:11 2026 -0700 drm/xe/rtp: Toggle 'deny' bit to (de-)whitelist OA regs [ Upstream commit b422babd77fac2c96b92db484050e460899bddaf ] Whitelist or de-whitelist OA registers by setting or resetting the 'deny' bit in OA nonpriv registers and writing new register values to HW. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260615224227.34880-7-ashutosh.dixit@intel.com Signed-off-by: Sasha Levin commit c2cfee9bf8d46e22799894a252404f38daad2d80 Author: Ashutosh Dixit Date: Tue Aug 4 19:46:10 2026 -0700 drm/xe/rtp: Save OA nonpriv registers to register save/restore lists [ Upstream commit a19a83721a28ccaddace846da70da5c53d7dd052 ] Now we can save OA whitelisting nonpriv registers to register save/restore lists. OA nonpriv registers are saved to both hwe->oa_sr as well as hwe->reg_sr. During probe, resume and gt-reset flows KMD will apply hwe->reg_sr, ensuring OA registers are de-whitelisted after these events. For engine-reset, hwe->reg_sr is registered with GuC and GuC will apply these registers, ensuring OA registers are de-whitelisted after engine resets. hwe->oa_sr is used for whitelisting or de-whitelisting OA registers during OA operation, by toggling the 'deny' bit on oa stream open/close. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260615224227.34880-6-ashutosh.dixit@intel.com Signed-off-by: Sasha Levin commit 4bb92418e749ff69a6b71aed81de7b78674d195b Author: Ashutosh Dixit Date: Tue Aug 4 19:46:09 2026 -0700 drm/xe/rtp: Generalize whitelist_apply_to_hwe [ Upstream commit 4fe2844b0f0c7cdc45ca4c4c62ca56b7f26c514c ] Generalize whitelist_apply_to_hwe to construct both non-OA and OA whitelist nonpriv registers. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260615224227.34880-5-ashutosh.dixit@intel.com Signed-off-by: Sasha Levin commit cc716d3ac560fa5b2b51e1bdf25798eb7b46b0d4 Author: Ashutosh Dixit Date: Tue Aug 4 19:46:08 2026 -0700 drm/xe/rtp: Keep track of non-OA nonpriv slots [ Upstream commit 60d49ea28bb190a640bd8dc3f4c946e0811a948c ] In order to dynamically whitelist/dewhitelist OA registers on OA stream open/close, we need to keep track of nonpriv slots occupied by non-OA register whitelists. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260615224227.34880-4-ashutosh.dixit@intel.com Signed-off-by: Sasha Levin commit f73e97080debddbcc7071e1d007814444737481e Author: Ashutosh Dixit Date: Tue Aug 4 19:46:07 2026 -0700 drm/xe/rtp: Maintain OA whitelists separately [ Upstream commit 31e2437561621b4867c08efc890bf629d017df03 ] Contains minor modification of the above commit because of changed API. OA registers are dynamically whitelisted (and again dewhitelisted) on OA stream open/close. Maintaining OA whitelists separately from non-OA register whitlists simplifies this management of OA register whitelisting/dewhitelisting. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Ashutosh Dixit Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260615224227.34880-3-ashutosh.dixit@intel.com Signed-off-by: Sasha Levin commit 7982678fa21eda02a9111d2646be6762b5e3a64d Author: Ashutosh Dixit Date: Tue Aug 4 19:46:06 2026 -0700 drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists [ Upstream commit e70086a3a06d276b4a5d9a2c51c9330c6cf72780 ] Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don't get whitelisted by default after probe, gt reset, resume and engine reset. Fixes: 828a8eaf37c3 ("drm/xe/oa: Add MMIO trigger support") Cc: stable@vger.kernel.org # v6.12+ Suggested-by: Umesh Nerlige Ramappa Signed-off-by: Ashutosh Dixit Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260615224227.34880-2-ashutosh.dixit@intel.com Signed-off-by: Sasha Levin commit 542d3b9fa8ec67b724c5219fd1934e0efe0f86fb Author: Ashutosh Dixit Date: Tue Aug 4 19:46:05 2026 -0700 drm/xe/rtp: Refactor OAG MMIO trigger register whitelisting [ Upstream commit ed455775c5a68b75e5f6ad6c8e0e3e9c98fd3f64 ] Minor refactor of OAG MMIO trigger register whitelisting for code reuse with OAM MMIO trigger register whitelisting. Signed-off-by: Ashutosh Dixit Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20251202025115.373546-5-ashutosh.dixit@intel.com Signed-off-by: Sasha Levin commit 2b70bebc709489d29a31ac2935aeffb8d5228395 Author: HyeongJun An Date: Thu Jun 18 15:37:37 2026 +0900 HID: logitech-dj: Fix maxfield check in DJ short report validation commit 590cc4d782487632a52f37c2171bee1eeea29627 upstream. Commit b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write") added validation for the DJ short output report, but the error path dereferences rep->field[0] even when rep->maxfield is zero. Commit 8b9a097eb2fc ("HID: logitech-dj: fix wrong detection of bad DJ_SHORT output report") made the check conditional on rep being present, but a crafted descriptor can still create report ID 0x20 with only padding output items. hid-core registers the report, ignores the padding field, and leaves rep->maxfield as zero. In that case the validation enters the rep->maxfield < 1 branch and then dereferences rep->field[0]->report_count while printing the error message, causing a NULL pointer dereference during probe. This is reproducible with uhid by emulating a Logitech receiver with a padding-only DJ short output report: BUG: KASAN: null-ptr-deref in logi_dj_probe+0xb1/0x754 [hid_logitech_dj] Read of size 4 at addr 0000000000000028 by task kworker/4:1/129 ... Call Trace: logi_dj_probe+0xb1/0x754 [hid_logitech_dj] hid_device_probe+0x329/0x3f0 [hid] really_probe+0x162/0x570 __device_attach+0x137/0x2c0 bus_probe_device+0x38/0xc0 device_add+0xa56/0xce0 hid_add_device+0x19c/0x280 [hid] uhid_device_add_worker+0x2c/0xb0 [uhid] Reject the zero-field report before printing the field report_count. Fixes: b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 6be3dbe45b287fffcfd132ab5c531c47cb95251a Author: Jun Guo Date: Thu Jan 15 17:19:24 2026 +0800 spi: spi-cadence: enable SPI_CONTROLLER_MUST_TX commit f6b625639e39bc384a7bddbf134a698d40258b3b upstream. During an SPI read operation, even if the xspi->txbuf passed to the cdns_spi_writerinterface is empty, it is still necessary to call cdns_spi_write(xspi, CDNS_SPI_TXD, txw); otherwise, the read operation will fail to obtain data correctly due to a lack of clocks. Fixes: 4e00135b2dd1 ("spi: spi-cadence: supports transmission with bits_per_word of 16 and 32") Reported-by: Rodrigo Alencar <455.rodrigo.alencar@gmail.com> Closes: https://lore.kernel.org/all/lbijvnnwsnddonmm5pveqzap6iibxhl4maneq43x4j6w64dev6@u75qhm5cwiob/ Signed-off-by: Jun Guo Link: https://patch.msgid.link/20260115091924.844179-1-jun.guo@cixtech.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 042ca38779554687fc32b66a28328e0d9a36c58f Author: Zack Rusin Date: Tue May 5 18:22:33 2026 -0400 drm/vmwgfx: validate external BO copy bounds for both stride paths commit 706c93c5813caabbb0d0a576c017d15aeec2c113 upstream. vmw_external_bo_copy() trusts caller-supplied offsets, strides, and heights and operates on imported dma-buf vmaps: - The equal-stride memcpy() bound was clamped after subtracting the offsets from dst_size and src_size; an offset larger than the BO size wraps the unsigned subtraction to a huge value and the resulting memcpy() runs off the end of the vmap. dst_stride * height is also a u32 multiplication that can overflow. - The non-equal-stride row-by-row path had no bound at all. The loop touches bytes through offset + (height - 1) * stride + width_in_bytes, with only a WARN_ON(dst_stride < width_in_bytes), and could likewise step past the end of either mapping. The offsets and strides are derived from STDU/SOU plane state, so a configured CRTC submitting a crafted atomic commit on an imported framebuffer can reach this path. Validate the exact row-copy endpoint against each BO's size up front using check_mul_overflow() and check_add_overflow(). Use the bulk memcpy() path only when width_in_bytes covers the whole stride; otherwise copy one row at a time so partial-row updates near the bottom of a framebuffer remain valid. Also reject zero strides and stride < width_in_bytes, both of which the row-by-row path cannot represent safely. Fixes: 50f119925091 ("drm/vmwgfx: Fix prime with external buffers") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-13-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit cfd163169af3be56eaef113c680ea251f0d09189 Author: Zack Rusin Date: Tue May 5 18:22:32 2026 -0400 drm/vmwgfx: use check_add_overflow for shader size+offset bound commit 54d56d5b42d2e4c72ba6e365e9774da90698aa22 upstream. vmw_shader_define() validates the user-supplied shader window against its backing buffer with (u64)buffer->tbo.base.size < (u64)size + (u64)offset drm_vmw_shader_create_arg::offset is __u64 in the uapi; when it is near U64_MAX the unsigned addition wraps and the resulting tiny value passes the check. The unbounded offset is then stored in res->guest_memory_offset and forwarded to host SVGA shader-create commands. Use check_add_overflow() to detect the wrap and compare the resulting endpoint against the buffer size. Fixes: 668b206601c5 ("drm/vmwgfx: Stop using raw ttm_buffer_object's") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-12-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 1eb4f796695be39e0b5c4383350033ced9ade703 Author: Zack Rusin Date: Tue May 5 18:22:30 2026 -0400 drm/vmwgfx: enforce cursor size limits for MOB cursors commit d5ed8749168ad13c0dbaa8300f68d854b6076966 upstream. vmw_cursor_plane_atomic_check() bounds cursor width and height only on the legacy update path; the SVGA_CAP2_CURSOR_MOB path -- the default on modern hosts -- accepts any size. When the requested size exceeds SVGA_REG_CURSOR_MAX_DIMENSION or SVGA_REG_MOB_MAX_SIZE, vmw_cursor_mob_get() returns -EINVAL and leaves vps->cursor.mob NULL. Its return value is then discarded in vmw_cursor_plane_prepare_fb(), so the subsequent vmw_cursor_update_mob() calls vmw_bo_map_and_cache(NULL) and oopses inside vmw_bo_map_and_cache_size() on the tbo.base.size load. Reachable from any DRM master via DRM_IOCTL_MODE_CURSOR2 with a sufficiently large width or height (e.g. cursor_max_dim + 1). Reject oversized cursors in atomic_check for both MOB-backed cursor update types. The MOB byte-size limit only applies to the SVGA_CAP2_CURSOR_MOB path (vmw_cursor_mob_size() returns 0 for GB_ONLY); compute the required MOB size in 64-bit to avoid overflow when very large dimensions are requested. In prepare_fb only call vmw_cursor_mob_get()/_map() for VMW_CURSOR_UPDATE_MOB -- the GB_ONLY path uses bo->map.virtual directly and would otherwise be silently downgraded to NONE on hosts without SVGA_CAP2_CURSOR_MOB (where vmw_cursor_mob_get() always returns -EINVAL). Degrade the update to NONE if vmw_cursor_mob_get() or vmw_cursor_mob_map() fails so the update path does not run with a NULL backing MOB. Fixes: 965544150d1c ("drm/vmwgfx: Refactor cursor handling") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-10-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 96efee36453b697ccbaf75091b7a1807c11809dd Author: Zack Rusin Date: Tue May 5 18:22:29 2026 -0400 drm/vmwgfx: avoid destroy_workqueue(NULL) on vkms init failure commit 05eaa887e7b4f40fba425f8a1d7a5a8a043092a6 upstream. Two paths through vmw_vkms_init() can leave vmw->crc_workq NULL while still leaving the rest of the driver in a state that calls vmw_vkms_cleanup() at module unload: 1. vmw_host_get_guestinfo(GUESTINFO_VBLANK, ...) failing or returning an oversized buffer -- the common case on hosts without a VBLANK guestinfo entry -- early-returned before the workqueue allocation. 2. alloc_ordered_workqueue() returning NULL on memory pressure. vmw_vkms_cleanup() then calls destroy_workqueue(NULL), which dereferences wq->name and panics. Fix the first case by removing the early return: vmw->vkms_enabled is already false on the rpci-failure path so no work will ever be queued, and allocating the workqueue unconditionally keeps the control flow simple. Fix the second case by guarding the cleanup with a NULL check, since alloc_ordered_workqueue() can still fail under low memory. Fixes: 7b0062036c3b ("drm/vmwgfx: Implement virtual crc generation") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-9-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 7e40e6120fb232a10b543ffd994e5c6d8f3a2cc6 Author: Zack Rusin Date: Tue May 5 18:22:28 2026 -0400 drm/vmwgfx: bound DMA command body size against suffix pointer commit f4f1db96bfd68b81053693ba53405b6f510ac16c upstream. vmw_cmd_dma() locates the DMA suffix at (unsigned long) &cmd->body + header->size - sizeof(*suffix) without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields. Reject the command if the body is too small for the suffix to fit. Fixes: 4e4ddd477743 ("drm/vmwgfx: Fix queries if no dma buffer thrashing is occuring.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-8-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit dc0be7662b7b0ce28cb5eea864737793ed7b9e70 Author: Zack Rusin Date: Tue May 5 18:22:27 2026 -0400 drm/vmwgfx: validate DRAW_PRIMITIVES header size before division commit 85891d174707d8bddcec7a888fb4e1d17def34f3 upstream. vmw_cmd_draw() computes maxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front. Fixes: 7a73ba7469cb ("drm/vmwgfx: Use TTM handles instead of SIDs as user-space surface handles.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-7-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit a8434b145b1e467940334c58c00af241e9494c5f Author: Zack Rusin Date: Tue May 5 18:22:26 2026 -0400 drm/vmwgfx: drop dma_buf reference on foreign-fd prime import commit f739416dc555fa205a785e5135d73fa39b26f35d upstream. ttm_prime_fd_to_handle() returns -ENOSYS when the imported fd's dma_buf->ops do not match the ttm_object_device's ops, but does so without releasing the reference acquired by dma_buf_get(). Any unprivileged renderD client passing a non-vmwgfx prime fd through the DRM_VMW_GB_SURFACE_REF{,_EXT} path leaks one dma_buf reference per call and indefinitely pins the foreign exporter's GEM resources. Funnel the error path through the existing dma_buf_put() so the reference is always dropped. Fixes: 65981f7681ab ("drm/ttm: Add a minimal prime implementation for ttm base objects") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-6-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit b79e82ea18236a4be641d53f1b7493fd44e75be8 Author: Zack Rusin Date: Tue May 5 18:22:25 2026 -0400 drm/vmwgfx: take fman->lock around fence list mutation in fifo_down commit 250af2e8c3e90dc978e062a936b633870a22e660 upstream. vmw_fence_fifo_down() drops fman->lock to wait on a fence and, on timeout, mutates fman->fence_list via list_del_init() and signals the fence without re-acquiring the lock. __vmw_fences_update() walks and removes entries from the same list under fman->lock from any other waiter, the fence-IRQ thread, or vmw_fences_update(), so the unlocked list_del_init() can corrupt the list head. Re-take fman->lock before manipulating fence->head and use dma_fence_signal_locked(). Wrap the locked signalling in dma_fence_begin_signalling() / dma_fence_end_signalling() so the lockdep annotation that dma_fence_signal() previously provided is preserved (the same pattern as __vmw_fences_update()). dma_fence_put() is moved outside the lock to avoid a recursive acquire from vmw_fence_obj_destroy(), which also takes fman->lock. Fixes: ae2a104058e2 ("vmwgfx: Implement fence objects") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-5-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 10460699c312e7a6c213478310b5ad36539b5f48 Author: Zack Rusin Date: Tue May 5 18:22:24 2026 -0400 drm/vmwgfx: clamp dirty-page range with min, not max commit f47d542d5912f236273399d7139b522f6950e2e4 upstream. vmw_bo_dirty_transfer_to_res() and vmw_bo_dirty_clear() compute the intersection of a resource's page range with the BO's tracked dirty range, but clamp res_end against dirty->end with max() instead of min(). When dirty->end exceeds the resource end, the loop walks past the resource's pages, calls vmw_resource_dirty_update() for ranges owned by other resources sharing the same backing MOB and clears their pending dirty bits via bitmap_clear(). The result is silent loss of writeback for unrelated resources whenever two resources share a MOB. Use min() in both functions so the loop is bounded to the intersection of the resource and dirty ranges. Fixes: b7468b15d271 ("drm/vmwgfx: Implement an infrastructure for write-coherent resources") Fixes: 965544150d1c ("drm/vmwgfx: Refactor cursor handling") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-4-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit e479240a1e076ba1104236331abd62400bf1d495 Author: Zack Rusin Date: Tue May 5 18:22:23 2026 -0400 drm/vmwgfx: reject DX_BIND_QUERY without a DX context commit 55ec09c9ce10b1272802c7ab6c1be2ea0dbc68db upstream. vmw_cmd_dx_bind_query() unconditionally dereferences sw_context->dx_ctx_node->ctx. Userspace can trigger a NULL pointer dereference from any render-node fd by submitting an execbuf with dx_context_handle == SVGA3D_INVALID_ID and a SVGA_3D_CMD_DX_BIND_QUERY opcode in the command stream: dx_ctx_node is left NULL and the kernel oopses on the assignment. The same NULL is then re-read in vmw_resources_reserve() via vmw_context_get_dx_query_mob(). All sibling DX handlers fail-close on a missing dx_ctx_node using VMW_GET_CTX_NODE(). Use the same pattern here, returning -EINVAL up front before any relocation state is published. Fixes: 9c079b8ce8bf ("drm/vmwgfx: Adapt execbuf to the new validation api") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-3-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 282f261cb035e5f01a486f76d356b7e9dbfba73f Author: Zack Rusin Date: Tue May 5 18:22:22 2026 -0400 drm/vmwgfx: fix guest_memory_dirty bitfield clobbered as size commit 83195b778f2d109a3a4f3ffaba4dce7e4cdb58aa upstream. Two sites in vmwgfx_resource.c assign boolean literals to res->guest_memory_size, which is an unsigned long allocation-size field; the intended target is the adjacent res->guest_memory_dirty bitfield. After the assignments the field holds 0 or 1 instead of the resource's MOB allocation size: - vmw_resource_release() writes 0 (false), and - vmw_resource_unbind_list() writes 1 (true). Subsequent revalidation paths read guest_memory_size when computing the dirty page range (vmw_bo_dirty_transfer_to_res()) and the buffer allocation size (vmw_resource_buf_alloc()), producing zero-length walks or wrap-around ranges that read or write past the MOB bitmap. The dirty-tracking intent of the original code (mark the resource as dirtied since the last sync) is also lost, since guest_memory_dirty is never updated. Rename both assignments to guest_memory_dirty. Fixes: 668b206601c5 ("drm/vmwgfx: Stop using raw ttm_buffer_object's") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.7 Signed-off-by: Zack Rusin Reviewed-by: Ian Forbes Link: https://patch.msgid.link/20260505222728.519626-2-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 6a52f48157fa7fb81e0c146937fd6c8b0c1cfdbd Author: William Palacek Date: Wed Jul 22 11:20:56 2026 -0400 drm/amdkfd: hold event_mutex while checkpointing CRIU events commit ff8bc5a68a9a70bdc38d61a72c7a49c56063f9d2 upstream. kfd_criu_checkpoint_events() counts the entries in p->event_idr via kfd_get_num_events(), allocates an array sized to that count, and then walks the same IDR to fill it. Neither the count nor the walk holds p->event_mutex. The CRIU checkpoint caller holds only p->mutex. Event create and destroy (kfd_event_create()/kfd_event_destroy()) take p->event_mutex and do not take p->mutex, so a second thread in the same process can insert or remove events between the count and the walk. If an event is inserted, the walk iterates more entries than were counted and writes past the end of the ev_privs allocation; if an event is removed, the walk dereferences an entry that is being freed. Hold p->event_mutex across the count and the walk so both observe a consistent view of p->event_idr. The lock is released before copy_to_user(), which only touches the local buffer. The caller already holds p->mutex and the create/destroy paths never take p->mutex, so the p->mutex -> p->event_mutex order is not inverted and no deadlock is introduced. Fixes: 40e8a766a761 ("drm/amdkfd: CRIU checkpoint and restore events") Signed-off-by: William Palacek Reviewed-by: Alysa Liu Signed-off-by: Alex Deucher (cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6189ceca5ce75078743db456e133efbfa2dc6fce Author: David Francis Date: Tue Jul 21 09:30:07 2026 -0400 drm/amdkfd: Handle invalid event type in CRIU event restore commit a9cdc85839e4fe2c760aa4ca6cc341c31ad1918a upstream. In kfd_criu_restore_event, there was no handling for the event priv data having an invalid event type. The priv data here is untrusted and can be invalid. In that case, fail with EINVAL. Signed-off-by: David Francis Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 2e8e9963cd5c41aa14fd5316bf9ec92e7a0e3097) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6dc0b4b39ed4f11ef70f76ecea8537e35f45342b Author: William Palacek Date: Mon Jul 20 12:51:34 2026 -0400 drm/amdkfd: fix uint32_t overflow in EOP ring buffer size alignment commit 83463a96ea3c7d8ae636a4d6a0ba63c9ce410724 upstream. eop_ring_buffer_size in struct queue_properties is a u32. In kfd_queue_acquire_buffers() the expected EOP buffer size is computed as ALIGN(eop_ring_buffer_size, PAGE_SIZE); ALIGN uses typeof(x), so the addition is done in 32-bit. A user-supplied size of 0xFFFFF001 wraps to 0, causing kfd_queue_buffer_get() to skip its exact-size check (gated on size != 0) and accept any BO mapped at the address. On GFX8/GFX9 the MQD cp_hqd_eop_control is then programmed for an 8KB EOP ring backed by a 4KB BO, so CP EOP writes can land past the buffer and fault the GPU. Cast the operand to u64 so the alignment is computed in 64-bit; the size check in kfd_queue_buffer_get() then rejects the oversized request. Fixes: 42ea9cf2f16b ("drm/amdkfd: Relax size checking during queue buffer get") Signed-off-by: William Palacek Reviewed-by: Alysa Liu Signed-off-by: Alex Deucher (cherry picked from commit ae443117b742c357bfef3a7bddabf76fcf86e9ef) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 5f0f2ddeac738e2ca9d12cb76a1ff2904e85ecc3 Author: Vladimir Marioukhine Date: Mon Jul 20 11:53:30 2026 -0400 drm/amdkfd: fix QID bit leak in pqm_create_queue() commit 38b73293f38658a4685ffcea666462024f858ad9 upstream. When MES is enabled and amdgpu_amdkfd_alloc_kernel_mem() fails during the first queue creation for a process, pqm_create_queue() returns early via 'return retval' without going through the err_create_queue cleanup label. This means clear_bit(*qid, pqm->queue_slot_bitmap) is never called, leaving the reserved QID bit permanently set in queue_slot_bitmap. Over time this leaks QID slots, potentially exhausting all available queue slots. Fix this by replacing 'return retval' with 'goto err_allocate_pqn' so that clear_bit() is always called on the error path without touching the uninitialized pqn pointer. AILIKFD-813 Reported-by: Deucher, Alexander Signed-off-by: Vladimir Marioukhine Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit a107f74c38edbb80d6ab64dcaeeb292c14e9779f) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9e52212aff8ed1fd9087728f61243ce3efd9d0ac Author: Gang Ba Date: Tue Jul 14 15:08:57 2026 -0400 drm/amdkfd: Fix missing authorization check in KFD_IOC_DBG_TRAP_DISABLE commit 99b2fe4f19e3be0a8d0a0b5ea98d855970889653 upstream. Prevent unauthorized termination of active GPU debug sessions. Previously, users with /dev/kfd access could terminate another process's debug session without proper ownership or ptrace authorization. Signed-off-by: Gang Ba Reviewed-by: Kent Russell Signed-off-by: Alex Deucher (cherry picked from commit 4db4c5ffd5585b72622ecf6ffedf2da258ee23f5) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 02647d98340738f918690ed227fdcf154db1b84a Author: Jiri Slaby (SUSE) Date: Thu Jul 23 06:25:48 2026 +0200 drm/amd/display: use proper context for logging commit 114b42507b6a23d9d24e24e4ef165233332c64d4 upstream. The same as the rest of the code, get_ss_info_from_atombios() uses calc_pll_cs->ctx->logger for logging. But calc_pll_cs->ctx is initialized only later in calc_pll_max_vco_construct(). Therefore, any output using DC_LOG_SYNC() leads to a NULL pointer deference in get_ss_info_from_atombios(). According to Sashiko, the very same problem exists in dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers() too. To avoid accessing the NULL context, use clk_src->base.ctx->logger everywhere. That context in base is initialized earlier in dce110_clk_src_construct() and dce112_clk_src_construct(). Before get_ss_info_from_atombios() or Sashiko's get_pix_clk_dividers functions above are actually called. This is done by redefining DC_LOGGER to CTX->logger. Before: dce110_clk_src_construct() did: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses calc_pll_cs->ctx # BOOM -> calc_pll_max_vco_construct() <- sets calc_pll_cs->ctx After: dce110_clk_src_construct() does: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses clk_src->base.ctx Closes: https://bugzilla.suse.com/show_bug.cgi?id=1271175 Closes: https://lore.kernel.org/all/a9ee54e6-2413-4156-9bde-d528ae3c63a3@kernel.org/ Fixes: 1296423bf23c ("drm/amd/display: define DC_LOGGER for logger") Reviewed-by: Bhawanpreet Lakha Signed-off-by: Jiri Slaby (SUSE) Cc: Lakha, Bhawanpreet Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Simona Vetter Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Alex Deucher (cherry picked from commit 6f16fcbb0c46a87e3d9685407e906573d60104b0) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3c2ae9509717c4a140ae6217dddb76d67ce947f4 Author: Ray Wu Date: Fri Jul 3 09:14:49 2026 +0800 drm/amd/display: Increase HDMI AV mute wait from 2 to 3 frames commit c216b39fbbc4b007fd6984cffd85039d49a55154 upstream. Some HDMI sinks need additional GCP packets to properly process the mute state before the timing generator is disabled, especially after link re-establishment with HDMI 2.0 scrambling enabled. Waiting for only 2 frames is insufficient for certain monitor firmware, resulting in garbled display output on resume from suspend. Increase the AV mute wait in dcn30_set_avmute() from 2 to 3 frames to ensure the sink receives enough GCP packets. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5167 Assisted-by: Cursor:Claude-Opus-4.6 Reviewed-by: Wayne Lin Signed-off-by: Ray Wu Tested-by: Dan Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 0c0d5174b09640d8b560764aa5a177630e076e93) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1860818feb4dbe413af2d53ddd539e2d93e97ca2 Author: Yang Wang Date: Thu Jul 23 23:18:33 2026 +0800 drm/amd/pm: fix torn gpu metrics reads commit 048f4541b71fb19645fb79d6e62e6e4da23a4035 upstream. amdgpu_dpm_get_gpu_metrics() returns a pointer to the shared metrics cache after dropping adev->pm.mutex. The sysfs path then copies from that pointer. Another reader can refresh the cache in place during the copy and return a snapshot containing data from two generations. Pass caller-provided storage through the DPM interface and copy the metrics while the mutex is held. This keeps the cache pointer private and makes each sysfs read observe one complete sample. Fixes: 25c933b1c4fc ("drm/amd/powerplay: add new sysfs interface for retrieving gpu metrics(V2)") Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit 862333bb48693ecafcae25af0c9d9ec31015ac77) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 45ba7f091abf4b3118da3c9d9646f8073f115a68 Author: Harkirat Gill Date: Mon Jul 27 14:37:56 2026 -0400 drm/amdgpu: cap GTT size to physical RAM on APUs commit 5e70f6804b4d6256058c360b10e044ee04ea4a4e upstream. On APUs, the GTT pool is backed by system RAM, but its size is not bound to the non-carveout memory that actually backs it. A user can end up with GTT + VRAM exceeding total physical memory through the following sequence: - Have a large non-carveout memory space (~128GB) and accordingly set a large GTT (~100GB) via the ttm module parameter. - Lower the non-carveout memory space in BIOS by increasing the UMA Frame Buffer Size (VRAM) to 64GB. - The previously set GTT value (~100GB) persists, even though the new non-carveout space (64GB) can no longer back it. This leads to a case where kernel reports GTT (100GB) + VRAM (64GB) despite the sum being greater than total physical memory (128GB). Cap the GTT size to totalram_pages() on APUs. totalram_pages() already excludes the VRAM carveout, so the resulting GTT can never exceed the system RAM that actually backs it. Signed-off-by: Harkirat Gill Reviewed-by: David Francis Assisted-by: Claude:claude-opus-4 Signed-off-by: Alex Deucher (cherry picked from commit 5dafdd649280c7dc6c22c8f877da3f54fcc441e1) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d330ac90d85f328dff61f9a11c44b35424dc3144 Author: Candice Li Date: Tue Jul 21 21:38:58 2026 +0800 drm/amdgpu: restore UMD profile pstate after runtime resume commit f931c54b241ce2f36bfc34955aec43a188276b8d upstream. Runtime suspend runs GFX hw_fini and clears perfmon clock gating while the UMD profile DPM level remains set in software. Re-apply stable pstate after a successful runtime resume when a profile mode is active. Signed-off-by: Candice Li Reviewed-by: Hawking Zhang Reviewed-by: Yang Wang Signed-off-by: Alex Deucher (cherry picked from commit 138531c8850cc247aa12b104bb29ea387bcdcbb1) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 18d21c9d04b00400054da6e21663129940637cdb Author: Pierre-Eric Pelloux-Prayer Date: Mon Jun 22 10:11:22 2026 +0200 drm/amdgpu: move debug_vm handling to amdgpu_cs_parser_fini commit d8726ef11512754a68c0ab53c57634a569b8feff upstream. The commit referenced below restarts the CS if the validation is still in progress. When debug_vm is enabled, all BOs from the CS are invalidated so we will hit an infinite loop. To avoid that, defer BO invalidation to amdgpu_cs_parser_fini. Fixes: 59720bfd8c6d ("drm/amdgpu: restart the CS if some parts of the VM are still invalidated") Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 8c990ee9daa295462df24982ce6878db997a380a) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0f1ff05c58e1740367ac3c8145ccef2ff58e9751 Author: Myeonghun Pak Date: Wed Jul 22 00:22:42 2026 +0900 drm/mediatek: ovl_adaptor: balance component registrations commit 533e3469a57996905cdb95f178e7efe38c21aeb2 upstream. The OVL adaptor registers both an aggregate driver for its child devices and a component for the main DRM aggregate. Probe currently ignores an error from registering the child aggregate and leaves that aggregate registered if registering the DRM component fails. The remove callback also leaves the DRM component registered. These imbalances can leave component framework entries referring to a device whose probe failed or whose driver has been detached. The aggregate unbind callback also fails to undo component_bind_all(), leaving its child components marked as bound when the aggregate is removed. Check the aggregate registration result, unwind it when the component registration fails, and unregister the component before the aggregate on remove. Keep runtime PM enabled until both framework registrations have been removed, and unbind all child components from the aggregate unbind callback. Fixes: 453c3364632a ("drm/mediatek: Add ovl_adaptor support for MT8195") Cc: stable@vger.kernel.org # 6.4+ Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260721152242.47138-1-mhun512@gmail.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Greg Kroah-Hartman commit c835f2b0b7167584832b516c9b0a26e9180d1d0b Author: Osama Abdelkader Date: Mon Jul 20 13:49:17 2026 +0200 drm/panthor: validate firmware interface structure sizes commit b921b8613790a3f9e78ab64017fa7149ef0b750c upstream. iface_fw_to_cpu_addr() only checks that the firmware-provided MCU virtual address points inside the shared section. The returned pointer is later used as a full firmware interface structure, so accepting an address near the end of the shared section can still lead to out-of-bounds accesses. Pass the expected object size to iface_fw_to_cpu_addr() and reject ranges that do not fit entirely in the shared section. 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/20260720114918.15973-1-osama.abdelkader@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2a761b9be5863e1d26a584f0c2d1e114a684ed9a Author: Osama Abdelkader Date: Thu Jul 16 16:39:38 2026 +0200 drm/panthor: reject firmware sections with oversized data commit a3caaa06809248b996254be5b47e10804a3494e2 upstream. In panthor_fw_load_section_entry(), the data size to copy is calculated without validating it against the allocated section_size: section->data.size = hdr.data.end - hdr.data.start; If a crafted firmware sets data.size larger than the allocated memory, this could cause a heap buffer overflow in panthor_fw_init_section_mem() memcpy(section->mem->kmap, section->data.buf, section->data.size); Additionally, if the section->data.size exceeds the BO size, could this memset underflow the size calculation, leading to a massive out-of-bounds zeroing of kernel memory? memset(section->mem->kmap + section->data.size, 0, panthor_kernel_bo_size(section->mem) - section->data.size); Reject section entries whose initial data is larger than the section size. 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: Boris Brezillon Link: https://patch.msgid.link/20260716143939.21903-1-osama.abdelkader@gmail.com Signed-off-by: Steven Price Signed-off-by: Greg Kroah-Hartman commit da898bb6faf322345a593470ba4a20a21f62584c Author: Laurent Pinchart Date: Fri Jul 17 21:48:36 2026 +0300 drm/bridge: display-connector: Fix I2C adapter resource leak commit 6a39ca1286dd97ad02bb8e03bbb65ee05368d778 upstream. If the probe function returns an error after getting the I2C adapter for DDC, the reference to the adapter is never released. Fix it by releasing it in the bridge .destroy() handler. There is no need to test the ddc pointer with !IS_ERR(), as of_get_i2c_adapter_by_node() returns NULL on error. Fixes: 2e2bf3a5584d ("drm/bridge: display-connector: add DP support") Cc: stable@vger.kernel.org Signed-off-by: Laurent Pinchart Reviewed-by: Johan Hovold Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20260717184836.2017386-1-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Luca Ceresoli Signed-off-by: Greg Kroah-Hartman commit 57667eb7548faaac396c6e39f3b4444dab5b097c Author: Maíra Canal Date: Mon Jul 27 11:32:29 2026 -0300 drm/vc4: Zero the tile state data array before each BIN job commit 48a570c964d8e37d353381e4195106277e17f5cb upstream. The binner BO is a single 16MB buffer split into 512KB slots that are handed out to jobs at submission time and recycled as jobs complete, without ever being cleared. Each slot holds the job's Tile State Data Array (TSDA) at its start, followed by the tile allocation pool. While the tile allocation pool is only walked by the render thread through branches the binner generated during the current job, the TSDA is the PTB's own per-tile bookkeeping and is consumed by the hardware itself. Although the kernel sets the "Auto-initialise Tile State Data Array" flag in the tile binning mode configuration, the PTB demonstrably still acts on stale tile state left by the slot's previous user: the binner ends up creating invalid command streams with invalid primitive streams and branches, which can cause GPU hangs as observed in [1][2]. Zero the TSDA when the job's binning slot is configured. This clears 48 bytes per tile (~24KB for a 1080p frame) in the submission path, and guarantees the PTB never sees another job's tile state. The tile count is only checked for being non-zero today, so the 8-bit fields it comes from can describe a tile state array almost six times larger than the slot it has to live in. Bound it before the slot is handed out, since such size decides how much of the slot is left for the tile alloc pool. Link: https://github.com/raspberrypi/linux/issues/3221 [1] Link: https://github.com/raspberrypi/linux/issues/5780 [2] Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.") Cc: stable@vger.kernel.org Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260727-vc4-bin-oom-fixes-v2-2-0d8a5eddc7c9@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 6cd5acf6f87c073622bd61e38fe99c47365cda9c Author: Jose Maria Casanova Crespo Date: Mon Jul 27 11:32:28 2026 -0300 drm/vc4: Supply the overflow slot size in BPOS, not the whole bin BO size commit 6395789e4739aa5177bbec0fa0f07ccc38d249b0 upstream. vc4_overflow_mem_work() points BPOA at a 512KB slot inside the 16MB binner BO, but writes the size of the whole BO to BPOS. On every binner out-of-memory event the PTB is therefore authorized to write tile lists across all the other slots (which may hold the tile state, tile alloc and overflow memory of in-flight jobs) and, for any slot but the first, past the end of the binner BO into unrelated CMA memory. Since CMA pages are recycled into page cache and user allocations, this is arbitrary memory corruption by GPU DMA. In practice it shows up as GPU hangs with corrupted control list pointers, userspace heap corruption, a GPU that stays permanently wedged after the first hang, and occasional full system crashes, whenever a job overflows the initial binner slot. The bug dates back to the conversion from a dedicated overflow BO (where writing the full BO size was correct) to the slotted binner BO. Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Jose Maria Casanova Crespo Reviewed-by: Maíra Canal Reviewed-by: Iago Toral Quiroga Link: https://patch.msgid.link/20260727-vc4-bin-oom-fixes-v2-1-0d8a5eddc7c9@igalia.com Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit 58d2bb394e88497e10fc039c0429c0f6aa762fe7 Author: Alexander Kaplan Date: Wed Jun 10 21:38:25 2026 +0200 drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs commit e40e20ac089e32f1d910636155dc82e61e61dcf3 upstream. The PCON max FRL bandwidth field lives in byte 2 of the DFP Detailed Capability Info (DPCD 0x82 for the first DFP). The DP standard defines the meaning of descriptor bytes 1-3 strictly per DFP type, and for a DisplayPort type DFP all of them are reserved, with "read all 0s" semantics (DP v2.0, section 2.12.3, Table 2-183). The FRL bandwidth field is an HDMI DFP extension added by the VESA DP-to-HDMI PCON specification. drm_dp_get_pcon_max_frl_bw() however parses the byte without checking the DFP type, the branch presence or DETAILED_CAP_INFO_AVAILABLE. Without the latter the port descriptors are one byte wide and port_cap[2] is not even the right register. All neighbouring helpers parsing the same descriptor are scoped by the DFP type already, see for instance drm_dp_downstream_max_bpc() reading the same byte and returning 0 for a DP type DFP. amdgpu's DC parses the field only for HDMI(/DP++) detailed types as well. This is not theoretical. A Synaptics VMM7100 based USB-C to HDMI adapter with a macOS targeted firmware advertises a DisplayPort type DFP with the type byte replicated across the whole descriptor (08 08 08 08). i915 decodes that as "PCON limited to 18 Gbps FRL" and prunes every mode above ~750 MHz dotclock, including all the 4k@100/120 modes the sink EDID offers, while macOS drives 4k@120 through the same adapter just fine via DP DSC (and amdgpu's type-scoped parser would ignore the bogus field as well). Only parse the field for an HDMI DFP behind a DPCD 1.1+ branch device that reports detailed cap info, matching the type-scoped field layout of the spec and the rest of the helpers. Fixes: ce32a6239de6 ("drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON") Cc: Ankit Nautiyal Cc: Uma Shankar (v2) Cc: Jani Nikula Cc: Maarten Lankhorst Cc: dri-devel@lists.freedesktop.org Cc: # v5.12+ Signed-off-by: Alexander Kaplan Reviewed-by: Ankit Nautiyal Signed-off-by: Ankit Nautiyal Link: https://patch.msgid.link/20260610193825.2933-1-alexander.kaplan@sms-medipool.de Signed-off-by: Greg Kroah-Hartman commit e8b797940536c42f4c04c623f89c6a5b65434846 Author: Avi Weiss Date: Thu Jul 23 18:55:43 2026 +0300 can: ctucanfd: mark error-active controller status valid commit 4e735cbe3affe88001428fdd9cae8e685ce92f21 upstream. In the CAN_STATE_ERROR_ACTIVE case, cf->data[1] is set to CAN_ERR_CRTL_ACTIVE, but cf->can_id is not set with CAN_ERR_CRTL in that path. Set CAN_ERR_CRTL so consumers know the controller-status information in cf->data[1] is valid. Fixes: 9bd24927e3ee ("can: ctucanfd: handle skb allocation failure") Signed-off-by: Avi Weiss Link: https://patch.msgid.link/20260723155543.318414-1-thnkslprpt@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 7d1619f56a75a2013bbfaf9e3a019137dc58b0c6 Author: Avi Weiss Date: Thu Jul 23 10:44:03 2026 +0300 can: ctucanfd: handle bus error interrupts commit e74bae899529f49c0f375307983d12e8ecad7d4b upstream. Include REG_INT_STAT_BEI in the top-level error interrupt condition. BEI is enabled when CAN_CTRLMODE_BERR_REPORTING is requested and ctucan_err_interrupt() already handles it. Without checking and clearing BEI in the top-level handler, bus error interrupts are not handled or acknowledged. Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.") Signed-off-by: Avi Weiss Acked-by: Pavel Pisa Link: https://patch.msgid.link/20260723074403.131575-1-thnkslprpt@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 46fc5aecde5cd9f9edabffc07d664b66b515fc1c Author: Avi Weiss Date: Thu Jul 23 12:59:34 2026 +0300 can: ctucanfd: unmap BAR0 using base address commit a6873910f983096746d1a2e0af94f36b8003e839 upstream. BAR0 is mapped into bar0_base, while cra_addr points to an offset within that mapping and is used for other purposes. Pass bar0_base to pci_iounmap(), instead of cra_addr, on the probe error path so the address returned by pci_iomap() is used for unmapping. Fixes: 792a5b678e81 ("can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support.") Signed-off-by: Avi Weiss Acked-by: Pavel Pisa Link: https://patch.msgid.link/20260723095934.181042-1-thnkslprpt@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit cae2880f8ffaeb3f2901301363e91ddd7c65c203 Author: Avi Weiss Date: Wed Jul 22 22:27:26 2026 +0300 can: ctucanfd: use self-test mode for PRESUME_ACK commit c31a435933f18be0f874302161333e9f16e200a0 upstream. Use self-test mode for CAN_CTRLMODE_PRESUME_ACK so transmitted frames can complete without receiving an ACK. ACK forbidden mode prevents the controller from acknowledging received frames and does not implement the presume-ack behavior. Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.") Signed-off-by: Avi Weiss Acked-by: Pavel Pisa Link: https://patch.msgid.link/20260722192726.230729-1-thnkslprpt@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit aa5e790bf185e870ee2f852ab4d9dc7d28f797fa Author: Pengpeng Hou Date: Sat Jul 4 23:19:57 2026 +0800 can: ctucanfd: add missing MODULE_DEVICE_TABLE() commit d937bdb244a751fe5967052ea2d64a7b2c476cc0 upstream. The driver has a match table for the pci bus wired into its driver structure, but the table is not exported with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE() entry so module alias information is generated for automatic module loading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the driver registration structure, and the missing module alias publication. Signed-off-by: Pengpeng Hou Acked-by: Pavel Pisa Link: https://patch.msgid.link/20260704151957.48194-1-pengpeng@iscas.ac.cn Fixes: 792a5b678e81 ("can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support.") Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 2427ef427bdd78d862c7c76597bfd9eda88b81f1 Author: Pengpeng Hou Date: Mon Jul 6 17:28:36 2026 +0800 can: peak_usb: validate uCAN receive record lengths commit 93fcab2c6968446316bbb49548848df604d6346f upstream. pcan_usb_fd_decode_buf() walks uCAN records packed in one USB receive buffer. Require each record to contain the fixed header for its type, and verify CAN payload bytes before copying them into the skb. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260706092836.79754-1-pengpeng@iscas.ac.cn Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB adapters") Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 92d0de80ca2223b9c7da78020155b6cb27824cc0 Author: Maoyi Xie Date: Wed Jun 17 02:15:31 2026 +0800 can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error commit 9b3d5a6d952c38bbcf07f903cbeadefdb56b9bc9 upstream. In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc() and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also frees the transfer buffer. If usb_submit_urb() fails, the error path frees the buffer explicitly with kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set, usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double free of the transfer buffer. BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0 Free of addr ffff8881069ccb80 by task trigger.sh/285 Call Trace: kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 Drop the redundant kfree(buf); usb_free_urb() already releases the transfer buffer. This mirrors commit 03819abbeb11 ("net: usb: lan78xx: Fix double free issue with interrupt buffer allocation"). Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core") Closes: https://lore.kernel.org/linux-can/178159320216.2154888.16953451793788581739@maoyixie.com/T/#u Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/178163373110.2507866.216458825145756798@maoyixie.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 1acab790b7cecd4e144d1d18bdfe549e282f6b0b Author: James Gao Date: Wed May 20 13:40:03 2026 +0800 can: peak_usb: add bounds check for USB channel index commit 39132f166ca8ce00ae60d8a9068e06a60943cc4b upstream. The channel control index ctrl_idx is derived from rx->len which comes directly from a device USB payload. The mask 0x0f allows values 0-15, but the array size of usb_if->dev[] is only 2. Values 2-15 cause heap out-of-bounds read, eventually causing kernel panic in the IRQ context. Add bounds checking for ctrl_idx before the array access in both pcan_usb_pro_handle_canmsg() and pcan_usb_pro_handle_error(). Fixes: d8a199355f8f ("can: usb: PEAK-System Technik PCAN-USB Pro specific part") Signed-off-by: James Gao Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/TYWPR01MB8559DBAAAA6A7F410400329CF0012@TYWPR01MB8559.jpnprd01.prod.outlook.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 2ee477e541a6d5e434d6a4041c6b677ab42e1d82 Author: Pengpeng Hou Date: Wed Jul 22 12:43:47 2026 +0800 can: softing: fw_parse(): validate firmware record spans commit 856d6cb04e5407523566b075841dcd6423757d1c upstream. fw_parse() reads a fixed record header, a firmware-provided payload, and a trailing checksum without knowing the end of the firmware blob. A truncated record can therefore make those reads exceed the blob. The same record also supplies addresses and lengths for writes into DPRAM. The generic loader uses wrap-prone mixed signed arithmetic for its bounds check, while the application loader does not bound the staging copy at all. Pass the firmware end to the parser and validate the full source record. Use a signed wide offset for generic DPRAM records and validate the application staging span against the mapped DPRAM before copying. Fixes: 03fd3cf5a179 ("can: add driver for Softing card") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260722044347.2708-1-pengpeng@iscas.ac.cn Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 185cb1fa38142a3cbf223dd8b3abb24217f330d3 Author: Pengpeng Hou Date: Wed Jul 22 12:22:21 2026 +0800 can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents commit 0293dd153f9dbc1ddf5dacdccc76b363bce4a8ee upstream. The wait and bulk receive paths walk variable-length commands from a USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be dispatched, and the wait path copies a matching command into a fixed caller-owned struct kvaser_cmd using the device-provided length. Reject nonzero commands that do not contain the fixed header or that extend beyond the current USB buffer item. In the wait path, also reject a matching command that exceeds the destination before copying it. Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260722042221.44066-1-pengpeng@iscas.ac.cn Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 2e90b2b406077e7c2a2573edc11a0c3032ba5225 Author: Abdun Nihaal Date: Wed Jul 22 16:09:03 2026 +0530 can: kvaser_usb: kvaser_usb_hydra_get_busparams(): fix memory leak in kvaser_usb_hydra_get_busparams() commit 941eaf9a6d3b33dea49f2c0a1da7546a03b6ff71 upstream. The memory allocated for cmd is not freed after the call to kvaser_usb_send_cmd() in both the normal and error paths. Fix that by adding a kfree() immediately after the call. Fixes: 39d3df6b0ea8 ("can: kvaser_usb: Compare requested bittiming parameters with actual parameters in do_set_{,data}_bittiming") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20260722103906.108571-1-nihaal@cse.iitm.ac.in Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 54258ea8d61fc2ff52e151cdecc3fb6c50dc8b8a Author: Tetsuo Handa Date: Tue Jul 28 07:58:34 2026 +0200 can: j1939: use netdevice_tracker for j1939_{priv,session,ecu} tracking commit d2fb981384b3a45f690616d550b29046e8ad16a4 upstream. syzbot is still reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem. A debug printk() patch in linux-next-20260508 identified that there is dev_hold()/dev_put() imbalance in j1939_priv management. Call trace for vcan0[26] +4 at __dev_hold include/linux/netdevice.h:4470 [inline] netdev_hold include/linux/netdevice.h:4513 [inline] dev_hold include/linux/netdevice.h:4536 [inline] j1939_priv_create net/can/j1939/main.c:140 [inline] j1939_netdev_start+0x36b/0xc10 net/can/j1939/main.c:268 j1939_sk_bind+0x853/0xb30 net/can/j1939/socket.c:506 __sys_bind_socket net/socket.c:1948 [inline] __sys_bind+0x2e9/0x410 net/socket.c:1979 Call trace for vcan0[28] -3 at __dev_put include/linux/netdevice.h:4456 [inline] netdev_put include/linux/netdevice.h:4523 [inline] dev_put include/linux/netdevice.h:4548 [inline] __j1939_priv_release net/can/j1939/main.c:166 [inline] kref_put include/linux/kref.h:65 [inline] j1939_priv_put+0x128/0x270 net/can/j1939/main.c:172 j1939_sk_sock_destruct+0x52/0x90 net/can/j1939/socket.c:388 __sk_destruct+0x8d/0x9d0 net/core/sock.c:2352 rcu_do_batch kernel/rcu/tree.c:2617 [inline] rcu_core kernel/rcu/tree.c:2869 [inline] rcu_cpu_kthread+0x99e/0x1470 kernel/rcu/tree.c:2957 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 This refcount leak in j1939_priv might be caused by a refcount leak in j1939_{session,ecu} because j1939_{session,ecu} holds a ref on j1939_priv. For further investigation using upstream kernels, enable netdevice_tracker in j1939_{priv,session,ecu} management. Signed-off-by: Tetsuo Handa Acked-by: Oleksij Rempel Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20260728055835.1151785-2-o.rempel@pengutronix.de Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 8604a3b81b9d0ceaf04fee5f52e701f623a179f9 Author: Oleksij Rempel Date: Tue Jul 28 07:58:35 2026 +0200 can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer commit eb96c58907922546e415e545fe9a14ea63b02719 upstream. Zero the allocated buffer in j1939_session_fresh_new() to ensure it contains no residual data. While there is a potential performance impact if users allocate maximum sized ETP buffers, most real-world use cases are not noticeably affected since the maximum known buffer size is typically around 65K. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Reported-by: Ji'an Zhou Message-ID: Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20260728055835.1151785-3-o.rempel@pengutronix.de Cc: stable@kernel.org [mkl: add Message-ID] Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 996eb21acdc9cac1eb6645f0aa020de98ade281a Author: Marc Kleine-Budde Date: Thu Jul 9 09:54:26 2026 +0200 can: gs_usb: gs_usb_receive_bulk_callback(): resubmit URB on skb allocation failure commit 68c5724ecd159992f76edb7b57dc508a44c8b7da upstream. If the allocation of the SKB in gs_usb_receive_bulk_callback() fails, the driver returns from the callback without resubmitting the URB in order to receive further USB in URBs. This results in a silent performance degradation which, if it occurs repeatedly, results in starvation of USB in traffic. Instead of returning immediately, try to resend the URB. If this also fails, this is logged as an info message. Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Fixes: 26949ac935e3 ("can: gs_usb: add CAN-FD support") Link: https://patch.msgid.link/20260709-gs_usb-resubmit-urb-v1-1-4dd40030cc84@pengutronix.de Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit c311f17c261fd375ddf5755f2ebe1f022c19c5b0 Author: Guangshuo Li Date: Mon Jul 6 09:46:01 2026 +0800 can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure commit 7a0cf2b2497c757c3cb1286eddf2986abb0d387b upstream. es58x_read_bulk_callback() resubmits the RX URB after processing a received packet. If the resubmit succeeds, the URB remains anchored and will be handled by the normal RX path or by teardown. However, if usb_submit_urb() fails, the callback unanchors the URB and then returns directly. This skips the existing free_urb path, so the coherent transfer buffer allocated with usb_alloc_coherent() is not released. Reuse the existing free_urb path after a resubmit failure so that the RX coherent buffer is freed before leaving the callback. Fixes: 5eaad4f76826 ("can: usb: etas_es58x: correctly anchor the urb in the read bulk callback") Signed-off-by: Guangshuo Li Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/20260706014601.415445-1-lgs201920130244@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 0b23144c59c126beb4a7761a85a194ae0fe668a5 Author: Pengpeng Hou Date: Mon Jul 6 17:27:52 2026 +0800 can: ems_usb: validate CPC message lengths commit 02925f51377f2a42a6724f00549167499c9302e5 upstream. ems_usb_read_bulk_callback() walks CPC messages packed in one USB receive buffer. Check that each declared message fits in the URB payload. Also require the type-specific payload to cover the fields used by the CAN, state, error and overrun handlers. Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260706092752.79600-1-pengpeng@iscas.ac.cn Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface") Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 26cf99713a96f3518e7829758f7212d7c83b76ae Author: Lucas Martins Alves Date: Tue Jul 14 16:48:57 2026 +0000 can: c_can: c_can_chip_config(): keep controller in init mode until bittiming is configured commit 26504844613fb44c7cab1c5f6fcff77861709baa upstream. c_can_chip_config() was programming C_CAN_CTRL_REG without CONTROL_INIT, which may allow the controller to become active before c_can_set_bittiming() finishes. That creates a short timing window where the peripheral can interact with the bus using a different/default bitrate, potentially generating bus errors and corrupting traffic. Set CONTROL_INIT together with the control-mode writes in c_can_chip_config() (normal, loopback and listen-only paths), so the controller stays halted until bit timing is fully programmed. This prevents transient bus disturbance during startup when the configured bitrate differs from the active bus bitrate. Signed-off-by: Lucas Martins Alves Link: https://patch.msgid.link/20260714164839.771123-1-lucas.alves@lumal21.com.br Fixes: 881ff67ad450 ("can: c_can: Added support for Bosch C_CAN controller") Cc: stable@kernel.org [mkl: remove space before close parenthesis] Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit affd62f5719a78135b7441aa49c8cab3c3b5e838 Author: Liem Date: Mon Jun 29 10:38:29 2026 +0800 i2c: imx: Cancel hrtimer before clearing slave pointer commit 6ac7702b6cc2b94aaed9ef2d95bfbefcdc90061f upstream. In i2c_imx_unreg_slave(), the slave pointer is set to NULL after disabling interrupts. However, a pending interrupt might already have started the hrtimer (i2c_imx_slave_timeout) before the pointer was cleared. If the hrtimer fires after i2c_imx->slave is set to NULL, the timer callback i2c_imx_slave_finish_op() will call i2c_imx_slave_event() with a NULL slave pointer, which results in a use-after-free / NULL pointer dereference. Fix by canceling the hrtimer and waiting for it to complete after disabling interrupts, before clearing the slave pointer. Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver") Signed-off-by: Liem Cc: # v5.11+ Acked-by: Carlos Song Reviewed-by: Frank Li Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260629023829.152651-3-liem16213@gmail.com Signed-off-by: Greg Kroah-Hartman commit 12a4f0950a158d98552cbaeacc35edccd8d975fa Author: Liem Date: Mon Jun 29 10:38:28 2026 +0800 i2c: imx: Fix slave registration race and error handling commit d64ec362c369bbc33833f7936d5f3a706b0d5c45 upstream. In i2c_imx_reg_slave(), the slave pointer was assigned before pm_runtime_resume_and_get(). If pm_runtime_resume_and_get() failed, the error path returned without clearing i2c_imx->slave, leaving it non-NULL and causing all subsequent registration attempts to fail with -EBUSY. Additionally, because this driver uses a shared IRQ, the interrupt handler i2c_imx_isr() can execute concurrently and, after acquiring slave_lock, dereference i2c_imx->slave. The previous fix attempt added a lockless i2c_imx->slave = NULL on the error path, but that could race with the ISR under the lock and still cause a NULL pointer dereference. Fix both issues by deferring the assignment of i2c_imx->slave and i2c_imx->last_slave_event to after a successful resume, and by performing the assignment inside the slave_lock critical section. This guarantees that the slave pointer is never left stale on the error path and is always valid when observed by the interrupt handler. Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver") Signed-off-by: Liem Cc: # v5.11+ Reviewed-by: Frank Li Acked-by: Carlos Song Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260629023829.152651-2-liem16213@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7a5db225ab5a6b095f6c37197b3b114921d85541 Author: Carlos Song Date: Mon May 25 11:04:00 2026 +0800 i2c: imx: mark I2C adapter when hardware is powered down commit 00d86dd5c2034e0e139e4806137b3b43e07ddd83 upstream. On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers. During system suspend/resume, there exists a time window between: - suspend_noirq and the system entering suspend - the system starting to resume and resume_noirq In this window, the I2C controller resources such as clock and pinctrl may already be disabled or not yet restored. If a workqueue triggers an I2C transfer in this period, the driver attempts to access I2C registers while the hardware resources are unavailable, which may lead to system hang. Mark the I2C adapter as suspended during noirq suspend and block new transfers until resume, ensuring that I2C transfers are only issued when hardware resources are available. Fixes: 358025ac091e ("i2c: imx: make controller available until system suspend_noirq() and from resume_noirq()") Signed-off-by: Carlos Song Cc: # v6.14+ Reviewed-by: Frank Li Acked-by: Oleksij Rempel Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260525030400.3182911-1-carlos.song@oss.nxp.com Signed-off-by: Greg Kroah-Hartman commit 82233ff0e36df6ce4d26c7a743954307e1f4adc9 Author: Jonas Gorski Date: Fri Jul 17 10:55:07 2026 +0200 i2c: iproc: reset bus after timeout if START_BUSY is stuck commit 98f2e9e6d6f91a6abb43f166b244b428ba85fa2b upstream. If a transaction times out, the START_BUSY signal can stay up, and subsequent transactaction attempts will fail as the bus is still considered busy. I can easily trigger this by attempting to read from an address with no device, e.g. when running i2cdetect. After the first read times out, all subsequent read attempts return busy. To get to a working state again, the controller needs to be reset to clear the START_BUSY signal. So check for START_BUSY still asserted on a timeout, and do reset in case it is, This is also done by the original non-upstream iproc-smbus driver implementation [1]. Works around situations like: bcm-iproc-2c 1803b000.i2c: transaction timed out bcm-iproc-2c 1803b000.i2c: bus is busy bcm-iproc-2c 1803b000.i2c: bus is busy bcm-iproc-2c 1803b000.i2c: bus is busy bcm-iproc-2c 1803b000.i2c: bus is busy bcm-iproc-2c 1803b000.i2c: bus is busy ... where the bus never recovers after a timeout. [1] https://github.com/opencomputeproject/onie/blob/master/patches/kernel/3.2.69/driver-iproc-smbus.patch Fixes: e6e5dd3566e0 ("i2c: iproc: Add Broadcom iProc I2C Driver") Signed-off-by: Jonas Gorski Cc: # v4.0+ Acked-by: Ray Jui Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260717085507.34209-1-jonas.gorski@bisdn.de Signed-off-by: Greg Kroah-Hartman commit 19b783335d62e7a2367436a6e1f1b37da1878360 Author: H. Nikolaus Schaller Date: Sun Jul 19 22:19:43 2026 +0200 i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock commit d99607c888f26e8a4e9fe9772860cef4aff86bb4 upstream. Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF. During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock. Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system. The jz4780 host controller clock itself is static and never changes at runtime. However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks. Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed() to use this cached value, safely decoupling active I2C transactions from the CCF internal locks without any risk of stale timings. Assisted-by web based Google AI (pinpointing the bug and writing the message). Fixes: ba92222ed63a12 ("i2c: jz4780: Add i2c bus controller driver for Ingenic JZ4780") Signed-off-by: H. Nikolaus Schaller Cc: # v4.1+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/2db6fd233aceb7238474e4833f4d25ca681c3ffb.1784492382.git.hns@goldelico.com Signed-off-by: Greg Kroah-Hartman commit 40dd7174459983efcd3b3a72aedbd17fe52b3ede Author: Wenmeng Liu Date: Thu Jun 25 17:42:45 2026 +0800 i2c: qcom-cci: drop custom suspend/resume and rely on runtime PM helpers commit b08c9857aa1f5f3a81d375d6d4bb1d8b92f22ebc upstream. cci_resume() unconditionally calls cci_resume_runtime() regardless of the runtime PM state. If the device is already runtime-suspended before system suspend, the clock is re-enabled while runtime_status remains RPM_SUSPENDED. As a result, pm_request_autosuspend() does not arm the timer, leaving the clock permanently enabled. Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver") Signed-off-by: Wenmeng Liu Cc: # v5.8+ Reviewed-by: Vladimir Zapolskiy Reviewed-by: Konrad Dybcio Reviewed-by: Loic Poulain Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260625-cci-v1-1-a100cda673ce@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman commit d9b5419df0654a2bbbee3b92a732feca6a66c8ef Author: Linmao Li Date: Thu Jul 23 10:11:40 2026 +0800 i2c: spacemit: request IRQ after controller initialization commit cdac670237258c8ca063aa8a16998f680d81b80d upstream. spacemit_i2c_probe() requests the IRQ before it enables the clocks, resets the controller and runs init_completion(). If an interrupt is already pending, the handler runs too early: it reads registers while the clocks are still off and calls complete() on an uninitialized completion. Request the IRQ after the controller and completion are initialized, but still before the adapter is registered. Fixes: 5ea558473fa3 ("i2c: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Linmao Li Cc: # v6.15+ Reviewed-by: Troy Mitchell Reviewed-by: Alex Elder Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260723021140.2293844-1-lilinmao@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 6a5cc2b4e6fafaa9e8ae5faabfeedf1265e779eb Author: Dawei Feng Date: Tue Jun 16 23:57:42 2026 +0800 ice: fix memory leak in ice_lbtest_prepare_rings() commit 3a9de5590da4ffd9e9c541c4c4d492aa2b54cf6e upstream. ice_lbtest_prepare_rings() frees Rx rings only when ice_vsi_start_all_rx_rings() fails. If ice_vsi_setup_rx_rings() fails after allocating some descriptors, or if ice_vsi_cfg_lan() fails after the Rx rings were prepared, the function reaches the Tx cleanup path without releasing the initialized Rx resources. Fix this by adding separate unwind paths for Rx setup failure and LAN configuration failure. The Rx setup failure path releases the partially prepared Rx rings before freeing Tx rings, while later failures first undo the LAN Tx configuration and then release the Rx rings in reverse setup order. 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-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have an Intel E800 Series adapter available to run the ethtool offline loopback selftest, no runtime testing was able to be performed. Fixes: 0e674aeb0b77 ("ice: Add handler for ethtool selftest") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng Reviewed-by: Jacob Keller Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 326c89ea2685a66d51d6873d443d224fbce77326 Author: Dawid Osuchowski Date: Thu May 14 18:35:55 2026 +0200 ice: fix VF interrupts cleanup commit fb096882095e5a8d6b5159e43793d4a38a0c5b1f upstream. When a virtual function sends an IRQ map command, the PF will set up interrupts according to that request. However, because these interrupts are never reset, the next time Virtual Function initializes, the interrupts are still enabled for a given VF, which leads to performance degradation in certain cases due to interrupts being unexpectedly enabled and thus causing interrupt floods. Cc: stable@vger.kernel.org Fixes: 1071a8358a28 ("ice: Implement virtchnl commands for AVF support") Suggested-by: Vladimir Medvedkin Reviewed-by: Aleksandr Loktionov Signed-off-by: Dawid Osuchowski Reviewed-by: Simon Horman Tested-by: Patryk Holda Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 7e8789f5b5d8ac16b0dfd38e50ff47bf14e84da8 Author: Aaron Ma Date: Wed Apr 29 11:48:49 2026 +0800 ice: wait for reset completion in ice_resume() commit c2816d613f388814d27bc9fd6dbd931a88056e19 upstream. ice_resume() schedules an asynchronous PF reset and returns immediately. The reset runs later in ice_service_task(). If userspace tries to bring up the net device before the reset finishes, ice_open() fails with -EBUSY: ice_resume() ice_schedule_reset() # sets ICE_PFR_REQ, returns ... ice_open() ice_is_reset_in_progress() # ICE_PFR_REQ still set, -EBUSY ... ice_service_task() ice_do_reset() ice_rebuild() # clears ICE_PFR_REQ, too late Reproduced on E800 series NICs during suspend/resume with irdma enabled, where the aux device probe widens the race window. ice 0000:81:00.0: can't open net device while reset is in progress Add a best-effort wait (10s timeout, matching ice_devlink_info_get()) for the reset to complete before returning from ice_resume(). In practice the reset completes in ~300ms. Fixes: 769c500dcc1e ("ice: Add advanced power mgmt for WoL") Cc: stable@vger.kernel.org Reviewed-by: Kohei Enju Reviewed-by: Aleksandr Loktionov Reviewed-by: Przemek Kitszel Signed-off-by: Aaron Ma Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit e0ba8eaef2a0d02a7a485e6a7157e47272b65cea Author: Ilya Maximets Date: Mon Jul 27 20:18:31 2026 +0200 net: openvswitch: fix skb leak on flow key update failure during ct commit bc62e843bc48f933da765ce47079fd992e535794 upstream. ovs_ct_execute() always steals or frees the skb on failure while ovs_flow_key_update() does not. So, if it fails and we return right away, the skb ends up leaked. Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly. This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless. Reported by Sashiko. Fixes: ec0d043d05e6 ("openvswitch: Ensure flow is valid before executing ct") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20260727181851.306076-3-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9c7246cc509fdb5877decbf2d44856577207f67c Author: Ilya Maximets Date: Mon Jul 27 20:18:30 2026 +0200 net: openvswitch: fix skb leak on flow key update failure during recirculation commit e1cf066244dad576221b7123a0e5005967f25a20 upstream. do_execute_actions() returns right away when execute_recirc() fails on the last action as it assumes this function always takes ownership of the skb when 'last' is true. But when the flow key update fails, the function doesn't free the skb and it ends up leaked. This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless. Reported by Sashiko. Fixes: 971427f353f3 ("openvswitch: Add recirc and hash action.") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20260727181851.306076-2-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 90623c9499627803ef3f04fa25a3199402d4fb95 Author: Ilya Maximets Date: Mon Jul 27 14:10:21 2026 +0200 net: openvswitch: fix potential UAF on meter attach failure commit a58a2b0ce354df531ebc71fc870058c2feb59f6b upstream. While attaching a newly created meter attach_meter() function makes the new meter visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter) on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508 Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584) ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ... netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible until all the checks are done and the function can't fail anymore. This also makes sure the "hash" value is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-31642. Fixes: c7c4c44c9a95 ("net: openvswitch: expand the meters supported number") Cc: stable@vger.kernel.org Signed-off-by: Ilya Maximets Reviewed-by: Eelco Chaudron Link: https://patch.msgid.link/20260727121022.198461-1-i.maximets@ovn.org Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 74b30e7ef46188c5f3bf1d9b4f527a2a8f0b1858 Author: Nava kishore Manne Date: Sat Jun 27 21:22:29 2026 +0530 phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB commit 7eb61caf45607e1e1270f51f8f93f0ded53146da upstream. USB Gen1 requires scrambling and 8b/10b encoding to be performed in the physical layer. Do not bypass PHY-side scrambler or encoder/decoder for USB operation, as mandated by the USB 3.x specification. Scrambler and 8b/10b bypass remain restricted to SATA and SGMII modes, where encoding is handled in the controller. Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver") Cc: stable@vger.kernel.org Signed-off-by: Nava kishore Manne Signed-off-by: Radhey Shyam Pandey Acked-by: Michal Simek Link: https://patch.msgid.link/20260627155229.2791113-4-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 79a312664118f092b95ea07a2499115121da5dbd Author: Nava kishore Manne Date: Sat Jun 27 21:22:28 2026 +0530 phy: zynqmp: use read-modify-write for SERDES scrambler bypass commit 21e0749f931702765b9d52d05740092bc87fcd8d upstream. xpsgtr_bypass_scrambler_8b10b() used xpsgtr_write_phy() which performs a full register write, silently clearing any bits beyond the intended bypass control fields. Switch to xpsgtr_clr_set_phy() with clr=mask, set=mask to set only the bypass bits while preserving the remaining bits in each register. Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver") Cc: stable@vger.kernel.org Signed-off-by: Nava kishore Manne Signed-off-by: Radhey Shyam Pandey Acked-by: Michal Simek Link: https://patch.msgid.link/20260627155229.2791113-3-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 4211450f0fecb36121ff1a35c752a9947db8c7d5 Author: Nava kishore Manne Date: Sat Jun 27 21:22:27 2026 +0530 phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask commit 6cb22477929489a412df8d153e550e77a012e701 upstream. The L0_TX_DIG_61 register bit 2 is a reserved read-only field. The previous mask value 0x0f incorrectly included bit 2, causing unintended writes to a reserved bit on every scrambler bypass operation. Correct the mask to (BIT(3) | GENMASK(1, 0)) to cover only the valid scramble bypass control bits. Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver") Cc: stable@vger.kernel.org Signed-off-by: Nava kishore Manne Signed-off-by: Radhey Shyam Pandey Acked-by: Michal Simek Link: https://patch.msgid.link/20260627155229.2791113-2-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 013a4484f061a2b41f052e25c0015203287e63f1 Author: Holger Dengler Date: Wed Jul 29 11:36:16 2026 +0200 s390/zcrypt: Validate length for CCA ECC private key requests commit a9ae0f6dd45c3ccc1d69363f7aea8af179122730 upstream. cca_ecc2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block. Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler Cc: stable@vger.kernel.org # 5.10+ Reviewed-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit ad93a1f1a45652478c0cf4eb029114e03af57f3b Author: Holger Dengler Date: Wed Jul 29 11:36:15 2026 +0200 s390/zcrypt: Validate length for CCA AES cipher key requests commit 06afe425d5283b9764303de47f554da5a808ce8a upstream. cca_cipher2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block. Fixes: 4bc123b18ce6 ("s390/zcrypt: Add low level functions for CCA AES cipher keys") Signed-off-by: Holger Dengler Cc: stable@vger.kernel.org # 5.4+ Reviewed-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit fbb0410986e8ad214121e51a4a28c3d0a10b7644 Author: Harald Freudenberger Date: Wed Jul 29 16:01:34 2026 +0200 s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() commit 01476391aecef36a3b789ee844357b22fbc90665 upstream. The helper function _ip_cprb_helper() uses internal buffer memory for building and processing CPRBs. After use this buffer was never scrubbed which could lead to leaving for example clear key material in memory which could be exposed via tricky reuse of this same memory. Extend the _ip_cprb_helper() function with another parameter 'scrub' used to steer scrubbing of this buffer. So now the caller has the opportunity to decide if scrubbing is needed or not. Extend the clear key to secure key token import process in function cca_clr2cipherkey() to tell the helper function from above to scrub the cprb buffer when the clear key value is part of the request data. Add explicit scrubbing on return from function cca_clr2cipherkey() for the random EXOR buffer and the cprb buffer. Overall this cleans the internal used buffer in case of clear key import to prevent sensitive data to get exposed. Fixes: 4bc123b18ce6 ("s390/zcrypt: Add low level functions for CCA AES cipher keys") Cc: stable@vger.kernel.org Reviewed-by: Holger Dengler Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit a57fd7fcdb63e2d5ceac78bbe825ec986062a9da Author: Harald Freudenberger Date: Wed Jul 29 13:40:09 2026 +0200 s390/zcrypt: Fix buffer over-read in cca_cipher2protkey commit 36b230835b8a008266aad22168ca52afacc8a58d upstream. Add validation of both the actual key buffer size and token length fields in all the cca_check_sec*token() functions. Additionally check in cca_gencipherkey() for possible underflow with returned key size. The CCA token structures contain user-controlled len fields that were used in operations without proper validation against both the actual buffer size and minimum token structure size. An attacker could set this field larger than the actual buffer size, leading to reading beyond buffer boundaries. This may result in a kernel crash or exposure of memory via sending this as part of a request down to the crypto card. Also an attacker could have used a very small len value and thus enforce a buffer under-run which may produce similar effects as a over-read. So now a key must - key buf length must be at least sizeof the token struct - the key len field inside the token must fit into the range of sizeof key token struct ... key buf length Fixes: 4bc123b18ce6 ("s390/zcrypt: Add low level functions for CCA AES cipher keys") Cc: stable@vger.kernel.org Reviewed-by: Ingo Franzki Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 672b12940e3f1336dfed5287412a71500adf2a76 Author: Harald Freudenberger Date: Thu Jul 23 11:54:52 2026 +0200 s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs commit 983279d7f86ade73db86f886e09172dd567031b5 upstream. There is a wrong upper limit check for the domain value when an EP11 CPRB is processed for sending to a crypto card. This check is only active on custom device nodes but may lead to access heap memory behind perms->adm when an administrative CPRB is sent. Add correct limit (AP_DOMAINS = 256) checking to fix this. Fixes: cfd68b33094e ("s390/zcrypt: Filter admin CPRBs on custom devices") Cc: stable@vger.kernel.org Reviewed-by: Finn Callies Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit e16e0fc54120cee3c6f0362de95aab6792865857 Author: Stefan Haberland Date: Mon Jul 27 16:28:40 2026 +0200 s390/dasd: Fix undersized format-check buffer commit 7f40b346462f563a0d6e841a77b5163d2a882a04 upstream. fmt_buffer_size in dasd_eckd_check_device_format() is declared as int, even though one of the multiplicands, sizeof(struct eckd_count), is a size_t. The expression trkcount * rpt_max * sizeof(struct eckd_count) is therefore correctly evaluated at 64-bit width, but the result is silently truncated when it is stored back into the 32-bit fmt_buffer_size variable. For a sufficiently large track range (start_unit/stop_unit are caller-controlled) this truncation yields a buffer size far smaller than the number of tracks actually requested. kzalloc() then succeeds with an undersized allocation, while the subsequent channel program build still operates on the untruncated track count and writes past the end of that buffer. Compute the buffer size with check_mul_overflow() and keep it in a size_t, so that a value that no longer fits results in -EINVAL instead of a silently truncated allocation size. Fixes: 8fd575200db5 ("s390/dasd: Add new ioctl BIODASDCHECKFMT") Cc: stable@vger.kernel.org #4.7 Reviewed-by: Jan Höppner Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260727142840.567286-4-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 86cdfd061509bcde84f3145f7221ba64e3e53b1f Author: Jan Höppner Date: Mon Jul 27 16:28:39 2026 +0200 s390/dasd: Fix potential NULL pointer dereference commit 9973026f572db6b67570cadc30942f3014e41079 upstream. dasd_release_space() checks the implementation of the is_ese() discipline function before calling it to determine if a given device is an ESE DASD. The current usage of the logical AND operator will lead to a NULL pointer dereference as the function is called even if the function pointer is NULL. Fix this by using the logical OR operator. Fixes: 91dc4a197569 ("s390/dasd: Add new ioctl to release space") Cc: stable@vger.kernel.org # v5.3+ Reported-by: Vasily Gorbik Acked-by: Eduard Shishkin Reviewed-by: Stefan Haberland Signed-off-by: Jan Höppner Signed-off-by: Stefan Haberland Link: https://patch.msgid.link/20260727142840.567286-3-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit bd63c7879eaa87f1958f7ee027813356fcd9ff11 Author: Aswin Karuvally Date: Thu Jul 23 16:00:50 2026 +0200 s390/qeth: Check CAP_NET_ADMIN for private ioctls commit d211028bac1bd0fff0026bfa2a8328e5b78cd0e6 upstream. Gate the SIOCDEVPRIVATE ioctl commands SIOC_QETH_ADP_SET_SNMP_CONTROL, SIOC_QETH_GET_CARD_TYPE and SIOC_QETH_QUERY_OAT with CAP_NET_ADMIN capable check to ensure unprivileged users cannot invoke them. Fixes: 18787eeebd71 ("qeth: use ndo_siocdevprivate") Cc: stable@vger.kernel.org Suggested-by: Christian Borntraeger Reviewed-by: Christian Borntraeger Reviewed-by: Alexandra Winter Signed-off-by: Aswin Karuvally Link: https://patch.msgid.link/20260723140050.762991-1-aswin@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ef1aa7cfb8c630d6bf2784d9a2541160ee0d413c Author: Niklas Schnelle Date: Wed Jul 22 15:08:34 2026 +0200 s390/pci: Fix s390_pci_mmio_write syscall error return without MIO commit b7ab86bdc65eadcfc43a0e3faf682a3f750cfb96 upstream. On a machine without PCI memory-I/O (MIO) support or when running with pci=nomio the s390 specific PCI MMIO write syscall checks if the MMIO cookie is above ZPCI_IOMAP_ADDR_BASE as a sanity check before even trying to perform the MMIO. If this check fails the return value was left unchanged and thus 0 from prior operations falsely indicating success. This could potentially confuse user-space into falsely believing the MMIO, on a mapping not valid for MMIO was successful. Fix this by setting the return value to -EFAULT prior to the check following the same pattern as elsewhere in the same function. Cc: stable@vger.kernel.org Reviewed-by: Julian Ruess Reviewed-by: Farhan Ali Fixes: a67a88b0b8de ("s390/pci: remove races against pte updates") Signed-off-by: Niklas Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit b039f13e095d28a64ca6b21d0ee5440d8b048f37 Author: Jianing Li Date: Wed Jul 1 14:10:42 2026 +0800 power: supply: max17040: handle missing status supplier commit 725668c6b6aa3971fe850659102c250d0d676e18 upstream. MAX17040 does not report charger state itself, so the driver forwards POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is registered, power_supply_get_property_from_supplier() returns -ENODEV and leaves the output value untouched. max17040_get_property() currently ignores that error and returns success, so userspace can read an uninitialized status value from the battery power supply. This happens on systems that use the fuel gauge without a charger supplier relationship in firmware. Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and propagate other supplier lookup errors. Fixes: f4b782af61ae ("power: max17040: pass status property from supplier") Cc: stable@vger.kernel.org # 6.7+ Signed-off-by: Jianing Li Link: https://patch.msgid.link/20260701061042.1008-1-m13940358460@163.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 6d89f33a646751632ab47b9f77ff1fb58c8cb054 Author: Xu Rao Date: Thu Jul 23 14:54:44 2026 +0800 power: supply: bq25890: fix the -10 C NTC lookup entry commit 160a783aa65b74782bc17cb874af1a6d3f5fba3c upstream. The TSPCT lookup table is monotonically decreasing except for ADC code 121, where the sequence reads -9.0 C, -1.0 C, -12.0 C. This makes the reported battery temperature jump upward by eight degrees for one code and then downward by eleven degrees for the next code. The entry is a missing zero: use -10.0 C so the sequence remains monotonic between -9.0 C and -12.0 C. Fixes: 9652c02428f3 ("power: bq25890: add POWER_SUPPLY_PROP_TEMP") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Link: https://patch.msgid.link/0619C8BF15F43B7C+20260723065444.1796002-1-raoxu@uniontech.com Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 63d6c855b27df5add128f8112f23cdb2aca98889 Author: Zhongqiu Han Date: Thu Jul 16 19:51:58 2026 +0800 cpufreq: schedutil: Publish util hooks only after all sg_cpu are initialized commit f0a3f042293a8c5a2152346b3637ea60866c503a upstream. Commit 16a03c71bba0 ("cpufreq: schedutil: Merge initialization code of sg_cpu in single loop") merged the per-CPU initialization and the utilization-hook registration into a single loop in sugov_start(). For a shared cpufreq policy this re-introduces the race originally fixed by commit ab2f7cf141aa ("cpufreq: schedutil: Fix sugov_start() versus sugov_update_shared() race"). The scheduler's util path reaches the hook under RCU-sched and never takes policy->rwsem, so the rwsem held across sugov_start() cannot serialize the two. Once the first CPU's hook is published, sugov_update_shared() may run and, via sugov_next_freq_shared(), read/write each sibling sugov_cpu (iowait_boost, util, bw_min, ...) concurrently with the memset() still initializing them, with no lock common to both sides: the update side holds sg_policy->update_lock while the init side holds only policy->rwsem, which the scheduler's util path never takes. The walk only accesses scalar members, never a pointer like ->sg_policy, so it does not crash today; it merely uses stale (or zero on first start) values that skew the frequency selection and tracepoints. It is still a genuine data race, and a latent crash once any pointer member is dereferenced there. Restore the two-phase approach: initialize all per-CPU structures first, and only then publish the per-CPU utilization update hooks. Fixes: 16a03c71bba0 ("cpufreq: schedutil: Merge initialization code of sg_cpu in single loop") Cc: stable@vger.kernel.org Signed-off-by: Zhongqiu Han Reviewed-by: Christian Loehle Link: https://patch.msgid.link/20260716115159.848403-1-zhongqiu.han@oss.qualcomm.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 437b38a08c0a83f09de3ce2f074bd31db6262de8 Author: Abdun Nihaal Date: Mon Jul 27 15:05:51 2026 +0530 cpufreq: powernow-k8: Fix possible memory leak in powernowk8_cpu_init() commit d5f8e5f6040d052d44fcbf4f31dd35145c0c8d7d upstream. The memory allocated for data->powernow_table inside powernow_k8_cpu_init_acpi() or find_psb_table() is not freed in one of the error paths in powernowk8_cpu_init(). Fix that by adding a kfree(). Fixes: 1ff6e97f1d99 ("[CPUFREQ] cpumask: avoid playing with cpus_allowed in powernow-k8.c") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal Acked-by: Viresh Kumar Reviewed-by: Zhongqiu Han Link: https://patch.msgid.link/20260727093553.98246-1-nihaal@cse.iitm.ac.in Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit efbcecdecefc26fa062c0e8210533ccad7d6bd4a 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 466ab0c41d5f54f71cee60619d07c4abd0ffd2cd Author: Junjie Cao Date: Thu Jul 23 09:41:29 2026 +0800 gpio: pch: use raw_spinlock_t for the register lock commit a02b8950d619123da64f69b70fe1dadef217dfe4 upstream. pch_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. This was confirmed on a PREEMPT_RT kernel with lockdep (PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored pch_irq_type()'s locking and drove it through the real genirq carrier irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), i.e. the same __irq_set_trigger() edge that __setup_irq() takes for a requested IRQ. With the original spin_lock_irqsave() edge lockdep reported an invalid wait context, immediately followed by: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro] __irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0 Switching the mirrored lock to raw_spinlock_t made both splats go away. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, but all of those critical sections only perform MMIO register accesses (ioread32()/iowrite32()) and irq_set_handler_locked(); none of them contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same class of issue and fix as recently addressed for other GPIO controllers, e.g. commit 286533cb14a3 ("gpio: sch: use raw_spinlock_t in the irq startup path") and commit 90f0109019e6 ("gpio: eic-sprd: use raw_spinlock_t in the irq startup path"). Fixes: 38eb18a6f92d ("gpio-pch: Support interrupt function") Cc: stable@vger.kernel.org Signed-off-by: Junjie Cao Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260723014129.1129730-1-junjie.cao@intel.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 2e4bc8422cdee2441f37dc3aa3e2c09395ba34cf Author: bui duc phuc Date: Mon Jul 27 15:02:05 2026 +0700 gpio: pca953x: fix cache_only and IRQ state on restore_context() failure commit d233087c19f6607ef926ac3f47d776e2406ffd1f upstream. When pca953x_restore_context() fails, cache_only is left disabled and the IRQ left enabled, even though register synchronization may not have completed successfully. Restore cache_only and disable the IRQ again on failure, matching the state set by pca953x_save_context(). Fixes: ec5bde62019b ("gpio: pca953x: Split pca953x_restore_context() and pca953x_save_context()") Fixes: 3e38f946062b ("gpio: pca953x: fix IRQ storm on system wake up") Cc: stable@vger.kernel.org Reviewed-by: Linus Walleij Signed-off-by: bui duc phuc Link: https://patch.msgid.link/20260727080205.16353-1-phucduc.bui@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 1883a09a37fed497b9efacf736c23624a472246b Author: Myeonghun Pak Date: Tue Jul 21 23:41:47 2026 +0900 i2c: amd-mp2: Unregister callback on adapter add failure commit 82048795242f04275a3f49ffc66ad851b6120954 upstream. amd_mp2_register_cb() stores the platform I2C context in the MP2 PCI driver's callback table before the adapter is registered. If i2c_add_adapter() fails, probe returns and devres frees the context, but the PCI driver can still dereference the stale pointer from its IRQ and system-sleep callbacks. Unregister the callback before returning the adapter registration error. Fixes: 529766e0a011 ("i2c: Add drivers for the AMD PCIe MP2 I2C controller") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Cc: # v5.2+ Signed-off-by: Andi Shyti Link: https://lore.kernel.org/r/20260721144147.31150-1-mhun512@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7a91d07939e07c435a79eb980eda95f71409d316 Author: Vincent Jardin Date: Thu Jul 23 17:44:56 2026 +0200 hwmon: (pmbus/core) notify on the hwmon device, not the i2c client commit a64a7e8a0b012ba81b0eadbd7afc84ab0dbfd70c upstream. pmbus_notify() calls sysfs_notify() and kobject_uevent() on the i2c client's kobject, but the alarm attributes live on the hwmon class device registered by pmbus_do_probe(). Notifying the parent i2c device is a no-op for both poll(POLLPRI) waiters and udev listeners: the named attribute does not exist on that kobject. Notify the hwmon device instead, so poll() wakes up and "change" uevents fire on the inX_alarm/tempX_alarm attributes when SMBALERT# reports a fault. Fixes: f469bde9afd1 ("hwmon: (pmbus/core) Notify hwmon events") Cc: stable@vger.kernel.org # v6.4+ Signed-off-by: Vincent Jardin Link: https://lore.kernel.org/r/20260723-fix_hwmon_notify_v1-v1-1-5a24c528686d@free.fr Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 30ae663746378471460e798bf342cf90ca4055a2 Author: Hongyan Xu Date: Wed Jul 29 18:01:16 2026 +0800 hwmon: (npcm750-pwm-fan): stop fan timer on device detach commit f27f6976ea269219c1259a7c2f8c6dfe782540a3 upstream. When a fan tach channel is present, npcm7xx_pwm_fan_probe() starts fan_timer. The timer callback polls tach state and rearms the timer, but the driver has no remove callback or devm cleanup action to stop it. On device detach, the devm-managed driver data and I/O mappings can be released while the timer is still pending or running. Register a devm cleanup action before starting the timer and shut the timer down synchronously from that action. This issue was found by a static analysis tool. Fixes: f1fd4a4db777 ("hwmon: Add NPCM7xx PWM and Fan driver") Cc: stable@vger.kernel.org Signed-off-by: Hongyan Xu Link: https://lore.kernel.org/r/20260729100116.790-1-getshell@seu.edu.cn Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 4ba5bf7ed50f235ea4581de8e7a0002f4ed287b0 Author: Asim Viladi Oglu Manizada Date: Sat Jul 25 03:21:06 2026 +0000 sctp: prevent peer transport count overflow commit bd0e9289e2642f6a5c54faad304ce0f41e926d22 upstream. sctp_assoc_add_peer() increments the association's 16-bit transport_count for every new unique peer. Adding the 65,536th transport wraps the count to zero. SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload, then copies one sockaddr_storage for every entry in transport_addr_list. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail. Reject a new unique peer when transport_count has reached U16_MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit. Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file") Cc: stable@vger.kernel.org Signed-off-by: Asim Viladi Oglu Manizada Acked-by: Xin Long Link: https://patch.msgid.link/20260725032053.521705-1-manizada@pm.me Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a0d1693923f41d6f49083aa2446686aed09d1d79 Author: Yuxiang Yang Date: Thu Jul 23 22:56:23 2026 +0000 sctp: reject stale cookies with mismatched verification tags commit 9d8da8e0a9bce4a340af60dd0446bc7eb8d07587 upstream. sctp_unpack_cookie() skips cookie expiration checks whenever an association already exists. This is broader than the exception in RFC 9260 Section 5.2.4. For an existing association, Section 5.2.4 permits an expired State Cookie only when both Verification Tags in the cookie match the current association. Otherwise, the packet SHOULD be discarded and a Stale Cookie ERROR MUST be sent. The broad check lets an expired Action A restart cookie reach sctp_sf_do_dupcook_a(). In a runtime test with the default 60 second cookie lifetime, replaying such a cookie after 65 seconds returned a COOKIE-ACK and restarted the association. Check cookie expiration unless both Verification Tags match. This preserves the Action D exception for a lost COOKIE ACK while rejecting expired cookies in all other cases. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Yuxiang Yang Acked-by: Xin Long Link: https://patch.msgid.link/20260723225623.2658868-1-yangyx22@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2047ed09bf13453b7d6f9431b112ec07984dd69b Author: Ibrahim Hashimov Date: Sun Jul 12 20:37:39 2026 +0200 scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write commit 93dde0bf2f39a0f9f57fd610aa3201ce5b753433 upstream. resp_report_zones() sizes the reply buffer from the CDB allocation length. The v3 fix rounds alloc_len up with ALIGN() before deriving the descriptor count: rep_max_zones = (ALIGN((u64)alloc_len, RZONES_DESC_HD) - RZONES_DESC_HD) >> ilog2(RZONES_DESC_HD); arr_len = (u64)RZONES_DESC_HD * (rep_max_zones + 1); For alloc_len in 0xFFFFFFC1..0xFFFFFFFF, ALIGN() rounds up to 0x100000000, so arr_len is 4 GB. On 32-bit, kzalloc()'s size_t is 32-bit and truncates 0x100000000 to 0; kzalloc(0) returns ZERO_SIZE_PTR, which passes the !arr check, and desc = arr + 64 is then dereferenced in the loop -> out-of-bounds write / panic. Clamp rep_max_zones to devip->nr_zones. The loop already stops at sdebug_capacity (after nr_zones zones), so a report can never hold more than nr_zones descriptors; the clamp does not change the report, it only bounds arr_len to (nr_zones + 1) * RZONES_DESC_HD, a real device property that can never reach 0x100000000. Fixes: 7db0e0c8190a ("scsi: scsi_debug: Fix buffer size of REPORT ZONES command") Suggested-by: Damien Le Moal Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Reviewed-by: Damien Le Moal Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260712183739.83915-1-security@auditcode.ai Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 5b4d4d5a29f92745dd1be8d3bf10013edf653cc7 Author: Chris Gellermann Date: Wed Jul 22 15:02:45 2026 +0200 selftests/clone3: fix wild pointer access of getline due to missing init commit 8f6f9fd93cd7a5dd607ad5cd910476dd68fff3ed upstream. Patch series "selftests: Add missing initalization of pointer passed to getline", v2. This patch (of 2): Clone3_set_tid uses getline(&line, ...) in a loop to read the child's process status. The code expects that getline allocates the buffer for the line on the first loop iteration. According to the Open Group Spec[1], char *line has to be null pointer for this: > ssize_t getline(char **restrict lineptr, ...); > If *lineptr is a null pointer or if the object pointed to by *lineptr > is of insufficient size, an object shall be allocated as if by malloc() > or the object shall be reallocated as if by realloc()[...]. However, char *line is only declared, leading to an undefined value that is potentially non-null. In an example run with Musl v1.2.6, the realloc call[2] of getdelim, which implements getline, triggers a segfault: ./run_kselftest.sh --test clone3:clone3_set_tid [ 1366.165898] kselftest: Running tests in clone3 ... [ 1367.799244] clone3_set_tid[811]: unhandled signal 11 code 0x1 at 0x0000000000000000 in libc.so[68184,3fbf69f000+4c000] [ 1367.802808] CPU: 0 UID: 0 PID: 811 Comm: clone3_set_tid Not tainted .. [ 1367.804188] epc: 0x0000003fbf6b0184 [ 1367.804188] ra : 0x0000003fbf6d4664 [ 1367.804188] sp : 0x0000003fce5f2e40 [ 1367.805314] gp : 0x0000002aaab0dfb8 [ 1367.805314] tp : 0x0000003fbf6f14a8 [ 1367.805314] t0 : 0x0000003fbf63d000 ... Looking at the realloc implementation, Musl mallocs for a null pointer memory. But for a non-null pointer, it assumes it's passed a valid pointer to the heap and tries to access its meta-data. This leads to the segfault we see: void *realloc(void *p, size_t n) { if (!p) return malloc(n); if (size_overflows(n)) return 0; struct meta *g = get_meta(p); ... } Fix this by properly initializing the line pointer to NULL. Link: https://lore.kernel.org/20260722130246.2135563-1-christian.gellermann@codasip.com Link: https://lore.kernel.org/20260722130246.2135563-2-christian.gellermann@codasip.com Link: https://pubs.opengroup.org/onlinepubs/9799919799/functions/getline.html [1] Link: https://git.musl-libc.org/cgit/musl/tree/src/stdio/getdelim.c#n38 [2] Fixes: 41585bbeeef9 ("selftests: add tests for clone3() with *set_tid") Signed-off-by: Chris Gellermann Acked-by: David Hildenbrand (arm) Reviewed-by: Lorenzo Stoakes Cc: Christian Brauner Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a0bc578641d74f36315803b63748eaad0a9a623f Author: Chris Gellermann Date: Wed Jul 22 15:02:46 2026 +0200 selftests/mm: fix potential wild pointer access of getline due to missing init commit 9f1d75a4ce04095afdb63d8e540092ff8151dacf upstream. This is another occurrence of using getline where the code assumes that getline allocates memory to store the line, but the pointer passed to it is uninitialized and potentially a non-null pointer. This violates the Open Group Spec[1] and caused a segfault in a similar situation in selftest/clone3/clone3_set_tid. Fix it by initializing the line pointer to NULL. The issue has been found by simply grepping through the selftest code after running into the issue in clone3_set_tid. Whether it segfaults in its current state is unknown to me. But it's good to be addressed due to defensive reasons. Link: https://lore.kernel.org/20260722130246.2135563-3-christian.gellermann@codasip.com Link: https://pubs.opengroup.org/onlinepubs/9799919799/functions/getline.html [1] Fixes: 26b4224d9961 ("selftests: expanding more mlock selftest") Signed-off-by: Chris Gellermann Acked-by: David Hildenbrand (arm) Reviewed-by: Lorenzo Stoakes Cc: Christian Brauner Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2e047b4171de4c99c73d45add36210c4a5e8abf6 Author: Vijaya Krishna Nivarthi Date: Wed Jul 22 14:53:58 2026 +0530 spi: qcom-qspi: Correct max DMA length to avoid 64K boundary failure commit 90ef2f2961c2dc55957dafe2f53b3efdb4675efc upstream. The maximum size for a DMA data descriptor is 64KB-1 because the size field in HW is 16 bits wide. For this reason, transfers fail at 64KB and beyond. Lower max_dma_len to 60KB so larger transfers are split into multiple DMA blocks and do not hit the failing 64KB boundary. 60KB is chosen as a safe round number below the 64KB-1 hardware limit while satisfying alignment requirements. Tested on x1e80100 (Hamoa) with SPI-NOR flash (/dev/mtd0): Without patch: dd if=/dev/mtd0 of=/tmp/spi_dump.bin bs=32768 count=2 # works dd if=/dev/mtd0 of=/tmp/spi_dump.bin bs=65536 count=1 # fails With patch: dd if=/dev/mtd0 of=/tmp/spi_dump.bin bs=65536 count=1 # works Fixes: b5762d95607e ("spi: spi-qcom-qspi: Add DMA mode support") Cc: stable@vger.kernel.org Signed-off-by: Vijaya Krishna Nivarthi Link: https://patch.msgid.link/20260722092358.459943-1-vnivarth@qti.qualcomm.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 581e5166f0780103dc91c0d8ebc801f9af4824b0 Author: Stanislaw Pal Date: Mon Jul 27 18:32:16 2026 +0200 spi: spi-qpic-snand: write the feature value before executing SET_FEATURE commit 8fd62901d6bf03f274a49dd0060793cc07dd51b0 upstream. qcom_spi_send_cmdaddr() programs NAND_FLASH_CMD/NAND_EXEC_CMD and submits the descriptors, which makes the controller execute the command immediately. For SPINAND_SET_FEATURE the value to be written is only placed into NAND_FLASH_FEATURES afterwards, by qcom_spi_io_op(), in a second submission - so the chip is programmed with whatever that register happened to hold from a previous operation, and the intended value is only applied by the *next* SET_FEATURE. Measured on a TP-Link Archer AX55 v1 (IPQ5018, ESMT F50L1G41LB): writing 0x40 to the configuration register (0xb0) leaves the chip at 0x00, and the subsequent write of 0x00 leaves it at 0x40 - every write lands one operation late. This stayed unnoticed until v6.18 added SPI-NAND OTP support together with OTP entries for ESMT chips. spinand_otp_rw() enables OTP mode, reads, and disables it again, and mtd_otp_nvmem_add() does this during MTD registration. With the off-by-one, the "disable" write actually applies the previously requested value, so CFG_OTP_ENABLE ends up set: the chip stays in OTP mode, every subsequent array read returns the OTP area instead of the array (UBI reports an empty device) and all writes fail with -EIO because the OTP area is write protected. On this board that makes the whole flash unusable and the device unbootable. Write the feature value into NAND_FLASH_FEATURES as part of the same transaction, before NAND_EXEC_CMD. While at it, copy only the bytes the operation actually carries - the previous code dereferenced a 4-byte pointer on a one-byte buffer (spinand->scratchbuf). With this patch the flash contents read back bit-identical to a known-good dump of the same board taken under the vendor firmware (md5-verified across partitions), and writes work. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Pal Reviewed-by: Md Sadre Alam Link: https://patch.msgid.link/20260727163216.109938-1-kuncy7@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c26a6477e149cdc7dd81915c9f3e54218fbc6bb3 Author: Masami Hiramatsu (Google) Date: Wed Jul 29 09:28:07 2026 +0900 tracing/filters: Fix false positive match in regex_match_full() commit c22c7b735f9810ad276014f788f9aa5c879ec238 upstream. regex_match_full() calls strncmp(str, r->pattern, len) where len is the target field buffer size. When len is smaller than r->len (the filter pattern length), strncmp() checks only len bytes of r->pattern against str. If those len bytes match, strncmp() returns 0, resulting in a false-positive match where a shorter string in a fixed-size field matches a longer filter pattern. For example, a 4-byte static string field containing "abcd" matched the filter pattern "abcdefgh" because strncmp("abcd", "abcdefgh", 4) returned 0. In this case, @len does NOT include '\0' because it is fixed-size array. Fix this by returning 0 (no match) early when len < r->len. Fixes: 1889d20922d1 ("tracing/filters: Provide basic regex support") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/178528488779.124250.5571741156199253769.stgit@devnote2 Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit cbb5ed3be9cae70e1c12b1991009b4e12bf4a4ca Author: Masami Hiramatsu (Google) Date: Wed Jul 29 09:27:58 2026 +0900 tracing: Check return value of __register_event() in trace_module_add_events() commit ac8719969e6c3c54e939834df812bc41f25453cf upstream. trace_module_add_events() ignores the return value of __register_event() and unconditionally calls __add_event_to_tracers() for each event. If __register_event() fails (for example, if event_init() fails), the trace_event_call is not added to ftrace_events list, but __add_event_to_tracers() still creates a trace_event_file pointing to it. If module loading subsequently fails and module memory is freed, tracing state retains a stale trace_event_call pointer in trace_event_file, leading to a use-after-free when tracefs or tracing subsystem operations are later executed. Fix this by checking the return value of __register_event() and only calling __add_event_to_tracers() if event registration succeeded. Fixes: ae63b31e4d0e ("tracing: Separate out trace events from global variables") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/178528487878.124250.14170824576025743236.stgit@devnote2 Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 205feb72e5beb3140e4e1403b6cff30cf739bab9 Author: Ming Lei Date: Sun Jul 26 09:50:25 2026 -0500 ublk: reset kernel-owned dev_info fields in ublk_ctrl_add_dev() commit e65848e4ce352bac9e3465099354c8b8f845391f upstream. ublk_ctrl_add_dev() memcpy()s the userspace ublksrv_ctrl_dev_info into ub->dev_info and then fixes up the fields the driver owns, but misses ->state and ->ublksrv_pid. A device added with ->state = UBLK_S_DEV_LIVE passes the "->state != UBLK_S_DEV_DEAD" test that ublk_stop_dev_unlocked() uses as its proxy for "a disk is attached", while ->ub_disk is still NULL, so DEL_DEV right after ADD_DEV oopses in del_gendisk(). UBLK_S_DEV_QUIESCED plus UBLK_F_USER_RECOVERY dies one step earlier, in ublk_force_abort_dev(). A poisoned ->state also gets START_USER_RECOVERY and the char device read/write path onto a device that was never started, and wedges START_DEV at -EEXIST. A poisoned ->ublksrv_pid just makes GET_DEV_INFO report an unrelated task as the ublk server. Reset both after the memcpy(), as ublk_detach_disk() does. Userspace only ever reads these back, so correcting them silently breaks nothing. ADD_DEV has copied ->state in unsanitized since ublk was merged, but back then it was harmless: the gendisk was allocated during ADD_DEV, and both teardown and the START_DEV -EEXIST check keyed off disk_live() rather than ->state. The oops became reachable once the disk allocation moved to START_DEV and those checks switched to ->state. Fixes: 6d9e6dfdf3b2 ("ublk: defer disk allocation") Cc: stable@vger.kernel.org Signed-off-by: Ming Lei Reviewed-by: Caleb Sander Mateos Link: https://patch.msgid.link/20260726145025.1507383-1-tom.leiming@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ee799977d7941dbfb11049e17edd9eaf4f8820f7 Author: Eric Dumazet Date: Thu Jul 23 14:42:48 2026 +0000 vxlan: use pskb_network_may_pull() in route_shortcircuit() commit 26bb2dd0a8839617e2c79ffbbe1923f8e4bab9fb upstream. route_shortcircuit() currently calls pskb_may_pull(skb, sizeof(struct iphdr)) (or ipv6hdr), which checks if bytes are available starting from skb->data. However, in vxlan_xmit(), skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, 20) only checks 20 bytes from skb->data (which is 14 bytes MAC header + 6 bytes of IP header), leaving the rest of the IP header potentially un-pulled in non-linear frags. Subsequent dereferences of ip_hdr(skb)->daddr can read beyond the pulled linear buffer length. Fix this by using pskb_network_may_pull(), which adds skb_network_offset(skb) to the length check to ensure the full network header is present in the linear buffer. Fixes: e4f67addf158 ("add DOVE extensions for VXLAN") Cc: stable@vger.kernel.org Signed-off-by: Eric Dumazet Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260723144249.759100-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 94dee751aad627b3645d424b5d0c736d394573e9 Author: Eric Dumazet Date: Thu Jul 23 14:42:49 2026 +0000 vxlan: use pskb_network_may_pull() for transmit path header pulls commit b9553558b48db54ac9273e6b98d7263ef5c1a329 upstream. In vxlan_xmit(), arp_reduce(), and vxlan_mdb_entry_skb_get(), pskb_may_pull() was being called to verify the availability of network layer headers (ARP, IPv6/ND, IP/IPv6 MDB keys). However, during transmit skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, len) only checks len bytes from skb->data rather than skb_network_offset(skb) + len, which can leave part of the network header in non-linear frags. Replace these remaining pskb_may_pull() calls with pskb_network_may_pull() to properly account for the MAC header offset. Fixes: e4f67addf158 ("add DOVE extensions for VXLAN") Fixes: f564f45c4518 ("vxlan: add ipv6 proxy support") Fixes: 0f83e69f44bf ("vxlan: Add MDB data path support") Signed-off-by: Eric Dumazet Cc: stable@vger.kernel.org Reviewed-by: Vadim Fedorenko Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260723144249.759100-6-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ff89415d34c3ab9f5312316423122e664ed3524f Author: Eric Dumazet Date: Thu Jul 23 14:42:47 2026 +0000 vxlan: use neigh_ha_snapshot() in route_shortcircuit() commit 8eca411347e1d38964f9ed2c8d3b6ab0e7e4473d upstream. The neighbour hardware address n->ha can be updated asynchronously by the neighbour subsystem, protected by n->ha_lock seqlock. Reading n->ha without holding the seqlock loop can lead to torn reads or reading a partially updated MAC address. Use neigh_ha_snapshot() in route_shortcircuit() to safely copy n->ha under read_seqbegin()/read_seqretry() lock protection before using it. Note that arp_reduce() and neigh_reduce() seem to have the same issue left for future patches. Fixes: e4f67addf158 ("add DOVE extensions for VXLAN") Cc: stable@vger.kernel.org Signed-off-by: Eric Dumazet Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260723144249.759100-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit adeed09eeb3b6aa52ed0109df198cb393a9fc2a1 Author: Eric Dumazet Date: Thu Jul 23 14:42:46 2026 +0000 vxlan: unclone skb head before modifying eth header in route_shortcircuit() commit 760d36e737f2b3867762f42af36c663f55babcc4 upstream. When route_shortcircuit() performs L3 short-circuit routing, it modifies the Ethernet header of the skb in-place: memcpy(eth_hdr(skb)->h_source, eth_hdr(skb)->h_dest, dev->addr_len); memcpy(eth_hdr(skb)->h_dest, n->ha, dev->addr_len); If the incoming skb is cloned (for example by packet sockets, tcpdump, or dev_queue_xmit), modifying the Ethernet header without uncloning can corrupt the packet header for other readers holding a reference to the cloned skb. Ensure the skb header is writable and unshared by calling skb_cow_head(skb, 0) prior to updating the Ethernet header. If skb_cow_head() fails, abort short-circuiting and return false to allow standard packet processing fallback. Fixes: e4f67addf158 ("add DOVE extensions for VXLAN") Cc: stable@vger.kernel.org Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260723144249.759100-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1235e017aa11cf01e91b613c4c5ed6aa28934fff Author: Eric Dumazet Date: Thu Jul 23 14:42:45 2026 +0000 vxlan: re-fetch eth header after route_shortcircuit() commit 1395a676ec15a0a02a2a6d86602324f2d5fd41d5 upstream. Before route_shortcircuit(), the eth header pointer is cached from eth_hdr(skb). Inside route_shortcircuit(), pskb_may_pull() can be called, which may reallocate skb->head. In this case, returning to vxlan_xmit() leaves the cached eth pointer pointing to freed memory, leading to a use-after-free when dereferencing eth->h_dest. Fix this by updating eth = eth_hdr(skb) after calling route_shortcircuit(). Fixes: ae8840825605 ("VXLAN: Allow L2 redirection with L3 switching") Cc: stable@vger.kernel.org Signed-off-by: Eric Dumazet Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260723144249.759100-2-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b24ba0bbffe3e23eb2f6838881c1fabcb29fb9fb Author: Matt Fleming Date: Wed Jul 22 20:19:25 2026 +0100 veth: convert frag_list skbs before running XDP commit d0d6415963040c401e7a7e4e482a698ba52448cb upstream. A frag_list skb can reach veth with data_len set but nr_frags zero. veth_convert_skb_to_xdp_buff() only converts skbs that are shared, locked, have frags[], or do not have enough headroom. It later uses skb_is_nonlinear() to decide whether to set XDP_FLAGS_HAS_FRAGS and xdp_frags_size. That exposes frag_list data to XDP as if it were stored in frags[], but frags[] is empty. AF_XDP copy mode can then trust the bogus XDP fragment metadata, walk an empty fragment entry, and crash in memcpy() from __xsk_rcv(). Route non-linear skbs through skb_pp_cow_data() before exposing them to XDP, and only advertise XDP frags when the resulting skb has frags[]. skb_copy_bits() already handles frag_list input, and skb_pp_cow_data() builds frags[] output with skb_add_rx_frag(), which is the representation XDP multi-buffer expects. Fixes: 718a18a0c8a6 ("veth: Rework veth_xdp_rcv_skb in order to accept non-linear skb") Cc: stable@vger.kernel.org Signed-off-by: Matt Fleming Reviewed-by: Toke Høiland-Jørgensen Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260722191925.2192070-1-matt@readmodwrite.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3bd35a5e272a1b7a3fb43acad9bdc599281b13fa Author: Breno Leitao Date: Wed Jul 29 07:44:40 2026 -0700 uprobes: Fix NULL pointer dereference in hprobe_expire() commit cc679d7a6303e84d769f2afcde1fc51c51f127cd upstream. Forking a task that has a pending uretprobe can oops the kernel with a NULL pointer dereference in the clone() path: BUG: kernel NULL pointer dereference, address: 0000000000000018 Oops: 0002 [#1] SMP NOPTI RIP: 0010:hprobe_expire CR2: 0000000000000018 Call Trace: uprobe_copy_process copy_process kernel_clone __x64_sys_clone do_syscall_64 entry_SYSCALL_64_after_hwframe This was found on real hosts on Meta fleet. I've got the impression that this is what is happening: CPU 1 CPU 2 (traced task) ----- ------------------- hit uprobe, prepare_uretprobe(): hprobe LEASED, refcount >= 1 uprobe_unregister() put_uprobe(): refcount -> 0 fork() -> dup_utask() hprobe_expire(hprobe, true) try_get_uprobe() -> NULL get_uprobe(NULL) <-- Oops Only take the extra reference when the uprobe is non-NULL; a NULL means it is gone and is the correct value to return. Fixes: dd1a7567784e ("uprobes: SRCU-protect uretprobe lifetime (with timeout)") Signed-off-by: Breno Leitao Signed-off-by: Peter Zijlstra (Intel) Acked-by: Oleg Nesterov Acked-by: Andrii Nakryiko Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260729-uprobe-v1-1-61896b87c867@debian.org Signed-off-by: Greg Kroah-Hartman commit 180ff4c81faf01ec4e06082c9daa7c40518ead89 Author: Michael Bommarito Date: Mon Jun 22 08:47:22 2026 -0400 um: vector: fix use-after-free in vector_mmsg_rx() commit af421e9aed3920c7ac88c24daa48606c7112feca upstream. When vector_mmsg_rx() discards a packet whose overlay header fails verify_header(), it frees the skb and continues the loop: if (header_check < 0) { dev_kfree_skb_irq(skb); vp->estats.rx_encaps_errors++; continue; } The normal and short-packet paths fall through to the bottom of the loop body, which clears the consumed slot and advances the cursors: (*skbuff_vector) = NULL; mmsg_vector++; skbuff_vector++; The verify_header() < 0 path skips that via continue, so the freed skb is left in skbuff_vector[] and the cursors do not advance. The next iteration reads the same slot, gets the freed skb, and frees it again, producing a refcount underflow / use-after-free in the RX path. Discard the slot the same way the other paths do before continuing. Only transports whose verify_header() can return negative are affected: GRE and L2TPv3 do so on a cookie/session-id mismatch (raw/tap do not), so any peer on such a transport can trigger it without authentication. Fixes: 49da7e64f33e ("High Performance UML Vector Network Driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit e4b98f9778dfca9463cab234b9996a42182fe3f3 Author: Thorsten Blum Date: Sat Jul 11 15:09:32 2026 +0200 powerpc/ps3: Fix map failure path in dma_ioc0_map_pages() commit 0bb024f11d120abff3e8db9144a585b9d7fb8459 upstream. If lv1_put_iopte() fails in dma_ioc0_map_pages(), the error path decrements iopage but keeps using the failed mapping's offset. As a result, it repeatedly tries to invalidate the failed IOPTE slot and leaves the already installed IOPTEs valid. Recompute offset and invalidate the installed IOPTEs instead. Fixes: 6bb5cf102541 ("[POWERPC] PS3: System-bus rework") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Geert Uytterhoeven Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260711130931.740719-3-thorsten.blum@linux.dev Signed-off-by: Greg Kroah-Hartman commit 4ef801b838d85c0ea5852c50667f7344ce3b6cd0 Author: Chengfeng Ye Date: Sun Jul 19 22:57:40 2026 +0800 net: pktgen: fix proc entry use-after-free commit 817ff6efdb7f484ea547218e11e17d8e43daa3b4 upstream. pktgen_change_name() replaces pkt_dev->entry while holding t->if_lock. pktgen_remove_device() removes the same entry before _rem_dev_from_if_list() takes that lock. This allows the following interleaving: CPU 0 (NETDEV_CHANGENAME) CPU 1 (kpktgend) if_lock(t) proc_remove(pkt_dev->entry) proc_remove(pkt_dev->entry) pkt_dev->entry = proc_create_data(...) if_unlock(t) The kthread can pass the stale proc_dir_entry to proc_remove() after the rename path has freed it. A reproducer with a widened race window reports: BUG: KASAN: slab-use-after-free in proc_remove+0x78/0x80 Read of size 8 at addr ffff8881478fea70 by task kpktgend_0/67 Call Trace: proc_remove+0x78/0x80 pktgen_remove_device.isra.0+0x11c/0x4c0 pktgen_thread_worker+0x1214/0x6bc0 kthread+0x2c6/0x3b0 Allocated by task 95: __proc_create+0x204/0x790 proc_create_data+0x72/0xe0 pktgen_thread_write+0xd61/0x1510 Freed by task 28: kmem_cache_free+0xcb/0x3d0 proc_free_inode+0x5b/0x80 rcu_core+0x50a/0x1850 The buggy address belongs to the object at ffff8881478fea00 which belongs to the cache proc_dir_entry of size 192 Move proc_remove() into the if_lock-protected list removal helper. Keep it before list_del_rcu() to preserve the ordering required by add_device(). The rename path must then finish replacing the entry before removal, or it observes that the device is no longer on the list. Fixes: 39df232f1a9b ("[PKTGEN]: fix device name handling") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260719145740.2888967-1-nicoyip.dev@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit dc3ab04220667f254f4348572b2a0b3febff89fb Author: Zhiling Zou Date: Fri Jul 24 00:48:52 2026 +0800 net: ipv6: clear suppressed fib6 rule result commit 6aea62e433fe1b586202a5fee8b5807ce635e1d7 upstream. fib6_rule_suppress() drops a suppressed route with ip6_rt_put_flags(), but leaves res->rt6 pointing at the released rt6_info. If no later rule supplies a replacement, fib6_rule_lookup() still sees res.rt6 and returns that stale dst to its caller. A suppressing rule can therefore leak a released route back to rt6_lookup(), and the next put hits rcuref_put_slowpath() from dst_release(). Clear res->rt6 when suppressing the route so suppressed lookups fall through to the null dst instead of reusing the released one. Fixes: cdef485217d3 ("ipv6: fix memory leak in fib6_rule_suppress") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/4b8acb7787d54e440155585dd32ebdf0bef7d122.1784710966.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0309ebbc570000ea0df11c06b69798e5860c5f6f Author: Zhiling Zou Date: Fri Jul 24 00:52:48 2026 +0800 net: bridge: stop fast-leave after deleting a port group commit a39789f211b8a4125f0c70e05b30cf715f4f187d upstream. br_multicast_leave_group() iterates mp->ports with pp = &p->next in its fast-leave path. After br_multicast_del_pg() removes p, continuing the loop advances pp through the deleted entry. If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, br_port_group_equal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group. Fast leave only needs to remove one matching port group. Break after br_multicast_del_pg() so the loop stops before dereferencing the removed entry. Fixes: 6db6f0eae605 ("bridge: multicast to unicast") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/1cf0898872ef7c72d5f4c0304414a192c6dac591.1784707712.git.zhilinz@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 332a546b4ee567d182f641fedbe8a5f24b7f3f86 Author: Breno Leitao Date: Thu Jul 16 06:42:18 2026 -0700 mm: memcg: initialize *locked in memcg1_oom_prepare() stub commit 1833ce36b35426504c64600c94f322437ea44bb2 upstream. mem_cgroup_oom() passes an uninitialized "locked" to memcg1_oom_prepare() and reads it back in memcg1_oom_finish(): bool locked, ret; ... if (!memcg1_oom_prepare(memcg, &locked)) return false; ret = mem_cgroup_out_of_memory(memcg, mask, order); memcg1_oom_finish(memcg, locked); This relies on memcg1_oom_prepare() setting *locked whenever it returns true. The CONFIG_MEMCG_V1=y version does, but the stub used when CONFIG_MEMCG_V1=n returns true without touching *locked, so memcg1_oom_finish() consumes an uninitialized value. On a memcg OOM this is reported by UBSAN: UBSAN: invalid-load in mm/memcontrol.c:1932:27 load of value 0 is not a valid value for type 'bool' (aka '_Bool') Initialize *locked to false in the stub; with cgroup v1 compiled out there is no OOM lock to take. Link: https://lore.kernel.org/20260716-memcg-oom-uninit-locked-v2-1-63631d878eb4@debian.org Fixes: e93d4166b40a ("mm: memcg: put cgroup v1-specific code under a config option") Signed-off-by: Breno Leitao Reviewed-by: Joshua Hahn Acked-by: Johannes Weiner Reviewed-by: SeongJae Park Acked-by: Shakeel Butt Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b11907c905fa08eda925395f0724b7a409870f65 Author: Link Lin Date: Tue Jul 21 00:55:33 2026 +0000 mm/page_reporting: use system_freezable_wq to fix UAF during suspend commit 0b45f6927a14914ff685fe0e6f9d11232a1e03df upstream. During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0 Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen by the PM core before this * function is called. */ Testing: I have verified these fixes using Google’s virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are no longer reproducible. Link: https://lore.kernel.org/20260721005603.1710551-1-linkl@google.com Fixes: 36e66c554b5c ("mm: introduce Reported pages") Signed-off-by: Link Lin Suggested-by: David Hildenbrand (Arm) Suggested-by: Michael S. Tsirkin Acked-by: David Rientjes Acked-by: David Hildenbrand (Arm) Acked-by: Michael S. Tsirkin Cc: Alexander Duyck Cc: Greg Thelen Cc: James Houghton Cc: Jason Wang Cc: Jiaqi Yan Cc: Vlastimil Babka Cc: Xuan Zhuo Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 63b361f228866b97e64026cae16d61b24add4c59 Author: Jens Axboe Date: Sun Jul 26 08:12:38 2026 -0600 io_uring/net: initialize mshot_len for send commit c77ffbc980efb337fd750c337d8157d532ea14e5 upstream. Commit: 6a8afb9fff64 ("io_uring/net: allow multishot receive per-invocation cap") changed how io_mshot_prep_retry() set sr->len, and added the same initialization in io_mshot_prep_retry(). But it neglected to touch the send path, which may also uses the mshot retry path. Ensure that sr->mshot_len always gets initialized correctly. Fixes: 6a8afb9fff64 ("io_uring/net: allow multishot receive per-invocation cap") Cc: stable@vger.kernel.org Reported-by: Sung Keum Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4dad8ca637d44d5a6d5c23fa80c9e2e455198c2b Author: Christian Brauner Date: Tue Jul 28 14:26:32 2026 +0200 binfmt_misc: don't let an 'F' entry pin its own instance commit 79055d82772b9584f259b747fe40ff56a076678d upstream. An entry registered with 'F' opens its interpreter at registration time and holds that file until the entry is freed. Any entry nobody removes by hand only gets closed once the binfmt_misc superblock is shut down. If the interpreter lives on a mount that keeps that superblock alive the two pin each other: binfmt_misc sb -> inode -> entry -> interp_file -> vfsmount -> binfmt_misc sb TL;DR the file is never closed. Once the mount namespace is gone there is nothing left to unregister through either. There are two ways to trigger this bug: - Point the interpreter at the instance itself. Its files are regular files owned by the mounter and both bm_get_inode() and simple_fill_super() leave i_op at empty_iops. So notify_change() falls back to simple_setattr() and chmod +x works. We never set SB_I_NOEXEC and so open_exec() accepts it. - Use the instance as an overlayfs lower layer. The overlay superblock holds a clone_private_mount() of every layer until it is destroyed and that clone is in no namespace. So umount_tree() never reaches it. That's a DoS. And it isn't only the superblock that leaks. It pins the user namespace it was mounted in, so every iteration permanently eats one of the caller's user namespace charges. So let's just do the sane thing. SB_I_NOEXEC makes open_exec() fail on the instance's own files and s_stack_depth makes overlayfs reject the layer before it ever takes a clone. That also covers the ecryptfs and fuse passthrough variants. What 'F' promises is unchanged. The stable tag is narrower than the Fixes tags on purpose. Before sandboxed mounts this needed global root against the single instance everyone shares, and the change doesn't apply to those trees anyway. Note that SB_I_NODEV is implicitly raised for userns mounts but raise it explicitly here as well. Link: https://patch.msgid.link/20260728-work-binfmt_misc-selfpin-v1-1-74df5daeca5b@kernel.org Fixes: 948b701a607f ("binfmt_misc: add persistent opened binary handler for containers") Fixes: 21ca59b365c0 ("binfmt_misc: enable sandboxed mounts") Cc: stable@vger.kernel.org # v6.7+ Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 840bb9c49c3e75fb32b593d67ab32f6b77122262 Author: Christian Brauner Date: Fri Jul 10 11:33:04 2026 +0200 binfmt_misc: reject a flag character as the field delimiter commit 8e85d50ba1117fd446bf9a250bd8a97d48384bdc upstream. The registration string starts with a user chosen delimiter that separates the individual fields. So that the field parsers terminate even on a truncated string create_entry() pads the buffer with that same delimiter: memset(buf + count, del, 8); Most fields are scanned for the delimiter with strchr()/scanarg() and happily stop on the padding. The flags field is different: instead of scanning for the delimiter check_special_flags() consumes the flag characters 'P', 'O', 'C' and 'F' and stops at the first byte that is none of them, relying on the trailing delimiter to end the scan. If the delimiter is itself a flag character the padding no longer acts as a terminator. The scan swallows all eight padding bytes and keeps reading past the end of the allocation until it hits a byte that is not a flag character. For example registering PaPEPPxPPiP with 'P' as the delimiter (name "a", type extension, magic "x", interpreter "i", empty flags) leaves the flag scan running off the end of the buffer. The registration is rejected in the end because the parser does not stop exactly at buf + count, but only after the out of bounds read has already happened. With an unlucky allocation layout the scan can walk into an unmapped page; under KASAN it is reported as a slab out of bounds read. binfmt_misc mounts are available to unprivileged users in a user namespace so the read is reachable without privileges. Reject a delimiter that is one of the flag characters up front. Such a registration was always rejected anyway, only after the out of bounds read, so no valid registration string changes meaning. Link: https://patch.msgid.link/20260710-work-binfmt_misc-locking-v3-3-a162f7cb58d6@kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 255a758697da87a205e072e0cfc35897b8f743b1 Author: Christian Brauner Date: Fri Jul 10 11:33:03 2026 +0200 binfmt_misc: use exe_file_deny_write_access() for the interpreter clone commit fa5990ca8fd917003e526036bcc50413edb9722c upstream. For MISC_FMT_OPEN_FILE entries load_misc_binary() clones the registered interpreter file and denies write access to the clone via plain deny_write_access(). The clone is installed as bprm->interpreter and later released by the exec machinery through exe_file_allow_write_access() which skips the i_writecount increment for files with FMODE_FSNOTIFY_HSM set. The deny and allow side can therefore come to different conclusions when pre-content watches are in play: if a pre-content watch is added to the interpreter after registration every subsequent exec through that entry takes a write denial on the clone that is never paired with a write allowance, driving the interpreter inode's i_writecount further down with each exec and leaving the interpreter unwritable even after the entry and all its users are gone. Take the write denial via exe_file_deny_write_access() so both sides of the pairing base their decision on the same file mode, and propagate failure instead of silently ignoring it: an interpreter that is concurrently open for writing now fails the exec with ETXTBSY, exactly like an interpreter freshly opened via open_exec() would. Link: https://patch.msgid.link/20260710-work-binfmt_misc-locking-v3-2-a162f7cb58d6@kernel.org Fixes: 0357ef03c94e ("fs: don't block write during exec on pre-content watched files") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit fdc1d702bf3001586221fa07e598e876a0a854c5 Author: Christian Brauner Date: Fri Jul 10 11:33:02 2026 +0200 binfmt_misc: restore write access when removing an entry commit db1856ea9196cf6e015d12199a34c0b9313c7bfa upstream. Registering an entry with the MISC_FMT_OPEN_FILE flag opens the interpreter via open_exec() which denies write access to it for as long as the entry exists. Removing the entry closes the interpreter file via filp_close() but never restores write access, leaving the inode's i_writecount permanently negative. Opening the interpreter for writing keeps failing with ETXTBSY long after the entry is gone until the inode is evicted from the inode cache. Commit 90f601b497d7 ("binfmt_misc: restore write access before closing files opened by open_exec()") fixed the same imbalance in the error path of bm_register_write() but the actual removal path has been leaking the write denial since the introduction of the flag. Restore write access in put_binfmt_handler() before closing the interpreter file. Link: https://patch.msgid.link/20260710-work-binfmt_misc-locking-v3-1-a162f7cb58d6@kernel.org Fixes: 948b701a607f ("binfmt_misc: add persistent opened binary handler for containers") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit c9dcfe6b8b71369e1d732e2ff622c3696a2f032c Author: Zhao Li Date: Tue Jul 28 19:53:25 2026 +0800 wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames commit 99a948382af8a225e2d5e54a7052158cd6281cc6 upstream. mwifiex_11n_dispatch_amsdu_pkt() splits an A-MSDU with ieee80211_amsdu_to_8023s() and walks the resulting subframes. For each subframe it passes the subframe data pointer to mwifiex_process_tdls_action_frame(), but pairs it with skb->len, the length of the A-MSDU parent, instead of rx_skb->len: rx_skb = __skb_dequeue(&list); rx_hdr = (struct rx_packet_hdr *)rx_skb->data; if (ISSUPP_TDLS_ENABLED(priv->adapter->fw_cap_info) && ntohs(rx_hdr->eth803_hdr.h_proto) == ETH_P_TDLS) { mwifiex_process_tdls_action_frame(priv, (u8 *)rx_hdr, skb->len); } The parent is not a valid description of that buffer, and may not be valid memory at all. ieee80211_amsdu_to_8023s() ends with if (!reuse_skb) dev_kfree_skb(skb); and it only sets reuse_skb when the parent is linear, is not a head_frag, and is being consumed as the *last* subframe. So when the parent does not qualify for reuse it has already been freed, and the read of skb->len is a use-after-free. When it is reused, skb->len is the length of the last subframe, applied to every earlier subframe, which over-states the buffer whenever an earlier subframe is shorter. The callee cannot absorb a wrong length, because it derives its own ceiling from the value it is given. Each frame type computes ies_len = len - sizeof(struct ethhdr) - TDLS_*_FIX_LEN; and the element walk is then bounded entirely against that ceiling, for (end = pos + ies_len; pos + 1 < end; pos += 2 + pos[1]) { u8 ie_len = pos[1]; if (pos + 2 + ie_len > end) break; so a too-large len moves end past the end of the subframe and the walk reads and copies beyond it. The A-MSDU layout is chosen by the sender, which makes the difference between the last subframe and a shorter earlier one remotely selectable. Reaching this requires TDLS support in firmware and the TDLS ethertype on the subframe. The other caller, mwifiex_process_rx_packet(), is correct: it passes a pointer and a length that describe the same region of the RX buffer. Pass rx_skb->len, the length of the subframe actually being parsed. Fixes: 776f742040ca ("mwifiex: fix AMPDU not setup on TDLS link problem") Assisted-by: Codex:gpt-5.6-sol Assisted-by: Kimi:K3 Cc: stable@vger.kernel.org Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260728115325.19128-1-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit bed792737b5f1ba773054dbe984502958bdfe6ce Author: Zihan Xi Date: Fri Jul 24 00:38:41 2026 +0800 tipc: avoid use-after-free in poll trace queue dumps commit b4f1719dfea023220e0e6bd892b087d76b2a6a49 upstream. TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most queue-dump callsites already serialize that walk under the socket lock or sk->sk_lock.slock, but tipc_poll() calls trace_tipc_sk_poll(..., TIPC_DUMP_ALL, ...) without holding either lock. That lets the poll trace path reach tipc_list_dump() and backlog head/tail dumping while another context dequeues and frees an skb, leaving the trace helper dereferencing a stale queue entry. Stop the unlocked poll trace site from requesting queue dumps. Other queue dump trace callsites keep their existing output under the locking they already provide, while poll still emits the event itself without walking live queue members from an unlocked context. Fixes: b4b9771bcbbd ("tipc: enable tracepoints in tipc") Cc: stable@vger.kernel.org Reported-by: Vega Signed-off-by: Zihan Xi Signed-off-by: Ren Wei Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/f8119abd5e5ecc400597de667ae9d39656de56d0.1784794294.git.zihanx@nebusec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 88752b811f72aa7a16de6dad4b25031d7308673e Author: Carlo Caione Date: Mon Jul 27 10:36:59 2026 +0200 of/address: Fix NULL bus dereference in of_pci_range_parser_one() commit bba13ad17b1a11b3f1ed9b3a5d556191d7755a59 upstream. The bus matching rework made of_match_bus() return NULL for nodes with ranges/dma-ranges but no local #address-cells. parser_init() stored that NULL bus, and the range iterator later dereferenced it. Reject such nodes in parser_init(), leaving an explicit empty iterator for callers that ignore the init return, and make of_dma_get_max_cpu_address() honour the init failure so a rejected node cannot clamp the DMA limit. Fixes: 64ee3cf096ac ("of/address: Rework bus matching to avoid warnings") Cc: stable@vger.kernel.org Signed-off-by: Carlo Caione Link: https://patch.msgid.link/20260727-of-range-parser-null-bus-v3-1-be01b708a4ce@baylibre.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Greg Kroah-Hartman commit 4ae701848e4ba9e9713375fb7d82218cbd309da2 Author: David Lee Date: Mon Jul 13 09:59:15 2026 +0000 netfilter: ipset: do not update comments from kernel-side hash adds commit f30415929be8aeb002d557c8d3f7ab2d2188003a upstream. mtype_resize() copies comment pointers with memcpy(), not the comment objects themselves. During the window after an entry has been copied but before the table swap and backlog replay, the old table is still published for packet-side updates while the replacement-table entry already holds the same ip_set_comment_rcu pointer. If xt_SET --add-set ... --exist hits that old entry in this window, mtype_add() calls ip_set_init_comment() even though packet-side adds carry no comment payload. That call frees the shared comment through the old entry, so the replacement-table entry now holds a stale pointer. When the queued add is replayed on the new table, mtype_add() calls ip_set_init_comment() again and strlen() dereferences the stale pointer. Fix this in mtype_add() by skipping ip_set_init_comment() when ext->target marks a packet-side add. Userspace adds still update comments, while packet-side adds can no longer free comment storage shared with a resize copy. Fixes: f66ee0410b1c ("netfilter: ipset: Fix "INFO: rcu detected stall in hash_xxx" reports") Cc: stable@vger.kernel.org Signed-off-by: David Lee Assisted-by: Codex:gpt-5.5 Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit f807a63d0d95680c34f677700da9148a07d7c78f Author: Xuanqiang Luo Date: Thu Jul 23 18:54:54 2026 +0800 net/smc: fix socket use-after-free during link group termination commit f621d6ebeebb6374342571e4ddf45fdbc420f6cd upstream. __smc_lgr_terminate() drops conns_lock after finding a connection in lgr->conns_all, but before taking a reference on its socket. The connection is embedded in the socket, and its registration reference protects it only while the connection remains in the tree. A concurrent close can unregister the connection and drop that reference, freeing the socket before the termination worker reaches sock_hold(). The race is reachable when close overlaps link group termination. Local stress testing reproduced the use-after-free and KASAN reported: BUG: KASAN: slab-use-after-free in __smc_lgr_terminate.part.0 [smc] Write of size 4 by task kworker/3:3 Workqueue: events smc_lgr_terminate_work [smc] __smc_lgr_terminate.part.0 [smc] The socket was allocated by smc_create(), freed through slab_free_after_rcu_debug(), and was followed by: refcount_t: addition on 0; use-after-free. __smc_lgr_terminate.part.0 [smc] Take the socket reference while conns_lock still protects the tree entry. The unregister path then cannot drop the last reference until termination has finished using the socket. Fixes: 69318b5215f2 ("net/smc: improve abnormal termination locking") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Reviewed-by: Mahanta Jambigi Link: https://patch.msgid.link/20260723105454.87016-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 2060764e0f46c3af8dc43996a790a7c2e09191d7 Author: Wei Liu Date: Tue Jun 30 14:57:54 2026 -0700 mshv: fix hv_input_get_system_property struct commit d6f0248f04a96249660591e47fcf37ba98ac7ea3 upstream. Keep it in sync with the correct definition. The old code worked by chance. Fixes: e68bda71a2384 ("hyperv: Add new Hyper-V headers in include/hyperv") Cc: stable@kernel.org Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman commit a60b5da05e318d9a364dbac38c347c7f24e625e7 Author: Namjae Jeon Date: Thu Jul 23 23:07:14 2026 +0900 ksmbd: reject repeated SMB2 NEGOTIATE requests commit cb469993b3a61a72653770856d37af616d72d05f upstream. Unauthenticated client can send multiple successful SMB2 NEGOTIATE requests on one connection before SESSION_SETUP. While the connection is in KSMBD_SESS_NEED_SETUP, smb2_handle_negotiate() accepts another SMB3.1.1 NEGOTIATE and overwrites conn->preauth_info with a new allocation. Only the final allocation is freed when the connection is released, leaking one object for every additional successful request. A repeated SMB2 NEGOTIATE after a dialect has been selected is a protocol violation. MS-SMB2 section 3.3.5.4 requires the server to disconnect without replying in this case. Set the connection exiting when rejecting the request, in addition to suppressing the response. Reject SMB2 NEGOTIATE unless the connection is new or is waiting for the SMB2 NEGOTIATE that follows an SMB1 multi-protocol negotiate. Serialize both SMB1 and SMB2 negotiation paths under conn->srv_mutex, since they update connection-wide dialect and negotiation state. Move the locking contract to ksmbd_smb_negotiate_common(), where the state and dialect are selected, and add ksmbd_conn_new() for consistent state access. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Reported-by: Runa Takemoto Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b5ee5b266f833601ac4817f6df0bc496fc376a28 Author: Zhiling Zou Date: Mon Jul 13 19:52:32 2026 +0800 ipvs: do not propagate one-packet flag to synced conns commit a63d2dbaeb50a85d4c976b15a36e6b0c7113db5b upstream. Synced connections can be created before their destination exists. When the destination is later added, ip_vs_bind_dest() copies connection flags from the destination into cp->flags. IP_VS_CONN_F_ONE_PACKET connections are not synced. If a synced connection inherits IP_VS_CONN_F_ONE_PACKET while it is already hashed, expiry can treat it as a one-packet connection and skip unlinking the existing conn_tab node, leaving stale hash nodes pointing at a freed struct ip_vs_conn. Drop IP_VS_CONN_F_ONE_PACKET from destination flags when binding synced connections. Fixes: 26ec037f9841 ("IPVS: one-packet scheduling") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Suggested-by: Julian Anastasov Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 3b5aee6fcbf6b58112d40d19c8d31fa3f78ee668 Author: David Carlier Date: Sun Jul 12 14:22:42 2026 +0100 igc: remove napi_synchronize() in igc_down() commit 5ffab5b9589c50e4cfc0cf36ffd76c89422d4019 upstream. When an AF_XDP zero-copy application is killed abruptly, the XSK pool is torn down but NAPI keeps polling. igc_clean_rx_irq_zc() then returns the full budget on every poll, so napi_complete_done() never clears NAPI_STATE_SCHED. igc_down() calls napi_synchronize() before napi_disable(), so it spins forever waiting for that bit and the interface never goes down. Drop the napi_synchronize() and let napi_disable() do the job -- it sets NAPI_STATE_DISABLE, which forces the stuck poll to complete. Reorder it ahead of igc_set_queue_napi() so the NAPI mapping is cleared only after polling has stopped, matching the recent igb fix b1e067240379. Fixes: fc9df2a0b520 ("igc: Enable RX via AF_XDP zero-copy") Suggested-by: Maciej Fijalkowski Cc: stable@vger.kernel.org Signed-off-by: David Carlier Reviewed-by: Maciej Fijalkowski Reviewed-by: Dima Ruinskiy Tested-by: Moriya Kadosh Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit 845a9cdd9b03b7b6fa8de3ee80579780350a7f65 Author: Matt Vollrath Date: Thu Apr 16 23:34:52 2026 -0400 igbvf: Fix leak in TX DMA error cleanup commit 0565052b7e2f436b7f1541f4849da96dc0aa7a0e upstream. If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented before each frag mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping (the head) would leak. This bug was introduced by a 2010 fix for an endless loop in dma_error. All other affected drivers have already been fixed. Fixes: c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-4-7-opus Signed-off-by: Matt Vollrath Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit b10bb77e91e9702575af719a4d511f8754a3f739 Author: Dawei Feng Date: Sun Jun 7 22:57:06 2026 +0800 e1000: fix memory leak in e1000_probe() commit 816419dfea5c88126f35eb7a1b429a1bf546665e upstream. In the e1000_probe() path, e1000_sw_init() allocates adapter->tx_ring and adapter->rx_ring. If the subsequent CE4100-specific MDIO BAR mapping fails, the error handling jumps past the ring cleanup code, leaking both allocations. Fix this leak by moving the err_mdio_ioremap label above the ring deallocation logic. This guarantees the proper release of these resources and prevents the memory leak. 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-rc6. An x86_64 allyesconfig build showed no new warnings. As we do not have a CE4100 reference platform to test with, no runtime testing was able to be performed. Fixes: 5377a4160bb65 ("e1000: Add support for the CE4100 reference platform") Cc: stable@vger.kernel.org Signed-off-by: Zilin Guan Signed-off-by: Dawei Feng Reviewed-by: Dima Ruinskiy Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit b0bdca3a49cf31db4abf7fcb995d14a1f4188b8b Author: Md Sadre Alam Date: Mon Jun 15 11:39:08 2026 +0530 dmaengine: qcom: bam_dma: Fix command element mask field for BAM v1.6.0+ commit 867621ba203027338b525af6729719c544135336 upstream. BAM version 1.6.0 and later changed the behavior of the mask field in command elements for read operations. In older BAM versions, or prior implementation assumptions, the mask field was effectively ignored for read commands. However, starting from BAM v1.6.0, the mask field for read commands is repurposed to carry the upper 4 bits of the destination address, enabling support for 36-bit addressing. For write commands, the mask field continues to function as a traditional write mask. The current driver sets mask = 0xffffffff for all command elements. While this works for write operations, it breaks read operations on BAM v1.6.0+ hardware. In such cases, the hardware interprets the upper address bits as 0xf, resulting in an invalid destination address (0xf_xxxxxxxx instead of 0x0_xxxxxxxx). This leads to failures such as NAND enumeration issues observed on platforms like IPQ5424. Fix this by assigning the mask field based on command type: - For read commands: set mask = 0 (upper address bits = 0) - For write commands: retain mask = 0xffffffff Also update the bam_cmd_element structure documentation to reflect the dual purpose of the mask field across BAM versions. This ensures correct behavior on BAM v1.6.0+ while maintaining backward compatibility with older hardware. Fixes: dfebb055f73a2 ("dmaengine: qcom: bam_dma: wrapper functions for command descriptor") Tested-by: Lakshmi Sowjanya D Signed-off-by: Md Sadre Alam Reviewed-by: Frank Li Reviewed-by: Dmitry Baryshkov Cc: stable@vger.kernel.org Signed-off-by: Varadarajan Narayanan Link: https://patch.msgid.link/20260615060908.1263171-1-varadarajan.narayanan@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 2db4535d6af79276a64449201c5be5feffb31c64 Author: Sonali Pradhan Date: Tue Jul 28 20:24:32 2026 +0000 ALSA: usb-audio: Clamp frame size in implicit-feedback mode commit 8d7a30c50c2e58a6839634ed0acde14466d1dc61 upstream. snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's stride and stores the result directly in out_packet->packet_size[i]. If a connected USB device sends an oversized sync packet, this frame count can exceed ep->maxframesize. The un-clamped frame count then propagates to the playback endpoint queue, potentially driving packet transfers beyond the endpoint's hardware frame limits. Cap the calculated frame count against ep->maxframesize in snd_usb_handle_sync_urb() to prevent oversized packets from entering the playback queue. Fixes: 28acb12014fb ("ALSA: usb-audio: use sender stride for implicit feedback") Cc: stable@vger.kernel.org Assisted-by: Jetski:Gemini-3.6-Flash Signed-off-by: Sonali Pradhan Link: https://patch.msgid.link/20260728202432.2354994-1-sonalipradhan@google.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 04595233e5606d452f9f47e6989fc7ae7440fd40 Author: Sonali Pradhan Date: Tue Jul 28 20:17:16 2026 +0000 ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set commit d0199ae1666ff9ae2d1d568d64c3430d4c47f0e5 upstream. When a USB audio endpoint requests full packet transfers via the fill_max descriptor flag, data_ep_set_params() promotes ep->curpacksize to ep->maxpacksize. However, maxsize is left at the original sample-rate derived value. Since u->buffer_size is allocated as maxsize * packets, the resulting DMA buffer is far too small for the requested transfer length. When the USB host controller streams up to curpacksize bytes per packet, it writes past the end of the buffer via DMA, corrupting kernel heap memory. Update maxsize to curpacksize when fill_max is set so that the allocated DMA buffer size matches the actual transfer request size. [ changed to reassign maxsize only when ep->fill_max is set -- tiwai ] Fixes: 8fdff6a319e7 ("ALSA: snd-usb: implement new endpoint streaming model") Cc: stable@vger.kernel.org Assisted-by: Jetski:Gemini-3.6-Flash Signed-off-by: Sonali Pradhan Link: https://patch.msgid.link/20260728201716.2347726-1-sonalipradhan@google.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b5305a0d0bb8e90a6fc9f88270d5f6c9b8c40081 Author: Baul Lee Date: Sun Jul 26 16:45:00 2026 +0900 ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output() commit 0970274613fb463d376211450cab066d34ebfe6a upstream. snd_usbmidi_akai_output() computes its fill-loop bound buf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1; as a signed int, so a small device-advertised bulk-OUT max_transfer makes buf_end negative. The loop guard then compares the u32 urb->transfer_buffer_length against that negative int: the usual arithmetic conversion turns buf_end into a large unsigned value, so the guard stays true and each iteration keeps appending SysEx framing and payload bytes past the end of the URB transfer buffer, which is only max_transfer bytes long. A USB device that advertises a tiny bulk-OUT endpoint can therefore trigger an attacker-length- and content-controlled heap out-of-bounds write when a process writes to the created /dev/snd/midiC*D* node. Return early when there is no room for even one SysEx, so the loop is never entered with a bound that would wrap. The loop is the last statement of the function, so bailing out is equivalent to it not running. Discovered by XBOW, triaged by Baul Lee Fixes: 4434ade8c933 ("ALSA: usb-audio: add support for Akai MPD16") Suggested-by: Takashi Iwai Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260726074500.50145-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7ba01e0d3539d9cf0aef3e82938f1648147744cc Author: Baul Lee Date: Sun Jul 26 15:50:20 2026 +0900 ALSA: usb-audio: fix stack info leak in RME Digiface status commit 441aaad150c57edaf57ee482a79a3bf4c5b7e353 upstream. snd_rme_digiface_read_status() reads a four-word status block from the device into an uninitialised on-stack __le32 buf[4] and, whenever the vendor control-IN transfer does not return a negative error, copies all four words into the caller's status[]. snd_usb_ctl_msg() copies the full requested size back into the caller's buffer regardless of how many bytes the data stage actually delivered: buf = kmemdup(data, size, GFP_KERNEL); err = usb_control_msg(dev, pipe, request, requesttype, value, index, buf, size, timeout); memcpy(data, buf, size); usb_control_msg() returns the transferred length on a short control-IN, which is a non-negative value, and writes only that many bytes. The remainder of the copy back is the kmemdup()ed image of the caller's buffer, so a device answering with a short data stage leaves the trailing words of buf[] holding leftover kernel stack. The only guard in the caller is err < 0, so those words are stored into status[]. They then reach user space: snd_rme_digiface_get_status_val() selects a 16-bit halfword of status[] per the control's reg/mask, and the eight Digiface status controls together expose the whole 16-byte frame to an unprivileged reader of /dev/snd/controlC*. Zero-initialise the buffer so a short read yields zeros instead of stack residue. This mirrors snd_rme_get_status1(), which already clears its output word before the same kind of vendor read. Discovered by XBOW, triaged by Baul Lee Fixes: 611a96f6acf2 ("ALSA: usb-audio: Add mixer quirk for RME Digiface USB") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260726065020.46070-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cc014ebf803174f0e5d15956dfc5a38413c945ae Author: Baul Lee Date: Sun Jul 26 14:13:37 2026 +0900 ALSA: usb-audio: fix use-after-free in ump_to_endpoint() commit 4a05b2d1b4642df74f30b6f54843e825c4a2bfd3 upstream. create_midi2_ump() registers a card-owned snd_ump_endpoint and stores a back-pointer to its per-interface snd_usb_midi2_ump object in ump->private_data, but it never installs an ump->private_free hook and never clears that pointer. If a later step of snd_usb_midi_v2_create() fails, its error path calls free_all_midi2_umps(), which kfree()s the snd_usb_midi2_ump object while the already-registered endpoint keeps pointing at it. The created /dev/snd/umpC*D* node stays exposed, so the first operation of any UMP open, ump_to_endpoint(), dereferences the dangling ump->private_data and reads rmidi->eps[dir] out of freed memory. A malicious USB MIDI 2.0 device that makes creation fail after the endpoint is registered can thus trigger a slab use-after-free read on a subsequent open of the UMP node. Clear the endpoint's back-pointer before freeing the object, and let ump_to_endpoint() tolerate a NULL private_data so the open/close/trigger callbacks fail cleanly (their callers already handle a NULL endpoint) instead of dereferencing a stale pointer. Discovered by XBOW, triaged by Baul Lee Fixes: ff49d1df79ae ("ALSA: usb-audio: USB MIDI 2.0 UMP support") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260726051337.41124-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 79f8720029f261371796c6ce3219074ac614c58f Author: Niklas Cassel Date: Tue Jul 28 13:38:42 2026 +0200 ata: libata-sata: fix ata_scsi_lpm_supported() iteration commit 3fd70e96914d761c17c376aadd0b0d1a3c9badba upstream. The inner loop of ata_scsi_lpm_supported() uses the wrong variable when iterating. It should obviously use the link that we are currently iterating over, rather than always using the host link. ata_scsi_lpm_supported() is used to control if a user should be allowed to change lpm policy (from the default) via sysfs. Thus, this bug could potentially disallow users to change the LPM policy for certain SATA devices via sysfs. Cc: stable@vger.kernel.org Fixes: 0060beec0bfa ("ata: libata-sata: Add link_power_management_supported sysfs attribute") Reported-by: Sashiko Link: https://lore.kernel.org/linux-ide/20260728112200.B99F21F000E9@smtp.kernel.org/ Signed-off-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 9562ddbc6ed8f0372b0ef376cd593cceee4ac1bc Author: Matt Vollrath Date: Fri Jul 24 03:39:42 2026 -0400 ata: libata-eh: Increase STANDBY IMMEDIATE timeout commit 1e024d2b41ee32bc06818f7f09a3562c58842cf9 upstream. Correct a previous change (see Fixes) which reduced the standby timeout from 30 to 5 seconds. Increase it to 15 seconds. I was troubleshooting an error spotted during system suspend: [ 1217.152867] ata1.00: Entering standby power mode [ 1222.322948] ata1.00: qc timeout after 5000 msecs (cmd 0xe0) [ 1222.324010] ata1.00: STANDBY IMMEDIATE failed (err_mask=0x4) This drive is a Samsung 870 EVO SSD in good SMART standing, and I wasn't aware of any reason it should be taking so long to standby. The issue is intermittent, but I observed it sometimes taking 7 seconds to manually standby. I assume this was interruption of background maintenance after a power outage. As a desktop user, I would prefer to wait the extra 2 seconds at suspend to let the drive finish its business rather than drop the rails from under it. The change from 30 to 5 seconds was implicit when switching suspend from START STOP UNIT to an internal command with no timeout table entry. No reason was stated for the change. Fixes: aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop") Cc: stable@vger.kernel.org Signed-off-by: Matt Vollrath Assisted-by: Claude:claude-5-fable Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 0a02b0c8780714c3b1c3a8444fdf9261601c5494 Author: Haidar Lee Date: Wed Jul 15 14:04:41 2026 +0800 ASoC: tas2562: fix broken entries in the volume lookup table commit bdb0fd6de403fcea7b85dc9d38f0a571583ebe80 upstream. The float_vol_db_lookup table is supposed to hold round(10^(dB/20) * 2^30) for every 2 dB step from -110 dB to 0 dB, which is 56 entries, but it only has 55: the -90 dB entry duplicates the -92 dB value (0x0000695b) and the -20 dB entry (0x06666666) is missing altogether. As a result every step between -90 dB and -22 dB is off by 2 dB, and the control's maximum raw value of 110 indexes one element past the end of the array. Replace the duplicated -90 dB entry with the correct value 0x000084a3 and add the missing -20 dB entry, bringing the table to the full 56 entries so index 55 (raw value 110, 0 dB) is in range again. Fixes: bf726b1c86f2 ("ASoC: tas2562: Add support for digital volume control") Cc: stable@vger.kernel.org Signed-off-by: Haidar Lee Link: https://patch.msgid.link/20260715-tas2562-dvc-fix-v1-2-072b13901b20@adlinktech.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 35d5f1852e390c9a51f515b05b3ca8b2b5bcc404 Author: Haidar Lee Date: Wed Jul 15 14:04:40 2026 +0800 ASoC: tas2562: fix DVC coefficient write order commit 8e957e4907c58e9ca944f98799524f2bbb9cf68a upstream. The TAS2562 applies the 32-bit digital volume coefficient to the playback path when the last byte, DVC_CFG4 (book 0 page 2 reg 0x0F), is written. tas2562_volume_control_put() wrote DVC_CFG4 first and DVC_CFG1 (the MSB) last, so every volume change latched a value made of the previous coefficient's upper three bytes combined with the new LSB; the remaining bytes only took effect on the next volume change. In practice the control was unusable: the first setting after power-on always played at roughly 0 dB no matter what value was requested (the chip's default upper bytes were still latched), and most subsequent changes muted the output entirely or produced a distorted, over-unity gain. Verified on a TAS2562 (ADLINK OSM-520 / MT8189 board) by tracing the I2C writes with ftrace and by writing the same coefficients manually in both byte orders: written MSB-first the register block behaves exactly as the driver expects, LSB-first reproduces the broken behaviour. Write the bytes MSB first with DVC_CFG4 last so the complete new coefficient is latched atomically. Fixes: bf726b1c86f2 ("ASoC: tas2562: Add support for digital volume control") Cc: stable@vger.kernel.org Signed-off-by: Haidar Lee Link: https://patch.msgid.link/20260715-tas2562-dvc-fix-v1-1-072b13901b20@adlinktech.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cac7d2066b2f052328eb81171d7657be631a9ff1 Author: Shengjiu Wang Date: Wed Jul 15 10:47:58 2026 +0800 ASoC: fsl_easrc: fix m2m_init error path to use goto instead of bare return commit a54bc0eef90ea760039c14bb7f3b5db42529f84d upstream. When fsl_asrc_m2m_init() fails in fsl_easrc_probe(), the code did a bare return ret, bypassing pm_runtime_disable() in err_pm_disable. Use goto err_pm_disable to ensure proper cleanup on failure. Fixes: b62eaff0650d ("ASoC: fsl_easrc: register m2m platform device") Cc: stable@vger.kernel.org Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260715024758.1252801-3-shengjiu.wang@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6df5b32881602a5019a65c3b51450fc99dca6370 Author: Shengjiu Wang Date: Wed Jul 15 10:47:57 2026 +0800 ASoC: fsl_asrc: fix m2m_init error path to use goto instead of bare return commit 890b4253134f3a39883af7d5bea67af9c494c56d upstream. When fsl_asrc_m2m_init() fails in fsl_asrc_probe(), the code did a bare return ret, bypassing pm_runtime_disable() in err_pm_get_sync. Use goto err_pm_get_sync to ensure proper cleanup on failure. Fixes: 286d658477a4 ("ASoC: fsl_asrc: register m2m platform device") Cc: stable@vger.kernel.org Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260715024758.1252801-2-shengjiu.wang@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 032746c2dd9a4ea0774b04ac8a29e2ea628f106e Author: Baul Lee Date: Sun Jul 26 14:16:33 2026 +0900 ALSA: ump: fix double free of out_cvts on rawmidi error commit 70c977815af0d997feb2d0c5d284d55689bf7051 upstream. snd_ump_attach_legacy_rawmidi() allocates the legacy conversion array ump->out_cvts and, on the snd_rawmidi_new() error path, frees it with kfree() but leaves ump->out_cvts pointing at the freed memory. When the endpoint is later torn down, snd_ump_endpoint_free() frees ump->out_cvts a second time, resulting in a double free. The host snd-usb-audio driver attaches the legacy rawmidi for any USB MIDI 2.0 (UMP) device, so a device that makes snd_rawmidi_new() fail reaches this path on enumeration. Clear ump->out_cvts after freeing it on the error path so it is not freed again during teardown. Discovered by XBOW, triaged by Baul Lee Fixes: 33cd7630782d ("ALSA: ump: Export MIDI1 / UMP conversion helpers") Reported-by: Federico Kirschbaum Reported-by: Baul Lee Cc: stable@vger.kernel.org Signed-off-by: Baul Lee Link: https://patch.msgid.link/20260726051633.41206-1-baul.lee@xbow.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a26a2e52736f9e39843ca66a2e1ce6bf1adbcd1e Author: Norbert Szetei Date: Sun Jul 26 10:01:45 2026 +0200 ALSA: timer: Clear SNDRV_TIMER_IFLG_DEAD once the close completes commit c2744d5f3aea474513fd2298daecb94a952ce441 upstream. snd_timer_close_locked() marks an instance with SNDRV_TIMER_IFLG_DEAD and returns early when the flag is already set, but the flag is never cleared again. A completed close ends in remove_slave_links(), which leaves timeri->timer NULL, so a second close is already harmless through the timer == NULL path; the early return can only be reached by an instance that was opened again in between. For such an instance the close unlinks nothing, so snd_timer_instance_free() frees an object that is still on timer->open_list_head, still on snd_timer_master_list if it was opened with a slave key, still owns any adopted slaves, and still holds its timer and module references. snd_seq_timer_open() reopens an instance exactly like that: it retries its fallback open on the same object after a failure that has already run snd_timer_close_locked() internally. An unprivileged user with access to /dev/snd/timer and /dev/snd/seq can force that failure, since snd_timer_check_master() returns -EBUSY when a pending slave matches the new master's (slave_class, slave_id) key and the target timer has reached max_instances, and SNDRV_TIMER_IOCTL_SELECT with dev_class = SNDRV_TIMER_CLASS_SLAVE keeps the caller-supplied dev_sclass, so a sequencer queue's key can be forged. The freed instance is afterwards dereferenced by any further snd_timer_open() on that timer, by snd_timer_check_slave(), and by /proc/asound/timers, which faults on the stale ti->owner pointer. The flag only has to be visible while the close is in progress, which is all its other users need. Clear it in remove_slave_links(), under the same timer->lock that sets it, once the instance is off every list. Fixes: da3039e91d1f ("ALSA: timer: Forcibly close timer instances at closing") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei Link: https://patch.msgid.link/CA41AA48-75BF-45E9-A36D-3A5D2F124F60@doyensec.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5260e195c53e898a4a76527d4bb2178f31795e78 Author: Norbert Szetei Date: Sat Jul 25 08:33:45 2026 +0200 ALSA: seq: Fix division by zero in initialize_timer() commit 21e19688433452dfbbbe6b2bb670dea6eb92f0f6 upstream. A userspace-driven ALSA timer (SND_UTIMER) lets an unprivileged user set the backing snd_timer's hardware resolution to an arbitrary 64-bit value via SNDRV_TIMER_IOCTL_CREATE. snd_utimer_create() only rejects zero. When such a timer is bound to a sequencer queue, initialize_timer() computes the tick period as tmr->ticks = 1000000000 / (r * freq); where r is that user-controlled resolution and freq is the sequencer update rate in Hz, clamped to MIN_FREQUENCY..MAX_FREQUENCY (10..6250). A resolution of 2^63 makes the 64-bit product r * freq wrap to zero for any even freq, including DEFAULT_FREQUENCY (1000), so the division faults with a divide-by-zero. The division runs under tmr->lock with interrupts disabled, so the oops leaves the spinlock held and hangs the CPU. It is reachable by an unprivileged user with access to /dev/snd/timer and /dev/snd/seq. Oops: divide error: 0000 [#1] SMP KASAN PTI CPU: 7 UID: 1000 PID: 456 Comm: alsa_seq_utimer Not tainted 7.2.0-rc4+ RIP: 0010:initialize_timer.constprop.0+0x20a/0x2d0 snd_seq_timer_start+0x15e/0x2b0 snd_seq_control_queue+0x56f/0xba0 snd_seq_write+0x3e0/0x730 Reject an overflowing product with check_mul_overflow() and fall back to a single tick, which also avoids feeding a wrapped-but-nonzero divisor (e.g. 2^63 * 1000 mod 2^64 == 0, or other resolutions wrapping to a small value) into the period computation. Fixes: 37745918e0e7 ("ALSA: timer: Introduce virtual userspace-driven timers") Cc: Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Norbert Szetei Link: https://patch.msgid.link/DF8A3844-AD5E-4B8A-9CFC-BD83C212BA38@doyensec.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2940cc3cf43c72126b74ee6376314c195382023a Author: Norbert Szetei Date: Tue Jul 28 14:50:01 2026 +0200 ALSA: pcm: wake linked drain waiters on unlink commit f495b6c4c8594122918552c9be2b51eb71647cd9 upstream. snd_pcm_drain() on a linked stream parks an on-stack wait entry on the drained peer's runtime->sleep, and after schedule_timeout() removes it only if that peer is still found in the caller's group. If group membership changes during the wait and the sleep ends by signal or timeout (so autoremove_wake_function() does not run), finish_wait() is skipped and snd_pcm_drain() returns with the entry still queued on that stream's sleep list; a later wake_up() then walks a freed stack frame. This is reachable by unlinking either the drained or the draining stream. Unlike the close path (snd_pcm_drop() -> snd_pcm_post_stop()), snd_pcm_unlink() never wakes the sleep queues. Wake every group member under the group lock before the membership change, so a linked drainer is released and drops its entry while the streams are still grouped. The window was opened when snd_pcm_link_rwsem stopped being held across the wait and the removal became conditional on group membership (see Fixes). The later switch to finish_wait() kept that conditional removal, so the signal/timeout case remained. Fixes: f57f3df03a8e ("ALSA: pcm: More fine-grained PCM link locking") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Norbert Szetei Link: https://patch.msgid.link/A0705100-D10B-4286-9980-0142ABEEAD51@doyensec.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4969533a1b950e4dea47fb9cbd4c4dc83619a867 Author: Xu Rao Date: Thu Jul 23 16:57:10 2026 +0800 ALSA: lx6464es: fix period byte count for 16-bit streams commit 6437033bffe8bd2af174d139af552d90d40c7ac6 upstream. The lx6464es driver advertises both 16-bit and packed 24-bit PCM formats, but lx_trigger_start() and lx_interrupt_request_new_buffer() calculate the DMA period size as runtime->period_size * runtime->channels * 3. That is only correct for the packed 24-bit formats. For 16-bit streams the driver submits buffers that are 50% larger than the actual ALSA period and advances the DMA address by the same wrong amount. For example, with 2 channels, 256 frames and 4 periods, the third buffer already extends beyond the ALSA buffer and the fourth buffer starts outside it. Use snd_pcm_lib_period_bytes() so the byte count matches the runtime format, channel count and period size. Fixes: 02bec4904508 ("ALSA: lx6464es - driver for the digigram lx6464es interface") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Link: https://patch.msgid.link/8BB12E8D92A7CDBA+20260723085710.2567463-1-raoxu@uniontech.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7484669d1fbab9a499817b5fef686f6417e65fa2 Author: Eckhart Mohr Date: Fri Jul 24 21:00:13 2026 +0200 ALSA: hda/realtek: Add quirk for TongFang X6SP45xU commit 26a94400ffa4fcbeff32e23abebb83a1a20eb401 upstream. TongFang X6KK45xU and X6SP45xU have actually different PCI IDs. This patch Adds the missing PCI ID to fix headphone detection and clarifies the naming. Fixes: d595255241e5 ("ALSA: hda/realtek: Add quirk for TongFang X6xx45xU") Signed-off-by: Eckhart Mohr Cc: stable@vger.kernel.org Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20260724190109.169889-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 11e2953d9f4c7c3d2af94a889c2d805c537d633f Author: Takashi Iwai Date: Sun Jul 26 09:48:19 2026 +0200 ALSA: 6fire: Fix UAF at error handling during probe commit a54bf16965f896415c3337bc4fbb40fb11941d99 upstream. Although 6fire driver had a few fixes for dealing with the early error handling during the probe phase, it forgot a pending URB before freeing the resources, which may lead to a UAF. This patch addresses it by doing the almost same cleanup procedure like the normal disconnect phase at the error path. Reported-and-tested-by: Shuangpeng Bai Closes: https://lore.kernel.org/20260724030900.1984491-1-shuangpeng.kernel@gmail.com Cc: Link: https://patch.msgid.link/20260726074821.2288158-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c0d3b81f703b2a9e37fe1347610a50cdf0078c27 Author: David Howells Date: Thu Jul 23 12:34:48 2026 +0100 afs: Fix UAF when sending a message commit 4af1ec68d54b3871155914d584fb10669c41a861 upstream. In afs_make_call(), there's a race with async call reception and destruction. If a call is dispatched that doesn't have call->write_iter set (used to specify the data content for FS.StoreData), then the first rxrpc_kernel_send_data() will not set MSG_MORE in the msghdr. Once rxrpc_send_data() queues the last request packet, the response could come in at any time and cause the call to be completed and put. However, afs_make_call() will look at the call again to see it ->write_iter should be handled - something it's only allowed to do if it has its own ref on the call. Whilst this is the case for synchronous calls, it isn't true for async calls such as FS.FetchData. There's also a potential UAF in afs_make_call() in the event that an asynchronous call is being sent, but the call fails in some way (e.g. it gets aborted from the server). The problem there is that afs_make_call() tries to abort a call if the rxrpc send fails, but the asynchronous notification from rxrpc may have caused the afs_call to be torn down. generic/650 plays games with randomly taking CPUs offline, and can interject a significant delay such that the call is deallocated before afs_make_call() gets to check call->write_iter - and a UAF ensues (caught by KASAN). BUG: KASAN: slab-use-after-free in afs_make_call+0x1c90/0x2210 [kafs] Read of size 8 at addr ffff888035e050e8 by task fsstress/1409 Fix this by making afs_make_op_call() give the op->call its own ref rather than transferring the caller's ref to it and then dropping the ref when afs_make_call() returns. This also means that the afs_make_call() func never loses its ref on the call now. Fixes: eddf51f2bb2c ("afs: Make {Y,}FS.FetchData an asynchronous operation") Fixes: e49c7b2f6de7 ("afs: Build an abstraction around an "operation" concept") Link: https://sashiko.dev/#/patchset/20260702144919.172295-1-dhowells%40redhat.com Reported-by: Marc Dionne Signed-off-by: David Howells Link: https://patch.msgid.link/20260723113452.566619-4-dhowells@redhat.com cc: Jeffrey Altman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit d703f022a28a27c9431c1ad7958216709e253365 Author: David Howells Date: Thu Jul 23 12:34:47 2026 +0100 afs: Fix afs_fs_fetch_data() to subtract transferred from len commit 222052c6be186f2074b3a4d741d5de200f654c43 upstream. Fix afs_fs_fetch_data() to subtract subreq->transferred from subreq->len rather than adding it. Fixes: f28fc2010d62 ("afs: Eliminate afs_read") Link: https://sashiko.dev/#/patchset/20260713081022.2186481-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260723113452.566619-3-dhowells@redhat.com cc: Marc Dionne cc: Jeffrey Altman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit b53face003b4d790fa5c4ff746134e738f115150 Author: David Howells Date: Thu Jul 23 12:34:46 2026 +0100 afs: Fix afs_fs_fetch_data() to set call->async commit d568a43f6dbba3ba006304d95fd09862bd482a2f upstream. Fix afs_fs_fetch_data() to set call->async on an async operation as does afs_fs_fetch_data64(). Fixes: eddf51f2bb2c ("afs: Make {Y,}FS.FetchData an asynchronous operation") Link: https://sashiko.dev/#/patchset/20260702144919.172295-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/20260723113452.566619-2-dhowells@redhat.com cc: Marc Dionne cc: Jeffrey Altman cc: linux-afs@lists.infradead.org cc: stable@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 5c7fdcbecbab2b0a08d294238dec45c1a78aaa1b Author: Xuanqiang Luo Date: Thu Jul 23 14:04:45 2026 +0800 bpf: lwt: Fix dst reference leak on reroute failure commit 88c17de85ddb459c3fe1e3c65d61fa366b1cf0a8 upstream. bpf_lwt_xmit_reroute() obtains a referenced dst from the route lookup. When skb_cow_head() fails before that dst is installed on the skb, the error path only frees the skb. The skb still owns its previous dst, so the newly looked up dst reference is leaked. Release the new dst reference before freeing the skb on this error path. Fixes: 3bd0b15281af ("bpf: add handling of BPF_LWT_REROUTE to lwt_bpf.c") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Link: https://patch.msgid.link/20260723060445.21926-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 27cc0e603355c585f1e5da8398faa4d36d498188 Author: Sangho Lee Date: Thu Jul 23 12:28:07 2026 +0900 Bluetooth: HIDP: validate numbered report payloads commit 34f53d27b81a16a02828c8fdfa4e02badc326f17 upstream. When hidp_get_raw_report() waits for a numbered report, hidp_process_data() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed. KMSAN reports an uninitialized-value use in hidp_session_run(), with the value originating in __alloc_skb() through vhci_write(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added. The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds. Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload. Fixes: 0ff1731a1ae5 ("HID: bt: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE") Cc: stable@vger.kernel.org Signed-off-by: Sangho Lee Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 2ebf63aa557a69990b4e9ea22be224d58aabce96 Author: Sangho Lee Date: Thu Jul 23 12:28:06 2026 +0900 Bluetooth: HIDP: reject frames without a transaction header commit 47778d2c2087b5d192398f6fddf692d16a5431cf upstream. hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom. KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one. The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds. Pull the transaction header with skb_pull_data() and discard frames that do not contain it. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Sangho Lee Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit eb1d8318764de7216e6dbba29a24d69f7ce51348 Author: Chengfeng Ye Date: Thu Jul 23 23:34:40 2026 +0800 Bluetooth: hci_sync: Fix advertising data UAFs commit cdc36db204ffd97b947d64374cf23a210dc74777 upstream. hci_find_adv_instance() returns an adv_info pointer that is valid only while hdev->lock is held. The advertising command-sync paths perform instance lookups without that lock and, in some cases, retain the pointer while waiting for a controller response. An advertising termination event can therefore interleave as follows: hci_cmd_sync_work hci_rx_work hci_find_adv_instance() __hci_cmd_sync_status() wait for controller reply hci_dev_lock() hci_remove_adv_instance() kfree(adv) adv->scan_rsp_changed = false KASAN reported: BUG: KASAN: slab-use-after-free in hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 Write of size 1 at addr ffff88810a45d21d by task kworker/u17:0/88 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_set_ext_scan_rsp_data_sync+0x2e1/0x300 hci_schedule_adv_instance_sync+0x390/0x4c0 hci_cmd_sync_work+0x173/0x300 Allocated by task 87: hci_add_adv_instance+0x538/0xac0 add_advertising+0x885/0x1160 Freed by task 89: kfree+0x131/0x3c0 hci_remove_adv_instance+0x1d8/0x3b0 hci_le_ext_adv_term_evt+0x17b/0x730 Protect the instance lookup and payload construction in the extended advertising, scan response, and periodic advertising data paths. Snapshot the advertising parameters under hdev->lock, but release the lock before waiting for the controller. Clear advertising-data dirty bits before issuing their commands and restore them after a failure using a fresh lookup. Likewise, update the reported transmit power through a fresh lookup after the parameter command completes. No adv_info pointer then survives an HCI command wait. Fixes: cba6b758711c ("Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 2") Cc: stable@vger.kernel.org Suggested-by: Luiz Augusto von Dentz Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit c569def320aa8b1fde89227e2ea96606790fd86d Author: Zihan Xi Date: Tue Jul 21 22:36:07 2026 +0800 Bluetooth: mgmt: fix UAF in pair command cancellation commit d0a7b48ad0921bd88effaee10bf970ab1d5d0ddd upstream. The pairing completion and authentication failure callbacks look up the pending MGMT_OP_PAIR_DEVICE command by walking hdev->mgmt_pending. The lookup returned a command that was still linked on the shared pending list, without keeping mgmt_pending_lock held for the later dereference and removal. A concurrent MGMT_OP_CANCEL_PAIR_DEVICE request can remove and free the same pending command before the callback uses it. The reverse race is also possible when cancel_pair_device() gets a command from pending_find() and a callback removes it before the cancel path dereferences it. This can lead to a use-after-free and a second list_del(). Make the pairing lookup helpers transfer ownership of the pending command by removing it from hdev->mgmt_pending while holding mgmt_pending_lock. The callbacks and cancel path then complete the command and free it directly, so racing paths cannot find or free the same command again. Take a temporary hci_conn reference in cancel_pair_device() because the command completion drops the reference stored in the pending command. Fixes: e9a416b5ce0c ("Bluetooth: Add mgmt_pair_device command") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: Codex:gpt-5.4 Signed-off-by: Zihan Xi Reviewed-by: Ren Wei Reported-by: Vega Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit a33bc07b4730b6cd5681ac77d18ae0de3e739690 Author: Aldo Ariel Panzardo Date: Sat Jul 25 16:52:30 2026 -0300 Bluetooth: SCO: give the socket its own sco_conn reference commit abd93c85c8667add738ee82aeab95dd9fc8265a2 upstream. sco_conn_del() drops a reference it does not own. It takes one transient reference via sco_conn_hold_unless_zero() and releases it with the sco_conn_put() that follows sco_sock_hold(); the additional put in the !sk branch releases a second one: conn = sco_conn_hold_unless_zero(conn); ... sk = sco_sock_hold(conn); sco_conn_unlock(conn); sco_conn_put(conn); if (!sk) { sco_conn_put(conn); return; } When close() races the controller's Disconnection Complete, sco_chan_del() clears conn->sk and drops the socket's reference while sco_conn_del() is running. sco_conn_del() then sees sk == NULL, its own put drops the count to zero and frees the conn, and the second put writes to the freed kref: BUG: KASAN: slab-use-after-free in sco_conn_put.part.0+0x1a/0x190 Write of size 4 at addr ffff8881099dec74 by task kworker/u17:3/413 Workqueue: hci1 hci_rx_work Call Trace: sco_conn_put.part.0+0x1a/0x190 hci_disconn_complete_evt+0x1ee/0x3e0 hci_event_packet+0x54a/0x650 hci_rx_work+0x321/0x3d0 Allocated by task 413: sco_conn_add+0x72/0x1a0 sco_connect_cfm+0x88/0x670 Freed by task 413: sco_conn_del.isra.0+0x3f/0xf0 hci_disconn_complete_evt+0x1ee/0x3e0 refcount_t: underflow; use-after-free. The root cause is that the socket stores the connection without holding a reference of its own. __sco_chan_add() does: sco_pi(sk)->conn = conn; so the socket borrows whatever reference its caller happened to hold, and the callers paper over that with ad-hoc holds and puts. Give the socket a counted reference instead: __sco_chan_add() takes one and it is released together with the channel (sco_chan_del()) and in sco_sock_destruct(). With the socket holding its own reference, sco_conn_del() no longer needs the extra put and the redundant hold in sco_conn_ready() goes away. Making the socket own its reference means the connection is now actually freed on the error paths of sco_connect() where it used to leak, which in turn runs sco_conn_free() and its hci_conn_drop(conn->hcon). To keep the hci_conn accounting balanced, make that ownership explicit as well: sco_conn_add() consumes one hci_conn reference and the sco_conn owns it for its lifetime. sco_connect() hands over the reference returned by hci_connect_sco() and no longer drops it on the error paths; sco_connect_cfm(), which is not given a reference, takes one with hci_conn_hold() before handing it to sco_conn_add() (and drops it again if the allocation fails); and the explicit hci_conn_hold() in sco_conn_ready() is removed. Every reference then has a single, clear owner. Fixes: e6720779ae61 ("Bluetooth: SCO: Use kref to track lifetime of sco_conn") Cc: stable@vger.kernel.org Suggested-by: Pauli Virtanen Signed-off-by: Aldo Ariel Panzardo Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 814f82f432dc6ee4d15f94756554ff94e6e3ef05 Author: Zihan Xi Date: Fri Jul 24 00:43:46 2026 +0800 Bluetooth: mgmt: fix pending command UAF in EIR updates commit 8f2f62855a41d1730fb9e8122912bd2c8d6bed5d upstream. MGMT_OP_SET_LOCAL_NAME is handled asynchronously on powered controllers and can run set_name_sync(). When the controller is BR/EDR capable, set_name_sync() updates the local name and then rebuilds EIR data through eir_create(). The EIR builder walks hdev->uuids, but the UUID list can be changed and entries can be freed by MGMT_OP_ADD_UUID and MGMT_OP_REMOVE_UUID. pending_eir_or_class() is meant to serialize management commands that can change EIR or the class of device, but it did not include MGMT_OP_SET_LOCAL_NAME. In addition, it walked hdev->mgmt_pending without hdev->mgmt_pending_lock even though pending commands are added and removed under that mutex. A racing command completion can therefore remove and free a pending command while pending_eir_or_class() is still inspecting it, leading to a use-after-free in the pending-command list or allowing a local name update to rebuild EIR while UUID entries are being removed. Take hdev->mgmt_pending_lock while scanning hdev->mgmt_pending and treat MGMT_OP_SET_LOCAL_NAME as an EIR/class-affecting pending command on the powered asynchronous path. Check for a conflicting pending command before copying the new short name so a rejected SET_LOCAL_NAME request does not modify hdev->short_name. Fixes: 6fe26f694c82 ("Bluetooth: MGMT: Protect mgmt_pending list with its own lock") Cc: stable@vger.kernel.org Reported-by: Vega Assisted-by: Codex:gpt-5.4 Signed-off-by: Zihan Xi Signed-off-by: Ren Wei Reported-by: Vega Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 6936b367ee6d40e3afd839bda9b1427822507811 Author: Greg Kroah-Hartman Date: Mon Jul 27 17:57:32 2026 +0200 Bluetooth: btmtk: Fix short read errors in btmtk_usb_uhw_reg_read() commit b186c18c4843dd58adc29443369bddc71cb626a3 upstream. If btmtk_usb_uhw_reg_read() gets a "short" read from a device, it will accidentally treat that as a "real" read and populate the returned value with some unknown and probably totally invalid data. Fix this logic error up by calling usb_control_msg_recv() which guarantees a "full" read happens, and then simplify the error checking for when btmtk_usb_uhw_reg_read() is called. Note, one caller of btmtk_usb_uhw_reg_read() does not check the return value, but as we pre-initialize the return value as 0, an incorrect read will not do anything wrong. Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit f14d41dbc2fdf18a86bd4fc23146fc42686c8c03 Author: Greg Kroah-Hartman Date: Mon Jul 27 17:57:34 2026 +0200 Bluetooth: btusb: Fix short read errors in btusb_qca_send_vendor_req() commit cac43d360c928bc0cbbd18809632388265649761 upstream. If btusb_qca_send_vendor_req() gets a "short" read from a device, it will accidentally treat that as a "real" read and populate the returned value with some unknown and probably totally invalid data. Fix this logic error up by calling usb_control_msg_recv() which guarantees a "full" read happens, and then simplify the error checking for when btusb_qca_send_vendor_req() is called. Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit cae0dfed5d307b240bff71c3cf206652d1b6f215 Author: Luxiao Xu Date: Tue Jul 21 23:37:41 2026 +0800 audit: fix potential use-after-free in audit_del_rule() commit 246df90b5f1a8a6e6abbd2f058b029558720adec upstream. `audit_del_rule()` destroys `e->rule.exe` via `audit_remove_mark_rule()` before unlinking the rule from RCU-visible filter lists and waiting for a grace period. Concurrent readers in `audit_filter()` and `audit_filter_rules()` still dereference `e->rule.exe`, while the fsnotify mark can be freed on an independent lifetime path. This creates a use-after-free window during rule deletion. Fix this by unlinking the rule from the RCU-visible lists and invoking `synchronize_rcu()` before calling `audit_remove_mark_rule()` (and other rule removal helpers). This ensures that all existing RCU readers have exited the critical section before any underlying resources are destroyed. Cc: stable@vger.kernel.org Fixes: 34d99af52ad4 ("audit: implement audit by executable") Reported-by: Vega Assisted-by: Codex:gpt-5.4 Signed-off-by: Luxiao Xu Signed-off-by: Ren Wei Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 185c784c98094e05277a196a19a825192eb38afb Author: Zhan Xusheng Date: Sat Jul 18 13:09:22 2026 +0800 audit: fix potential integer overflow in audit_log_n_string() commit f865c143629d4094866a811dba5f329250bad486 upstream. audit_log_n_string() computes new_len as "slen + 3" (enclosing quotes plus the NUL terminator) and stores it into an int, while slen is a size_t. For a sufficiently large slen the addition can overflow and/or the result be truncated when assigned to the int new_len, so the "new_len > avail" check can be bypassed and the subsequent memcpy(ptr, string, slen) can write past the skb tail. This is the same class of bug that was fixed for the hex sibling in commit 65dfde57d1e2 ("audit: fix potential integer overflow in audit_log_n_hex()"); both helpers are reached through audit_log_n_untrustedstring() with the same length source. Make new_len a size_t and use check_add_overflow() to catch the overflow, mirroring the audit_log_n_hex() fix. No functional change for the in-tree callers, which all pass bounded lengths. Cc: stable@vger.kernel.org Fixes: 168b7173959f ("AUDIT: Clean up logging of untrusted strings") Signed-off-by: Zhan Xusheng Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 17b412468c7a44f66a385bda48cdc1e94e39bd6d Author: Charles Vosburgh Date: Mon Jul 27 19:17:30 2026 -0400 sctp: validate Adaptation Indication parameter length commit 74b21f52c5c5a71a05c0ff70e513f4f04ff28b17 upstream. The Adaptation Layer Indication parameter contains a fixed 32-bit Adaptation Code Point after its parameter header. However, sctp_verify_param() accepts a header-only parameter because the generic parameter walker only requires the header to be present. sctp_process_param() then reads adaptation_ind beyond the declared parameter. When the malformed parameter is last in an INIT, the read starts at the receive skb tail, and the value is copied into the state cookie returned in the INIT ACK. This may disclose four receive-buffer tail bytes. Require the declared parameter length to match the fixed structure size and abort the association through the existing invalid parameter length path otherwise. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Charles Vosburgh Acked-by: Xin Long Link: https://patch.msgid.link/20260727-sctp-adaptation-length-v1-1-0ab58b2810a5@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c0837aeace96152d14b17fdd19d70102b6631a7d Author: Hidayath Khan Date: Mon Jul 27 11:35:30 2026 +0200 dibs: fix use-after-free of dmb_node in loopback attach/detach/unregister commit a10ea943356b9d70c5616a0a06f6fa97cfdaccb1 upstream. dibs_lo_attach_dmb(), dibs_lo_detach_dmb() and dibs_lo_unregister_dmb() look up the dmb_node under dmb_ht_lock, drop the lock and only then operate on the node's refcount. Nothing keeps the node alive across that window: __dibs_lo_unregister_dmb() removes the node from the hash table under the write lock and immediately frees it. A concurrent final put can therefore free the node between the lookup and the refcount operation: CPU0 (attach) CPU1 (owner unregisters) read_lock_bh(&dmb_ht_lock) find dmb_node (refcnt == 1) read_unlock_bh(&dmb_ht_lock) refcount_dec_and_test() 1 -> 0 write_lock_bh(&dmb_ht_lock) hash_del(&dmb_node->list) write_unlock_bh(&dmb_ht_lock) kfree(dmb_node) refcount_inc_not_zero(&dmb_node->refcnt) <-- use-after-free The same window exists for the refcount_dec_and_test() calls in the detach and unregister paths. Close the race structurally by making hash table membership and the refcount transitions atomic with respect to each other: - Perform the final refcount_dec_and_test() and hash_del() in a single dmb_ht_lock write-side critical section, in both the unregister and the detach path. Freeing the node still happens after the lock is dropped, which is safe because a node whose refcount reached zero has left the hash table and can no longer be found. - This establishes the invariant that any node found in the hash table holds at least one reference, and that the final reference can only be dropped under the write lock. dibs_lo_attach_dmb() can thus take its reference with a plain refcount_inc() while still holding the read lock; refcount_inc_not_zero() is no longer needed. __dibs_lo_unregister_dmb() no longer touches the hash table and is renamed to dibs_lo_free_dmb() accordingly. Note: commit cc21191b584c ("dibs: Move data path to dibs layer") moved the code to its current location; the race was introduced earlier by commit c3a910f2380f ("net/smc: implement DMB-merged operations of loopback-ism"). Tested SMC-D via ISM and dibs loopback. Cc: stable@vger.kernel.org Fixes: c3a910f2380f ("net/smc: implement DMB-merged operations of loopback-ism") Reported-by: Rahul Chandelkar Signed-off-by: Hidayath Khan Reviewed-by: Alexandra Winter Link: https://patch.msgid.link/20260727093530.968834-1-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b878ba7e28144c9a857bc847d31f3c45413450ac Author: Farhan Ali Date: Thu Jul 23 15:14:09 2026 -0700 KVM: s390: pci: Validate AIBV and AISB before pinning guest pages commit 868d32ac72cba21c5c6d8a66a814b7c25a3a5c01 upstream. The AIBV holds one bit per MSI-X vector for a given function. The size of the bit vector is derived from the NOI and the AIBVO. If the size of the AIBV exceeds a single page boundary, then reject the request as we cannot safely pin the guest AIBV. Similarly reject the request if the AISB address is not 8-byte aligned as the architecture requires doubleword alignment for the summary bit address. Since the AISBO can address up to 64 bits, the size of the AISB can only be 8 bytes for the function. This also ensures the AISB doesn't exceed a single page boundary. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Cc: stable@vger.kernel.org Reviewed-by: Christian Borntraeger Reviewed-by: Matthew Rosato Signed-off-by: Farhan Ali Tested-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit e137d082325bbcae780087b57501d38585e625d9 Author: Farhan Ali Date: Thu Jul 23 15:14:07 2026 -0700 KVM: s390: pci: Fix NULL dereference on AIBV allocation failure commit 8bf09b9b7d3232806df95f409581f8a9fd99a3fa upstream. The airq_iv_create() can return NULL on failure, but the return value was never checked. If it fails, zdev->aibv will be NULL and fail when dereferenced in kvm_zpci_set_airq(). Add a NULL check and free the previously allocated AISB bit and zdev->aisb on failure. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Cc: stable@vger.kernel.org Reviewed-by: Christian Borntraeger Reviewed-by: Matthew Rosato Signed-off-by: Farhan Ali Tested-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 1abf9ce39a862f54a32b24002c09dc44f058972a Author: Farhan Ali Date: Thu Jul 23 15:14:06 2026 -0700 KVM: s390: pci: Fix missing error codes and memory unaccounting commit f86842e4d6c482300f4567f492d512c9ccf5bc4f upstream. In kvm_s390_pci_aif_enable() two error paths failed to set an error code, causing the function to return 0 on failure. It also failed to rollback memory accounting on failure. Fix both by propagating an error code on failure and calling unaccount_mem() in the cleanup path. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Cc: stable@vger.kernel.org Reviewed-by: Christian Borntraeger Reviewed-by: Matthew Rosato Signed-off-by: Farhan Ali Tested-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 70871b121f81d08879363cb1238a4c85c5c2800c Author: Farhan Ali Date: Thu Jul 23 15:14:05 2026 -0700 KVM: s390: pci: Fix memory accounting for pinned/unpinned pages commit 36f6999ecde3976731a8bfc0b8e667da6f593069 upstream. The account_mem() and unaccount_mem() functions call get_uid() which increments the reference count of struct user_struct on every invocation. But we don't decrement the count by calling free_uid(). It also accounted/unaccounted the pages against the current->mm. But its possible the unaccount_mem() can be called from a different process context than the one that originally pinned the pages. Let's fix this by storing the pinning process user_struct and mm_struct when accounting for pinned pages, and subsequently free these resources when the pages are unpinned. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Cc: stable@vger.kernel.org Reviewed-by: Christian Borntraeger Reviewed-by: Matthew Rosato Signed-off-by: Farhan Ali Tested-by: Matthew Rosato [borntraeger@linux.ibm.com: Fixed whitespace] Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 6837f0ae85fd54cf64c8a0c7c530bba2fae0a207 Author: Farhan Ali Date: Thu Jul 23 15:14:04 2026 -0700 KVM: s390: pci: Reject adapter interrupt forwarding if already enabled commit 8fa01be5a6149404adb82c0979a78f6347edd3ef upstream. The MPCIFC instruction doesn't allow registering adapter interrupts without first unregistering. So reject any request to enable interrupt forwarding if its already enabled for the zPCI device. This also fixes overwriting and thus leaking resources when the ioctl is called multiple times for the same device. Fixes: 3c5a1b6f0a18 ("KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding") Cc: stable@vger.kernel.org Reviewed-by: Christian Borntraeger Reviewed-by: Matthew Rosato Signed-off-by: Farhan Ali Tested-by: Matthew Rosato Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 7668c58dcf465559dc7a0d2e95e9cb79cf47454b Author: Sean Christopherson Date: Fri Jul 10 09:20:51 2026 -0700 KVM: SVM: Update x2APIC MSR intercepts if AVIC is inhibited while L2 is active commit 7d3aae206663c4e006b25a1c7a20a4029e67da76 upstream. Always update x2APIC MSR intercepts for L1 when AVIC is deactivated, even if L2 is active and KVM is using a separate MSR bitmap to run L2. If AVIC is fully enabled prior to running L2, and is then inhibited while L2 is active (for a VM-scoped inhibit), then KVM will run L1 with AVIC disabled, but with x2APIC MSR intercepts disabled, i.e. will allow L1 to read most of the host's APIC state, send arbitrary interrupts, change task priority, and ultimately trivially DoS the host. E.g. sending a self-IPI in L1 on HYPERV_REENLIGHTENMENT_VECTOR, 0xee, with CONFIG_HYPERV=n in the host kernel as a "safe" PoC, yields: Spurious interrupt (vector 0xee) on CPU#425. Acked And hacking KVM to abuse kvm_set_posted_intr_wakeup_handler() to register a handler and WARN on POSTED_INTR_WAKEUP_VECTOR yields: ------------[ cut here ]------------ WARNING: arch/x86/kvm/svm/svm.c:5594 at pi_wakeup_handler+0x9/0x10 [kvm_amd], CPU#156: nested_x2apic_t/316940 CPU: 156 UID: 0 PID: 316940 Comm: nested_x2apic_t Tainted: G S U Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20260209.0-0 02/09/2026 RIP: 0010:pi_wakeup_handler+0x9/0x10 [kvm_amd] Call Trace: sysvec_kvm_posted_intr_wakeup_ipi+0x64/0x80 asm_sysvec_kvm_posted_intr_wakeup_ipi+0x1a/0x20 RIP: 0010:vcpu_run+0x1430/0x1e40 [kvm] kvm_arch_vcpu_ioctl_run+0x2c1/0x600 [kvm] kvm_vcpu_ioctl+0x580/0x6b0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46ff4b ---[ end trace 0000000000000000 ]--- Fixes: 091abbf578f9 ("KVM: x86: nSVM: optimize svm_set_x2apic_msr_interception") Cc: stable@vger.kernel.org Cc: Yosry Ahmed Signed-off-by: Sean Christopherson Link: https://patch.msgid.link/20260729213558.639074-1-pbonzini@redhat.com/ Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 5acc92947baa21b05a6efaf36887efb17c0f7914 Author: Paolo Bonzini Date: Tue Jul 21 18:31:49 2026 +0200 KVM: VMX: add memory clobber to asm for VMX instructions commit 0e65cd9e5d41c34f86b7c347967bedac54926041 upstream. VMCLEAR/VMREAD/VMWRITE/VMPTRLD access the internal VMCS cache, which is not visible to the compiler; without a memory clobber, the compiler can reorder them in troublesome ways because "asm volatile" and "asm goto" only protect against removal of the asm. For example, placing a VMWRITE before the corresponding VMCS pointer is loaded can lead to corruption. While none of this has been observed, it is better to prevent than cure. Likewise, INVEPT and INVVPID access the TLB and, even though in their case the effect is only visible to the next VMLAUNCH/VMRESUME, it is technically correct to add the clobber there too. So avoid any urge to special case them, and simply hardcode "memory" into the clobber list of vmx_asm1() and vmx_asm2(). __vmcs_readl() open-codes its own asm, so add the clobber there as well. Link: https://lore.kernel.org/kvm/CABgObfbL3t21yVeSwiLSjjOUER+rTYDPHYAH9YU4TWGRjx6XHg@mail.gmail.com/ Cc: Sean Christopherson Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit e768ea3a422d1304a0588e7dc704ce739c2944a5 Author: Raushan Patel Date: Fri Jul 24 12:12:08 2026 +0530 tracing/fprobe: Roll back on enable_trace_fprobe() failure commit aca0cd1bf16574327ef64f3178e5f5e37a61ef0b upstream. enable_trace_fprobe() sets the file link or the TP_FLAG_PROFILE flag and then registers each trace_fprobe in the probe list. If __register_trace_fprobe() fails partway through, the function returns immediately without unregistering the trace_fprobes it already registered or undoing the file link / flag it set, leaving the event half-enabled and leaking the registered fprobe(s). enable_trace_kprobe() already handles this with a rollback path. Do the same for fprobe: on failure, unregister all probes and clear the file link or profile flag. Link: https://lore.kernel.org/all/20260724064208.480030-1-raushan.jhon@gmail.com/ Fixes: 334e5519c375 ("tracing/probes: Add fprobe events for tracing function entry and exit.") Cc: stable@vger.kernel.org Signed-off-by: Raushan Patel Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 3b2e08e0ede729277455ca7e972ceedd20956b21 Author: Raushan Patel Date: Fri Jul 24 11:14:35 2026 +0530 tracing/probes: Reject $arg0 in meta argument expansion commit 00a8ce2a2a9fa17674e1feec4d9105c1a5d6a419 upstream. traceprobe_expand_meta_args() parses $argN with simple_strtoul() and calls sprint_nth_btf_arg(n - 1, ...). For $arg0, n is 0 so the index is -1. Because ctx->nr_params is signed, the "idx >= nr_params" guard in sprint_nth_btf_arg() does not catch the negative index, and ctx->params[-1].name_off is read out of bounds. The normal per-argument path (parse_probe_vars()) already rejects $arg0 via its argument-number check, but meta-argument expansion runs before per-argument parsing and substitutes the value first, bypassing that check. Reject $arg0 explicitly during expansion. Link: https://lore.kernel.org/all/20260724054435.146279-1-raushan.jhon@gmail.com/ Fixes: 18b1e870a496 ("tracing/probes: Add $arg* meta argument for all function args") Cc: stable@vger.kernel.org Signed-off-by: Raushan Patel Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit e0fa737783b5b7c25f4f497be12670681878a060 Author: Gregory Price Date: Sat Jun 27 16:22:43 2026 -0400 mm/vmstat: fold stranded per-cpu node stats when a node comes online commit ea3034b2b00fa50c8d2518d0804c9d427bbafa86 upstream. A per-node vmstat counter is pgdat->vm_stat[] plus per-cpu deltas. A balanced counter can sit split as global=+N / per-cpu=-N. The folds reconciling the split only walk online nodes, so when try_offline_node() marks a node offline the per-cpu deltas are stranded. A subsequent online resets the per-cpu area but not pgdat->vm_stat[], orphaning the +N permanently. All NR_VM_NODE_STAT_ITEMS are affected. The existing code zeroes the per-cpu counters and causes a permanent skew. Fold the stranded deltas instead, before the node rejoins the online set. The node is not online yet and the hotplug lock is held, so the remote access to per-cpu values is safe. Discovered when node compaction hung for a nearly empty node, as the math to determine throttling broke. Reproduced by repeated memory hotplug/unplug cycles on a node under pressure: NR_ISOLATED_ANON ratchets up and never returns to zero. Link: https://lore.kernel.org/20260627202243.758289-1-gourry@gourry.net Fixes: 75ef71840539 ("mm, vmstat: add infrastructure for per-node vmstats") Signed-off-by: Gregory Price Cc: Johannes Weiner Cc: Mel Gorman Cc: Mike Rapoport Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 126a70bf1a08ddc9d79c471ebdaa2b08cfbab8df Author: Xiangfeng Cai Date: Tue Jul 14 01:14:55 2026 +0800 mm/hugetlb: fix list corruption in allocate_file_region_entries() commit dd9623f58ec702a07b2d67179d6fcea79c52231a upstream. allocate_file_region_entries() tops up resv->region_cache with freshly allocated file_region descriptors. The allocation uses GFP_KERNEL, so resv->lock is dropped around it: the new entries are gathered on a stack-local list head, allocated_regions, and spliced into resv->region_cache once the lock is re-acquired. The splice used list_splice(), which moves the entries but does not re-initialize the source head, so allocated_regions is left pointing at an entry that now lives on resv->region_cache. The top-up runs in a while loop that re-checks the cache deficit after re-acquiring the lock. For a shared mapping the resv_map is shared by every mapper of the hugetlbfs inode, so a concurrent region_chg()/region_add()/region_del() on the same resv_map can consume cache entries during the unlocked window and force a second iteration. That iteration calls list_add() on the stale head and corrupts the list; with CONFIG_DEBUG_LIST the __list_add_valid() check trips: list_add corruption. next->prev should be prev (ffffc900011ff7f8), but was ffff88814c281460. (next=ffff88814c545640). kernel BUG at lib/list_debug.c:31! allocate_file_region_entries+0x191/0x420 region_chg+0x267/0x300 hugetlb_reserve_pages+0x387/0xc80 hugetlbfs_file_mmap+0x2ce/0x3f0 mmap_region+0x1348/0x1a80 do_mmap+0x85e/0xb90 vm_mmap_pgoff+0x18c/0x330 ksys_mmap_pgoff+0x2a1/0x3e0 do_syscall_64+0xd7/0x420 Without CONFIG_DEBUG_LIST the bad list_add() silently links a kernel-stack address into resv->region_cache, leading to later use-after-free. This was observed as a real host panic on a dense KVM host where a QEMU guest-RAM hugetlbfs file was mapped MAP_SHARED by both QEMU and a separate SPDK/DPDK vhost-user target, generating concurrent region_* traffic on one shared resv_map. Use list_splice_init() so the source head is re-initialized empty after each splice, making the retry loop safe. Link: https://lore.kernel.org/20260713171456.300518-2-caixiangfeng@bytedance.com Fixes: d3ec7b6e09e5 ("mm/hugetlb: use list_splice to merge two list at once") Signed-off-by: Xiangfeng Cai Reviewed-by: Muchun Song Cc: Baoquan He Cc: David Hildenbrand Cc: Oscar Salvador Cc: Shuah Khan Cc: Wei Yang Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 32134cf9211b83bed9076d0739c5906fbea4c763 Author: Zi Yan Date: Thu Jul 9 15:12:01 2026 -0400 mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk() commit 89b1b79c308818a715e75f28744b70d8940a07c9 upstream. In pcpu_create_chunk(), nr_pages is the total contiguous backing allocation, i.e., nr_units * pcpu_unit_pages, but pcpu_chunk_populated() uses it to set chunk->populated, whose size is pcpu_unit_pages, bitmap. Since bit N in chunk->populated means page offset N inside every unit is backed. When nr_units > 1, the function writes beyond chunk->populated. Fix it by using chunk->nr_pages. It also fixes the global pcpu_nr_empty_pop_pages accounting, since pcpu_balance_free() only iterates up to chunk->nr_pages. Commit a63d4ac4ab609 ("percpu: make percpu-km set chunk->populated bitmap properly") introduced the bitmap overflow issue. Later, commit b539b87fed37f ("percpu: implmeent pcpu_nr_empty_pop_pages and chunk->nr_populated") added pcpu_nr_empty_pop_pages and caused the accounting issue. Link: https://lore.kernel.org/20260709-fix-pcpu_create_chunk-in-percpu-km-v1-1-1f64745a84cc@nvidia.com Fixes: a63d4ac4ab609 ("percpu: make percpu-km set chunk->populated bitmap properly") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260703-keep-subpage-private-zero-at-free-v2-0-2970fe777dd6%40nvidia.com?part=1 Assisted-by: Codex:GPT-5 Signed-off-by: Zi Yan Acked-by: Dennis Zhou Cc: Christoph Lameter Cc: Tejun Heo Cc: Zi Yan Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7d3e1d3a0dce9d842288e50294839a611454d0e9 Author: Kiryl Shutsemau (Meta) Date: Wed Jul 15 15:42:33 2026 +0100 fs/proc/task_mmu: fix PAGEMAP_SCAN written state for PMD holes commit 40de8160ca7f67d14619ee0351ce5d68fc4a237a upstream. PAGEMAP_SCAN reports an unpopulated PTE in a uffd-wp VMA as written, but a range with no page table at all -- a PMD hole -- is skipped: pagemap_scan_pte_hole() tests p->cur_vma_category, which never carries PAGE_IS_WRITTEN, so the hole is neither reported nor (under PM_SCAN_WP_MATCHING) armed. In a uffd-wp VMA, WP_UNPOPULATED installs uffd-wp markers when protecting a range, allocating page tables as needed, so an unpopulated slot is treated as written -- see the pte_none() handling in pagemap_page_category(). A missing marker therefore means the range was zapped, e.g. via MADV_DONTNEED. This applies to anon and shmem VMAs. An anonymous THP is write-protected in place as a huge PMD, so a full-PMD MADV_DONTNEED clears it to pmd_none -- a hole with no page table -- and pagemap_scan_pte_hole() misses it. For a MAP_PRIVATE|MAP_ANON mapping MADV_DONTNEED has fill-with-zeros semantics, so a write-tracking checkpoint/migration tool (e.g. CRIU) treats the range as unchanged and keeps its previous contents; after restore or live migration the process reads stale data instead of zeroes -- data corruption. Report a hole in a non-hugetlb uffd-wp VMA as written, matching the pte_none handling in pagemap_page_category(); the existing PM_SCAN_WP_MATCHING path then arms it via uffd_wp_range(). hugetlb is excluded: pagemap_hugetlb_category() reports an empty hugetlb entry (huge_pte_none) as not-written, unlike pagemap_page_category(), which reports pte_none as written. pagemap_scan_pte_hole() fires for a hugetlb slot only when it has no page table; keeping that not-written matches how an allocated-but-empty hugetlb entry reads, so the hole and the empty-entry cases agree within the VMA. Link: https://lore.kernel.org/20260715144234.442721-2-kirill@shutemov.name Fixes: 2bad466cc9d9 ("mm/uffd: UFFD_FEATURE_WP_UNPOPULATED") Signed-off-by: Kiryl Shutsemau Reported-by: Sashiko AI review Closes: https://sashiko.dev/#/patchset/20260707151349.92143-1-kirill@shutemov.name Tested-by: Muhammad Usama Anjum Acked-by: David Hildenbrand (Arm) Cc: Peter Xu Cc: Jann Horn Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Pedro Falcato Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zenghui Yu Assisted-by: Claude:claude-fable-5 Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c091462e46f75ef1e1a22c7f605fe8f8b72d2a0c Author: Jori Koolstra Date: Fri Jul 10 19:17:35 2026 +0200 selftest: fix headers in fclog.c commit e3a0127eee04db8769e53c8102c4e76aa49be8c3 upstream. fclog.c does not compile because it is missing fcntl.h, needed for O_RDONLY etc. There are also some redundant includes that are also in kselftest_harness.h. Link: https://lore.kernel.org/20260710171741.837308-1-jkoolstra@xs4all.nl Signed-off-by: Jori Koolstra Cc: Aleksa Sarai Cc: Shuah Khan Cc: Wei Yang Cc: Christian Brauner Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9668ffe0e2a5e2399dce281620198a2e415871fc Author: Aboorva Devarajan Date: Thu Jul 9 01:49:54 2026 +0530 mm/util: don't read __page_2 for order-1 folios in snapshot_page() commit 7441d6348c70738e9ed307510db171c7a9b3f4bf upstream. snapshot_page() currently reads __page_2 after checking nr_pages > 1, but it should only do so when nr_pages > 2. If an order-1 folio is allocated at the end of a vmemmap section, __page_2 will not exist and reading it will cause a fault. During DLPAR memory remove on a 22 TB ppc64le LPAR, snapshot_page() oopsed on the page isolation path while reading an order-1 folio's __page_2 from an adjacent absent section (unmapped vmemmap). Fix this to avoid reading memmap that doesn't exist (e.g., a vmemmap hole). Link: https://lore.kernel.org/20260708201954.686111-1-aboorvad@linux.ibm.com Fixes: 31a31da8a618 ("mm: move _pincount in folio to page[2] on 32bit") Signed-off-by: Aboorva Devarajan Reported-by: Sourabh Jain Acked-by: David Hildenbrand (Arm) Reviewed-by: Lorenzo Stoakes Reviewed-by: Matthew Wilcox (Oracle) Reviewed-by: Luiz Capitulino Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: "Ritesh Harjani (IBM)" Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: # v6.15+ Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2be94d6b20789b8865b1864dae5fe458ca85e019 Author: Kefeng Wang Date: Mon Jul 6 19:19:58 2026 +0800 mm: migrate_device: fix pte_pfn/pte_dirty called on non-present PTE commit 63867c82d0c0c2d182016a32b1cc0103116b0ea5 upstream. pte_pfn() and pte_dirty() have undefined behaviour when called on a non-present PTE. In migrate_vma_collect_pmd(), these functions may be invoked on non-present entries (e.g., device-private entries), leading to potential crashes from pte_pfn() or incorrect dirty folio accounting from pte_dirty(). Fix both by guarding with pte_present() checks. Link: https://lore.kernel.org/20260708003955.4024340-1-wangkefeng.wang@huawei.com Link: https://lore.kernel.org/20260706111958.3649651-1-wangkefeng.wang@huawei.com Fixes: fd35ca3d12cc ("mm/migrate_device.c: copy pte dirty bit to page") Fixes: 6c287605fd56 ("mm: remember exclusively mapped anonymous pages with PG_anon_exclusive") Signed-off-by: Kefeng Wang Reviewed-by: Balbir Singh Acked-by: Zi Yan Cc: Alistair Popple Cc: Byungchul Park Cc: David Hildenbrand Cc: Gregory Price Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: Ying Huang Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2205263b1e013a82ac0e6abf899968ff2889fc1d Author: Nathan Chancellor Date: Tue Jun 23 13:23:46 2026 -0700 fortify: Disable -Wstringop-overread in tests commit c1f3e770eec26d6f96dd6d2ea30555ba7c09a244 upstream. clang recently added support for -Wstringop-overread [1], which is on by default like -Wfortify-source. This breaks the usage of -Werror in the fortify tests, resulting in the following false positive warnings in the kernel build: warning: unsafe memcmp() usage lacked '__read_overflow2' warning in lib/test_fortify/read_overflow2-memcmp.c warning: unsafe memcmp() usage lacked '__read_overflow' warning in lib/test_fortify/read_overflow-memcmp.c warning: unsafe memchr() usage lacked '__read_overflow' warning in lib/test_fortify/read_overflow-memchr.c Examining the fortify test logs shows a warning like the following in each of the failed logs: In file included from lib/test_fortify/read_overflow2-memcmp.c:5: lib/test_fortify/test_fortify.h:34:2: error: 'memcmp' reading 17 bytes from a region of size 16 [-Werror,-Wstringop-overread] 34 | TEST; | ^ lib/test_fortify/read_overflow2-memcmp.c:3:2: note: expanded from macro 'TEST' 3 | memcmp(large, small, sizeof(small) + 1) | ^ 1 error generated. Disable -Wstringop-overread for the fortify tests, as it defeats the purpose of testing the Linux specific implementation of fortify, like -Wfortify-source. Cc: stable@vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/2168 Link: https://github.com/llvm/llvm-project/commit/86f2e71cb8d165b59ad31a442b2391e23826133e [1] Signed-off-by: Nathan Chancellor Link: https://patch.msgid.link/20260623-fix-test_fortify-for-clang-stringop-overread-v1-1-15ee8342a953@kernel.org Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 96b0aa79b0e1e49f557b190d3fff1fd59bec72dc Author: Benjamin Boortz Date: Mon Jul 20 19:51:04 2026 +0200 pinctrl: bm1880: add missing select GENERIC_PINCONF commit dad6e107b3cd9d20514e7799b7ad8674f81e3f30 upstream. drivers/pinctrl/pinctrl-bm1880.c initialises its pinconf_ops with .is_generic = true, but that field is only present when CONFIG_GENERIC_PINCONF is enabled (guarded by #ifdef in pinconf.h). The Kconfig entry for PINCTRL_BM1880 never selects GENERIC_PINCONF, so any config that enables CONFIG_PINCTRL_BM1880=y without CONFIG_GENERIC_PINCONF=y fails to compile: drivers/pinctrl/pinctrl-bm1880.c:1288:10: error: 'const struct pinconf_ops' has no member named 'is_generic' Found by randconfig testing on arm64; tinyconfig reproducer below. Add the missing select to fix the build. Fixes: 49bd61ebce5f ("pinctrl: Add pinconf support for BM1880 SoC") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Boortz Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 5aaa06dfc10f8398c8807453dbec738ea9af10e4 Author: Michael Bommarito Date: Tue Jul 14 07:47:29 2026 -0400 erofs: cap LZMA stream pool size commit c9b47e6b23114e939b17f818471c7a46e59006e7 upstream. fs/erofs/decompressor_lzma.c sizes the module-global MicroLZMA stream pool from num_possible_cpus() when the lzma_streams module parameter is unset, then z_erofs_load_lzma_config() preallocates one image-supplied dictionary per stream, accepting dictionaries up to 8 MiB. On high-CPU systems, a small EROFS image can pin hundreds of MiB of vmalloc-backed decoder state until the erofs module is unloaded. Impact: An EROFS image mounted by the system can pin up to 8 MiB of vmalloc memory per LZMA stream, either as intended or unexpectedly. Bound the default stream count by a new CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS option, default 16, so the worst-case default preallocation is 128 MiB if the number of CPUs is no less than 16 while preserving the existing per-image dictionary limit. An explicit lzma_streams module parameter is still honoured as-is, so administrators who deliberately size the pool are not affected. Fixes: 622ceaddb764 ("erofs: lzma compression support") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Gao Xiang Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit ad0ad3c228b6f76fde10f32047e0ec5fbc109dc8 Author: Karl Mehltretter Date: Sun Jul 19 14:11:40 2026 +0200 pinctrl: devicetree: don't free uninitialized dev_name on error path commit 015b5bcbcb622b32317642be91a7f79aa5413649 upstream. dt_remember_or_free_map() duplicates dev_name for each map entry. If kstrdup_const() fails, dt_free_map() frees dev_name in all num_maps entries, including entries that have not been initialized. Some pinctrl drivers, including pinctrl-imx, allocate the map with kmalloc() and leave dev_name for the core to initialize. The untouched entries therefore contain uninitialized data which is passed to kfree_const(). Reproduced on qemu's mcimx6ul-evk (pinctrl-imx) with failslab injection while binding the pinctrl-consuming device, under KASAN: BUG: KASAN: double-free in dt_free_map+0x34/0xa4 Free of addr c425a900 by task init/1 kfree from dt_free_map+0x34/0xa4 dt_free_map from dt_remember_or_free_map+0x184/0x198 dt_remember_or_free_map from pinctrl_dt_to_map+0x33c/0x4c8 pinctrl_dt_to_map from create_pinctrl+0x9c/0x5c0 Initialize all dev_name fields to NULL before duplicating the device name, making the full-map cleanup safe after a partial failure. Fixes: be4c60b563ed ("pinctrl: devicetree: Avoid taking direct reference to device name string") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 93d934668047f9457e3aaae0a1b118864e429cff Author: Benjamin Boortz Date: Sun Jul 19 11:41:46 2026 +0200 pinctrl: microchip-sgpio: add missing select REGMAP_MMIO commit 25cb6e9a13123d1039cdc75b446ac52e1ebdc26d upstream. The driver calls ocelot_regmap_from_resource() via , which internally uses devm_regmap_init_mmio() and requires REGMAP_MMIO. The Kconfig entry does not select REGMAP_MMIO, causing a build failure when no other driver in the config happens to pull in REGMAP_MMIO: include/linux/mfd/ocelot.h:34:24: error: implicit declaration of function 'devm_regmap_init_mmio' Found by randconfig testing on arm64; tinyconfig reproducer below. Fixes: 2afbbab45c26 ("pinctrl: microchip-sgpio: update to support regmap") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Boortz Reviewed-by: Andy Shevchenko Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 6da8f37419dd4c456f26fc203f04e000186f4b3d Author: Peiyang He Date: Mon Jul 20 16:50:16 2026 +0800 iommu/iommufd: Fix IOPF group ownership UAF commit 738e6f32e61d80b554e37015ecb7bc620b88001c upstream. iopf_group_alloc() links each last-page IOPF group into the generic IOPF pending list before invoking the domain fault handler. iommufd_fault_iopf_handler() also queued an accepted group in the IOMMUFD deliver list without removing it from the generic pending list. When detach or HWPT replacement drops the device's IOPF reference count to zero, an IOMMU driver may call iopf_queue_remove_device(). That function responds to and frees groups through the generic pending list without removing the same groups from IOMMUFD's deliver list or response xarray. A later read, response, or cleanup can then access the freed group and cause a UAF. Fix this by dequeuing an accepted group from the generic pending list before IOMMUFD queues it for userspace response. Make iopf_group_response() send a response regardless of pending-list membership, so the dequeued group can still be completed by IOMMUFD. Link: https://patch.msgid.link/r/3CFD314D0FE4D7EC+20260720085017.3998878-2-peiyang_he@smail.nju.edu.cn Closes: https://lore.kernel.org/all/B4F28798E2E784CA+d29f723c-b2b5-4b67-8d1c-4f7b9b0b27cb@smail.nju.edu.cn/ Fixes: 34765cbc679c ("iommufd: Associate fault object with iommufd_hw_pgtable") Cc: stable@vger.kernel.org Tested-by: Peiyang He Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Peiyang He Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 564ac339c0f8bada4e77a57a92bab9d3df635e07 Author: Peiyang He Date: Fri Jul 10 20:29:52 2026 +0800 iommufd: Fix wrong hwpt passed to iommufd_auto_response_faults on replace commit ba5c0f28a26e7d9be1e0997f8920dd638e2782fd upstream. iommufd_hwpt_replace_device() calls: iommufd_auto_response_faults(hwpt, old_handle); passing the *new* hwpt together with the handle of the device's *old* domain. This should be a parameter mismatch: 1. Semantically, iommufd_auto_response_faults(x, handle) scans x->fault's deliver list and response xarray for groups matching "handle". A group is queued under the hwpt that was attached at fault-delivery time. old_handle is fetched *before* the domain switch, so its group lives on old->fault, not on the new hwpt->fault. 2. Historically, the first argument was "old". The routine was introduced by commit b7d8833677ba ("iommufd: Fault-capable hwpt attach/detach/replace") as __fault_domain_replace_dev() in fault.c, correctly calling iommufd_auto_response_faults(old, curr). Commit fb21b1568ada ("iommufd: Make attach_handle generic than fault specific") moved this into iommufd_hwpt_replace_device() in device.c and swapped it to "hwpt". This should be a refactor regression, not an intentional change. Fix this by passing "old" instead. Link: https://patch.msgid.link/r/9D652384339C69D5+20260710122952.885325-1-peiyang_he@smail.nju.edu.cn Fixes: fb21b1568ada ("iommufd: Make attach_handle generic than fault specific") Cc: stable@vger.kernel.org Signed-off-by: Peiyang He Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit ee2212b482320d657b40c63864e028fdc259de64 Author: Nicolin Chen Date: Sun Jul 5 22:36:10 2026 -0700 iommufd/viommu: Publish a vDEVICE only after vdevice_init() succeeds commit 9be311cfbe6154da146a7408e0d5e518a9321ed3 upstream. iommufd_vdevice_alloc_ioctl() adds the vDEVICE to the viommu->vdevs xarray with xa_cmpxchg() before the driver's vdevice_init() op runs. That op is where a driver validates the device and may reject it, but the xarray entry is already live by then: a concurrent IOMMU_HWPT_INVALIDATE can look it up with iommufd_viommu_find_dev() and run the driver invalidation path against a device that vdevice_init() would have refused. Reserve the index with xa_insert(): it stores a zero entry that reads back as NULL, and returns -EBUSY on a duplicate virt_id. Run vdevice_init() and store the vDEVICE pointer only once it succeeds. A failed vdevice_init() releases the reservation, so lookups observe the vDEVICE only after it is fully initialized and accepted. Fixes: ed42eee797ff3 ("iommufd/viommu: Add driver-defined vDEVICE support") Link: https://patch.msgid.link/r/1e05999347f4bf583edbc6a1312c857d5548708c.1783311134.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Reviewed-by: Kevin Tian Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Pranjal Shrivastava Signed-off-by: Nicolin Chen Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 294b464b2be7e57872864cb6936e1d9c7294f89d Author: Nicolin Chen Date: Sun Jul 5 22:36:09 2026 -0700 iommufd/viommu: Release the igroup lock on the vdevice_size error path commit 339bd11591593ab7ce88136ab7fd01ef3813b724 upstream. iommufd_vdevice_alloc_ioctl() takes idev->igroup->lock, then validates the driver's vdevice_size against the core structure size with a WARN_ON_ONCE. On failure that guard jumps to out_put_idev, below out_unlock_igroup, so it skips the mutex_unlock(), leaving the igroup lock held and deadlocking the next vDEVICE operation on that group. Jump to out_unlock_igroup instead. Fixes: ed42eee797ff3 ("iommufd/viommu: Add driver-defined vDEVICE support") Link: https://patch.msgid.link/r/e903f775d491296a525097e2a90b3eb6a47cf2ef.1783311134.git.nicolinc@nvidia.com Cc: stable@vger.kernel.org Reviewed-by: Kevin Tian Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Pranjal Shrivastava Signed-off-by: Nicolin Chen Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 062aa5dcc49a9ad96726a80c2a0ab0a1233bc2b9 Author: Stanislav Kinsburskii Date: Thu Jul 23 00:28:11 2026 +0000 mshv: Order pt_vp_array publish against irqfd assertion path [ Upstream commit b098dc869219c15dc49bf9cf63fb5fc1481d3373 ] mshv_partition_ioctl_create_vp() initialises a VP struct (allocations, mutex_init, init_waitqueue_head, page mappings) and then publishes the pointer into partition->pt_vp_array. Several ISR paths read this array locklessly: the intercept ISR, the two scheduler ISRs, and mshv_try_assert_irq_fast() on the irqfd fast path. Of these, only mshv_try_assert_irq_fast() can structurally race the publish. It runs from an eventfd waker without holding pt_mutex, and MSHV_IRQFD does not require the target lapic_apic_id (== vp_index) to refer to an existing VP at registration time. A user can therefore register an irqfd targeting a yet-to-be-created VP, then trigger mshv_try_assert_irq_fast() concurrently with MSHV_CREATE_VP for the same index. On weakly-ordered architectures the reader can observe a non-NULL pointer in pt_vp_array before the initialising stores to the VP struct become visible, leading to use of partially-initialised fields (e.g. vp_register_page). The other ISR readers cannot reach this race: the hypervisor will not generate intercept or scheduler messages for a VP that has never been told to run, and the user can only call MSHV_RUN_VP on the VP fd returned by MSHV_CREATE_VP, which by construction is returned after the publish. Leave those readers as plain loads. Use smp_store_release() in mshv_partition_ioctl_create_vp() to publish the pointer, and pair it with smp_load_acquire() in mshv_try_assert_irq_fast(). On x86 these compile to plain accesses under TSO; on ARM64 they emit one-instruction acquire/release barriers, acceptable on this fast path. The destroy-side path (destroy_partition() clearing pt_vp_array[i] to NULL after kfree(vp)) has a separate ordering and lifetime concern that is out of scope here. Fixes: 621191d709b14 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs") Signed-off-by: Stanislav Kinsburskii Reviewed-by: Anirudh Rayabharam (Microsoft) Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit f50f5d3972da0c4f888be2ea66e470e317afb0df Author: Stanislav Kinsburskii Date: Thu May 7 15:43:43 2026 +0000 mshv: Fix level-triggered check on uninitialized data [ Upstream commit 0289a67cd70bf9d3807e289f4efd643e16a6c6b4 ] In mshv_irqfd_assign(), the level-triggered validation for resample irqfds checks irqfd_lapic_irq.lapic_control.level_triggered before mshv_irqfd_update() has populated the field. Since the irqfd struct is zero-allocated, level_triggered is always 0 at that point, causing the check to always reject resample irqfds with -EINVAL. This makes level-triggered interrupt resampling — used to avoid interrupt storms with assigned devices — completely non-functional. Move the check after the mshv_irqfd_update() call, which resolves the IRQ routing entry and populates irqfd_lapic_irq with the actual trigger mode. Fixes: 621191d709b14 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs") Signed-off-by: Stanislav Kinsburskii Reviewed-by: Anirudh Rayabharam (Microsoft) Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit fc362bfcb060eb6050aca772f60904153b6c228b Author: Jinank Jain Date: Mon Nov 24 14:25:59 2025 +0000 mshv: adjust interrupt control structure for ARM64 [ Upstream commit 9d70ef7a18e0ec1653ac63020a13a5d4dda7cc0d ] Interrupt control structure (union hv_interupt_control) has different fields when it comes to x86 vs ARM64. Bring in the correct structure from HyperV header files and adjust the existing interrupt routing code accordingly. Signed-off-by: Jinank Jain Signed-off-by: Anirudh Rayabharam (Microsoft) Signed-off-by: Wei Liu Stable-dep-of: 0289a67cd70b ("mshv: Fix level-triggered check on uninitialized data") Signed-off-by: Sasha Levin commit 72a90ce4918b5a2d4820fe20677ba9af780d8826 Author: Stanislav Kinsburskii Date: Thu May 7 15:43:15 2026 +0000 mshv: Fix race in mshv_irqfd_deassign [ Upstream commit 0762262ac3e70f65b3bb843fe892f8bac1562d08 ] mshv_irqfd_deactivate() and the hlist traversal of pt_irqfds_list require pt->pt_irqfds_lock to be held, but mshv_irqfd_deassign() omits it. This races with the EPOLLHUP path in mshv_irqfd_wakeup(), which does take the lock before calling mshv_irqfd_deactivate(). Additionally, mshv_irqfd_deactivate() uses hlist_del() which poisons the node pointers rather than resetting them. Since mshv_irqfd_is_active() relies on hlist_unhashed() (checks pprev == NULL), a poisoned node still appears active. If a concurrent path calls mshv_irqfd_deactivate() again on the same irqfd, the guard fails to prevent a double hlist_del() on poisoned pointers. Fix both issues: - Add the missing spin_lock_irq/spin_unlock_irq around the list traversal in mshv_irqfd_deassign(), matching mshv_irqfd_release(). - Use hlist_del_init() instead of hlist_del() so the node is properly marked as unhashed after removal, making the is_active guard reliable. Fixes: 621191d709b14 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs") Signed-off-by: Stanislav Kinsburskii Reviewed-by: Anirudh Rayabharam (Microsoft) Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit cfc686a1174aa904dcad9b9a7c5e46b484d27e4e Author: Christoph Hellwig Date: Mon Jun 29 14:52:29 2026 +0200 iomap: add a separate bio_set for iomap_split_ioend [ Upstream commit c679ce3be6cb63763d68ab9b5d9d73ddc0a40762 ] iomap_split_ioend can split bios that already come from iomap_ioend_bioset and thus deadlock when the bioset is exhausted. Add a separate bio_set to avoid this deadlock. Christian Brauner says: Mark iomap_ioend_split_bioset static as it is only used in ioend.c, fixing the sparse warning reported by the kernel test robot. Fixes: 5fcbd555d483 ("iomap: split bios to zone append limits in the submission handlers") Signed-off-by: Christoph Hellwig Link: https://patch.msgid.link/20260629125229.3400726-1-hch@lst.de Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 9be4a66f019ea90bd9deca70511f4f9ffebf5c6f Author: Namjae Jeon Date: Wed Jul 22 10:04:19 2026 +0900 ksmbd: fix use-after-free in __close_file_table_ids() [ Upstream commit e7188199eff46a636f3436356f0aae039be6dd66 ] A ksmbd_file can remain alive after logical close while another session holds a temporary reference obtained through ksmbd_lookup_fd_inode(). ksmbd_close_fd() currently marks the file closed and drops the idr-owned reference, but leaves the pointer published in the closing session's idr until the final reference is dropped. If the foreign holder performs the final ksmbd_fd_put(), __put_fd_final() supplies the foreign session's file table to __ksmbd_close_fd(). The object is then freed without being removed from its owner's idr, and the owner session later dereferences the stale pointer during file-table teardown. Remove the volatile id from the owner's idr while ksmbd_close_fd() still holds that table's lock, and clear volatile_id before dropping the idr-owned reference. A later foreign final put then only performs physical destruction and cannot remove the object from the wrong table. Fixes: 8510a043d334 ("ksmbd: increment reference count of parent fp") Reported-by: Yunseong Kim Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 213b4568f6e5d5b2c6402bd820f5d9ea3c7a8f91 Author: Namjae Jeon Date: Sun Jun 21 19:41:08 2026 +0900 ksmbd: return success for deferred final close [ Upstream commit c5db4de8988f1a621556ca5c4537f77b766ca07d ] ksmbd_close_fd() marks an open file as FP_CLOSED and drops the file table reference. If another in-flight request still holds a reference, the final close is deferred until that request drops its reference. The function currently returns -EINVAL in that deferred-final-close case because fp is cleared when the reference count does not reach zero. That turns a valid close into STATUS_FILE_CLOSED. smb2.compound_find.compound_find_close sends QUERY_DIRECTORY and then closes the same directory handle before receiving the find response. The query holds a reference while it builds the response, so close must mark the handle closed and return success even though final teardown is delayed. Track whether the handle was successfully transitioned to FP_CLOSED and return success when only the final close is deferred. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Stable-dep-of: e7188199eff4 ("ksmbd: fix use-after-free in __close_file_table_ids()") Signed-off-by: Sasha Levin commit cebba11df714bde20d55a4d7cca2ec7fdfd52a00 Author: Jerome Tollet Date: Wed May 20 07:55:44 2026 +0530 drm/i915/hdmi: Poll for 200 msec for TMDS_Scrambler_Status [ Upstream commit 1afb8eaeec44fd011f2b93ccd9fd426d753d963b ] HDMI 2.0 section 6.1.3.1 specifies that after enabling Scrambling_Enable and starting scrambled video transmission, the source should poll Scrambling_Status until it reads 1 or until a timeout of 200 ms expires. Add a polling step after enabling the HDMI port to check the scrambling status when HDMI scrambling is enabled. On some HDMI 2.0 sinks, omitting this check can result in 4K@60Hz (594 MHz) failing to come up correctly because the sink has not yet finished its scrambling setup. In practice, waiting for the scrambling status here fixes such sinks. While this synchronous polling is not itself explicitly required for correct modeset sequencing, HDMI 2.0 section 6.1.3.1 does recommend it as the way for the source to verify that the TMDS link is functioning correctly with scrambling enabled. v3: - Add explicit HDMI 2.0 section reference in code comment - Clarify commit message around the observed sink fix v2: - Poll TMDS_Scrambler_Status for up to 200 ms instead of using a fixed delay Reported-by: Jerome Tollet Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6868 Link: https://lore.kernel.org/dri-devel/20251230091037.5603-1-jerome.tollet@gmail.com/ Signed-off-by: Jerome Tollet Signed-off-by: Ankit Nautiyal Reviewed-by: Arun R Murthy Link: https://patch.msgid.link/20260520022544.3097252-1-ankit.k.nautiyal@intel.com (cherry picked from commit b7d51d65e4f12a48392d260613108ec262bc7774) Fixes: 15953637886d ("drm/i915: enable scrambling") Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit e51becb8f3377a377171ed5bf0082b96e22e6292 Author: Denis V. Lunev Date: Sun Jul 26 12:43:11 2026 +0200 qede: sync udp_tunnel ports outside qede_lock in the recovery path [ Upstream commit 451c9075d6c53f2438d110addbeeeea6fac18567 ] A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- taken qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. Re-sync the tunnel ports from qede_sp_task() after the internal lock is dropped, still under rtnl_lock as the udp_tunnel API requires. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case. This keeps the old gating exactly: a device that was down or a failed recovery returns false, as those paths never reached the udp_tunnel_nic_reset_ntf() call before either. This was the only user of the qede_lock()/qede_unlock() helpers, so remove them. Fixes: 8cd160a29415 ("qede: convert to new udp_tunnel_nic infra") Signed-off-by: Denis V. Lunev CC: Andrew Lunn CC: "David S. Miller" CC: Eric Dumazet CC: Jakub Kicinski CC: Paolo Abeni Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260726104311.1782900-1-den@openvz.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 51c52e493346fd8d0305d8891a8984ada584e28d Author: Haibo Chen Date: Tue Jul 28 18:18:08 2026 +0800 spi: spi-nxp-fspi: add per-SoC SDR/DTR clock rate limits for all supported SoCs [ Upstream commit 9c19d60fea9f46ed0c3394653ef4941f1a459968 ] The commit f43579ef3500 ("spi: spi-nxp-fspi: limit the clock rate for different sample clock source selection") introduced a global 166MHz cap for DTR mode (RXCLKSRC=3), based on the i.MX8MN datasheet timing specification (Section 3.9.9, page 65). After reviewing the FlexSPI timing parameters in the datasheets for all supported SoCs, the following corrections and additions are needed: 1. SDR mode (RXCLKSRC=0) limits vary per SoC: - i.MX8MN/MM/MP/95: 66MHz (IMX8MNCEC §3.9.9, IMX8MMCEC §3.9.10, IMX8MPCEC, IMX95CEC Rev.8 §4.11.7) - i.MX8QXP/QM/DXL/ULP: 60MHz (IMX8QXPCEC, IMX8QMCEC, IMX8DXLCEC, IMX8ULPCEC §7.3.1 ND mode) - LX2160A: 100MHz (LX2160ACEC FlexSPI timing parameters) 2. DTR mode (RXCLKSRC=3) limits vary per SoC: - i.MX8MN/MM/MP/ULP: 166MHz - i.MX8QXP/QM/DXL: 200MHz (same FlexSPI IP across this family) - i.MX95: 200MHz (IMX95CEC §4.11.7.3.2.3 Table 106) - LX2160A: DTR disabled (FSPI_QUIRK_DISABLE_DTR) Update related platform data with correct speed limation according to datasheet. Fixes: f43579ef3500 ("spi: spi-nxp-fspi: limit the clock rate for different sample clock source selection") Signed-off-by: Haibo Chen Link: https://patch.msgid.link/20260728-fspi-clock-v2-1-dbe786a4a6eb@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit caeaaf23f7c369a62d3c30a5e29b48f981d20677 Author: Gabriele Monaco Date: Fri May 22 14:58:33 2026 +0200 sched/deadline: Use revised wakeup rule only for running dl_server [ Upstream commit 1842bf97af109f5ebf830175c9725bf81ebb78b1 ] Commit 14a857056466 ("sched/deadline: Use revised wakeup rule for dl_server") applies the revised wakeup rule to any server, as a result servers that are not running (dl_defer_running == 0) and start with a deadline overflow get enqueued and can boost tasks as if they were running, invalidating the defer rule and the documented state model. Apply the revised wakeup rule only for deferrable servers that are marked as running. Fixes: 14a857056466 ("sched/deadline: Use revised wakeup rule for dl_server") Signed-off-by: Gabriele Monaco Signed-off-by: Peter Zijlstra (Intel) Acked-by: Juri Lelli Tested-by: Andrea Righi Link: https://patch.msgid.link/20260522125833.264145-1-gmonaco@redhat.com Signed-off-by: Sasha Levin commit 5a73e8c632c3147f3e9890ea94e76eca5b2283f6 Author: Suman Ghosh Date: Fri Jul 24 12:58:31 2026 +0530 octeontx2-pf: Set correct sequence for carrier off and tx queue stop [ Upstream commit 16809472409d998afcda402e32b8229b389337c4 ] During link down event, we were doing netif_tx_stop_all_queues() first and then netif_carrier_off(). This can cause a potential race since carrier is still on during down event. This patch reverse the calling order to fix the issue. Fixes: 50fe6c02e5ad ("octeontx2-pf: Register and handle link notifications") Signed-off-by: Suman Ghosh Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260724072831.2415281-1-rkannoth@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b90916156b47221e02dc8188ae60cdaa90465332 Author: Jiawen Wu Date: Fri Jul 24 15:46:57 2026 +0800 net: libwx: fix FDIR ATR queue mismatch for software VLAN packets [ Upstream commit 732ed8f75ce583d115716f668dc80d730f3ad610 ] When TX VLAN hardware offload is disabled, VLAN tags are embedded in the packet payload (software VLAN). Previously, the driver failed to set the WX_TX_FLAGS_SW_VLAN flag for these packets during transmission. This missing flag caused the txgbe FDIR ATR logic to fall through to the default hash calculation path. This resulted in asymmetric hash values for Tx and Rx flows, preventing return packets from being steered to the same queue as the transmit packets. Fix this by detecting software VLANs via eth_type_vlan(skb->protocol) and setting WX_TX_FLAGS_SW_VLAN. This ensures the ATR feature selects the correct hashing algorithm to maintain Tx/Rx queue symmetry. Fixes: b501d261a5b3 ("net: txgbe: add FDIR ATR support") Signed-off-by: Jiawen Wu Reviewed-by: Simon Horman Link: https://patch.msgid.link/0879DA38A8E32701+20260724074657.10773-1-jiawenwu@trustnetic.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6bf322ab07418bad56a4635e8972bc42b2a3ff17 Author: Wei Fang Date: Mon Jul 27 14:03:48 2026 +0800 ptp: netc: fix potential interrupt storm caused by incorrect unbind order [ Upstream commit 54ad7ea45d63146a8e3c57375f8a269d4cf7ecea ] In netc_timer_remove(), hardware interrupts are disabled by clearing TMR_TEMASK before ptp_clock_unregister() is called. This may cause a race condition during driver unbind that could leave hardware interrupts active. For example, a concurrent PTP_CLK_REQ_EXTTS ioctl can re-enable TMR_TEMASK after it has been cleared, leaving a pending hardware interrupt when the driver unbinds. Since the NETC Timer does not support PCIe FLR, hardware state is not reset during probe. When the driver is rebound and the IRQ is registered, the pending interrupt fires immediately. At that point priv->tmr_emask is still zero, so netc_timer_isr() does not clear the interrupt status and unconditionally returns IRQ_HANDLED, resulting in an uninterruptible infinite interrupt storm. Fix this in several ways. First, request the IRQ with IRQF_NO_AUTOEN so it is not enabled when request_irq() runs, and clear TMR_TEMASK in netc_timer_init() before enabling it. The IRQ is only enabled at the end of probe once the timer has been reprogrammed and the PTP clock has been registered. This ensures a stale pending interrupt from a previous unbind or an unclean shutdown cannot be delivered before the driver is fully initialized. Second, in netc_timer_remove() call disable_irq() before ptp_clock_unregister() and move the TMR_TEMASK/TMR_CTRL clearing after it. disable_irq() masks the line and waits for any in-flight netc_timer_isr() to finish, so no ISR can dereference priv->clock after ptp_clock_unregister() has freed it. Unregistering the PTP clock before clearing the mask also guarantees that no in-flight or concurrent ioctl can re-enable hardware interrupts. Finally, return IRQ_NONE from netc_timer_isr() when the masked event status is zero, so the kernel's spurious interrupt detection can disable a stuck line instead of looping forever. Fixes: 671e266835b8 ("ptp: netc: add periodic pulse output support") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260720012508.23227-1-wei.fang%40oss.nxp.com Signed-off-by: Wei Fang Link: https://patch.msgid.link/20260727060348.1887464-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1e0dfb7e7a5d9021282cdb4efd8c03fb442f9ef4 Author: Daniel Golle Date: Tue Jul 28 05:52:29 2026 +0100 net: dsa: mt7530: error out on failed reads in MT7531 PHY polling [ Upstream commit 77a9ebe8818cf6dd1699bd6728cb5d66307801d7 ] The MT7531 indirect PHY access functions poll MT7531_PHY_IAC through a helper which returns 0 when the underlying read fails, so a failed bus transaction clears MT7531_PHY_ACS_ST and the access carries on, returning garbage PHY register data to phylib. Poll using regmap_read_poll_timeout(), which stops on read errors and propagates them. These functions hold the MDIO bus lock across the whole sequence, so the unlocked regmap accesses remain correct. Remove the now-unused _mt7530_unlocked_read(). Fixes: c288575f7810 ("net: dsa: mt7530: Add the support of MT7531 switch") Signed-off-by: Daniel Golle Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/79e85d68d210cc37342978171aa6432aa2954333.1785213071.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fd9586881d4782b92887dfb4216b69820ab4d580 Author: Daniel Golle Date: Tue Jul 28 05:52:14 2026 +0100 net: dsa: mt7530: check bus->read() errors in the MDIO regmap backend [ Upstream commit b4ce102b2cd88424c5860fbbb20b9eb343a93bf4 ] bus->read() returns a negative errno on failure, but mt7530_regmap_read() assigns it to a u16, truncating e.g. -ETIMEDOUT into 0xff92, and returns success. The garbage word is then consumed as register data, and read-modify-write cycles write it back to the switch. Check both reads and propagate their errors. The same defect existed in mt7530_mii_read() since the driver was introduced and moved into the regmap backend unchanged. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Daniel Golle Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/3c628e48276c2e5522c8795a6be60d11c7a76a7d.1785213071.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 54e07a158f7aea2754849d3a5a4cba1ac338ae7e Author: Karl Mehltretter Date: Wed Jul 29 03:21:32 2026 +0200 riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove [ Upstream commit a0188cc133696627857d16054e43f9ebc7efc821 ] remove_pud_mapping() and remove_p4d_mapping() obtain a child table base with pud_offset(p4dp, 0) and p4d_offset(pgd, 0), then add the index for addr. RISC-V folds page-table levels at runtime. When a level is folded, its offset helper returns the parent entry itself, but the index can still be nonzero. Adding it walks past the parent table. Sv48 folds P4D, while Sv39 folds both P4D and PUD, so memory hot-remove can descend into unrelated memory and pass an invalid page to __free_pages(). This can trigger: kernel BUG at include/linux/mm.h:1810! VM_BUG_ON_PAGE(page_ref_count(page) == 0) arch_remove_memory+0x1e/0x5c try_remove_memory+0x15e/0x200 remove_memory+0x24/0x3c Only add the index when the corresponding page-table level is enabled, matching p4d_offset() and pud_offset(). Fixes: c75a74f4ba19 ("riscv: mm: Add memory hotplugging support") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260729012132.24882-1-kmehltretter@gmail.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit b297559dc2f291872543bf9ae0ffd297c49519b3 Author: Muhammad Bilal Date: Thu Jun 18 02:25:20 2026 +0500 accel/qaic: use sizeof(*trans_hdr) for transaction length check [ Upstream commit d6c075f797a672a6e3bd2fd44aee713801698ec2 ] In encode_message() the per-transaction lower-bound check compares trans_hdr->len against sizeof(trans_hdr), i.e. the size of the pointer, instead of sizeof(*trans_hdr), the size of struct qaic_manage_trans_hdr. Every other length check in this file (encode_message() at the loop guard, decode_message(), etc.) correctly uses sizeof(*trans_hdr), so this is an inconsistency. On 64-bit builds the pointer and the struct are both 8 bytes, so the check is correct by coincidence and there is no behavioural change. On 32-bit builds the pointer is 4 bytes, which weakens the minimum-length check below the 8-byte header size. Use sizeof(*trans_hdr) so the check validates against the actual transaction header size on all builds. Fixes: ea33cb6fc278 ("accel/qaic: tighten bounds checking in encode_message()") Signed-off-by: Muhammad Bilal Reviewed-by: Jeff Hugo Signed-off-by: Jeff Hugo Link: https://patch.msgid.link/20260617212520.59801-1-meatuni001@gmail.com Signed-off-by: Sasha Levin commit 01bd01b61ad9ea917e5629a7f14f57a8af0543bb Author: Anirudh Srinivasan Date: Fri Jun 12 11:24:43 2026 -0500 riscv: drop __init from vec_check_unaligned_access_speed_all_cpus [ Upstream commit f51fed61eea0daba2f95f1a6074085e4cd513c7b ] This function runs within a kthread and need not necessarily finish before system finishes boot and free_initmem() unmaps the .init.text section. This function makes calls to SBI for probing unaligned access speed, and if this is slow for some reason (say some debug prints were added to SBI), the kthread can still be running at this point and result in an instruction page fault when trying to fetch from the freed region. [ 25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8 [ 25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000 [ 25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3 [ 25.661244] Oops [#1] [ 25.662997] Modules linked in: [ 25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY [ 25.674669] Hardware name: Tenstorrent Blackhole (DT) [ 25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.683458] ra : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.688372] epc : ffffffff80a04ef8 ra : ffffffff80a04ef8 sp : ffff8f8000203e20 [ 25.693874] gp : ffffffff814dc168 tp : ffffaf8001ad9900 t0 : 0000000000000000 [ 25.699401] t1 : fffffffffffffff0 t2 : ffffaf8001ad9a10 s0 : ffff8f8000203e30 [ 25.704912] s1 : ffffaf80018dc780 a0 : 0000000000000000 a1 : 0000000000000002 [ 25.710407] a2 : 00000000000001f0 a3 : 0000000000000018 a4 : 0000000000000000 [ 25.715917] a5 : 0000000000000000 a6 : ffffaf8001c03d98 a7 : ffffaf8001c03e30 [ 25.721419] s2 : ffff8f8000023c98 s3 : ffffaf8001aa1240 s4 : ffffffff80a04ee0 [ 25.726937] s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000 [ 25.732450] s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000 [ 25.737944] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000402 [ 25.743481] t5 : 0000000000000040 t6 : 0000000000000004 ssp : 0000000000000000 [ 25.749024] status: 0000000200000120 badaddr: ffffffff80a04ef8 cause: 000000000000000c [ 25.755060] [] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c [ 25.760964] [] kthread+0xd8/0xfc [ 25.764660] [] ret_from_fork_kernel+0x18/0x1c4 [ 25.769220] [] ret_from_fork_kernel_asm+0x16/0x18 [ 25.774018] Code: cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc (cccc) cccc Drop __init from its signature so that this doesn't happen. Fixes: a00e022be531 ("riscv: Annotate unaligned access init functions") Signed-off-by: Anirudh Srinivasan Assisted-by: Claude:claude-opus-4-6 Link: https://patch.msgid.link/20260612-vec_unaligned_drop_init-v1-1-df969210ae34@oss.tenstorrent.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit a20a0010eb6485f60cd64e15ebc85a4bd388642e Author: Masami Hiramatsu (Google) Date: Tue Jul 28 21:50:00 2026 +0900 tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions [ Upstream commit 12b80cdbc54cf615b4717a4e8180063408091ea2 ] mmio_trace_rw() and mmio_trace_mapping() retrieve mmio_trace_array into tr and pass it to __trace_mmiotrace_rw() and __trace_mmiotrace_map(). If these functions are invoked while mmio_trace_array is NULL (e.g. before initialization or after disabled), accessing tr->array_buffer.buffer will result in a NULL pointer dereference crash. Fix this by adding an explicit NULL check for tr at the beginning of __trace_mmiotrace_rw() and __trace_mmiotrace_map(). Link: https://patch.msgid.link/178524300062.56416.8362487250709962380.stgit@devnote2 Fixes: f984b51e0779 ("ftrace: add mmiotrace plugin") Assisted-by: Antigravity:gemini-3.6-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 9b604041f1009bec2b598935ebd31d6fedf9c9e3 Author: Masami Hiramatsu (Google) Date: Tue Jul 28 21:49:51 2026 +0900 tracing/mmiotrace: Reset dropped_count in mmio_reset_data() [ Upstream commit c786d2bdf1f3964deee192ad942dee2a741c1e2c ] mmio_reset_data() is called during tracer initialization, reset, and start. While it resets overrun_detected and prev_overruns, it neglects to reset dropped_count. Consequently, dropped event counts from prior tracing sessions persist in dropped_count and corrupt overrun reports in subsequent runs. Fix this by explicitly calling atomic_set(&dropped_count, 0) in mmio_reset_data(). Link: https://patch.msgid.link/178524299122.56416.16277704230639425172.stgit@devnote2 Fixes: 173ed24ee2d6 ("mmiotrace: count events lost due to not recording") Assisted-by: Antigravity:gemini-3.6-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit fc97dcb42fb46ac3d1b6bbd4a2570744c0bb19a0 Author: Masami Hiramatsu (Google) Date: Wed Jul 29 08:27:33 2026 +0900 fprobe: Fix module reference count leak on error in register_fprobe() [ Upstream commit 8cf2f40ceb85047ad8a84dffae3bebc9fed18216 ] In register_fprobe(), get_ips_from_filter() resolves target function addresses and increments module reference counts via try_module_get() for symbols in kernel modules. If get_ips_from_filter() fails on the second pass and returns an error, register_fprobe() returned directly without releasing module references acquired up to that point. Fix this by ensuring the cleanup loop executing module_put() runs even when get_ips_from_filter() returns a negative error. Link: https://lore.kernel.org/all/178528125360.101985.4144133640239273153.stgit@devnote2/ Fixes: d24fa977eec5 ("tracing: fprobe: Fix to lock module while registering fprobe") Assisted-by: Antigravity:gemini-3.6-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 84b5aa55de7c868ddca36ff0dc3f14dc1d9e1181 Author: Alexander Kaplan Date: Sat Jul 18 12:52:07 2026 +0200 drm/i915/dp: Ignore the sink's DSC max FRL rate without a PCON DSC encoder [ Upstream commit 8891e39e89042e285fd82fdde325d1311ec750a1 ] intel_dp_hdmi_sink_max_frl() limits the sink's max FRL rate by its DSC max FRL rate whenever the sink supports DSC 1.2. However, the DSC max FRL rate (HF-VSDB DSC_Max_FRL_Rate) only applies to compressed video transport, which requires a DSC 1.2 encoder in the PCON (configured via intel_dp_pcon_dsc_configure()). Without such an encoder the HDMI link always carries uncompressed video, for which the regular Max_FRL_Rate is the correct limit. Applying the DSC limit unconditionally trains the FRL link at a lower rate than both the PCON and the sink support. E.g. an LG OLED G4 (Max_FRL_Rate 48 Gbps, DSC_Max_FRL_Rate 24 Gbps) behind a Synaptics VMM7100 PCON (PCON max FRL bw 48 Gbps, no DSC encoder): Sink max rate from EDID = 24 Gbps FRL trained with : 24 Gbps while Windows/macOS train the same hardware at 40/48 Gbps. The too low FRL rate needlessly constrains the formats available to the sink. Only apply the sink's DSC max FRL rate if the PCON has a DSC 1.2 encoder, matching the gate in intel_dp_pcon_dsc_configure(). PCONs with a DSC encoder keep the current conservative behavior, since the link is trained once and compressed transport may be used for any subsequent mode. With this the setup above trains at 48 Gbps. Tested on PTL (xe) with the above PCON/sink combo. Fixes: 10fec80b48c5 ("drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding") Cc: Ankit Nautiyal Cc: Ville Syrjälä Reviewed-by: Ankit Nautiyal Signed-off-by: Alexander Kaplan Signed-off-by: Ankit Nautiyal Link: https://patch.msgid.link/20260718105207.5565-3-alexander.kaplan@sms-medipool.de (cherry picked from commit 71b57dd92f94569dca4bdf883fbd8ca5d4ed4bae) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 50edffd0854fe49d3c65a81a728dfefab5e02694 Author: Minhong He Date: Wed Jul 29 16:56:56 2026 +0800 can: isotp: check register_netdevice_notifier() error in module init [ Upstream commit ef09a13c5afac41a3c4b5f22b8572820d9e7518c ] Register the netdevice notifier before can_proto_register() and check the return value. If protocol registration fails, unregister the notifier before returning the error. Align isotp_module_init() with the reordering already done for raw.c (commit c28b3bffe49e ("can: raw: process optimization in raw_init()")) and bcm.c (commit edd1a7e42f1d ("can: bcm: registration process optimization in bcm_module_init()")). Fixes: 8d0caedb7596 ("can: bcm/raw/isotp: use per module netdevice notifier") Signed-off-by: Minhong He Link: https://patch.msgid.link/20260729085656.134523-1-heminhong@kylinos.cn Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit b4f8c33593f2586cd074fc2b72054e43774e37f0 Author: Chenguang Zhao Date: Thu Jul 23 10:18:20 2026 +0800 net: sxgbe: check descriptor ring allocation failures [ Upstream commit 51b093a7ba27476e1f639455f005e8d2e75390e4 ] sxgbe_open() ignores the return value of init_dma_desc_rings() and continues to program DMA with invalid ring addresses when allocation fails. Check the return value and disconnect the PHY on failure. Fixes: 1edb9ca69e8a ("net: sxgbe: add basic framework for Samsung 10Gb ethernet driver") Signed-off-by: Chenguang Zhao Reviewed-by: Vadim Fedorenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 42b87cfd9666ef156637c90ff3f6f6dd9a5ad4cb Author: Chenguang Zhao Date: Thu Jul 23 10:18:19 2026 +0800 net: sxgbe: free TX rings on RX allocation failure [ Upstream commit c870f7e2890b9f78ac84515a9809cc5c183c975e ] When RX descriptor ring allocation fails, init_dma_desc_rings() only frees the partially allocated RX rings and returns. The TX rings that were allocated earlier in the same function are leaked. Rearrange error labels to clean up TX rings upon RX failures. Fixes: 1edb9ca69e8a ("net: sxgbe: add basic framework for Samsung 10Gb ethernet driver") Signed-off-by: Chenguang Zhao Reviewed-by: Vadim Fedorenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 69a258a5a322ed7991ac433676fdfc1e294a16f6 Author: Leon Romanovsky Date: Wed Jul 22 09:30:10 2026 +0300 scsi: target: Clear cmd_cnt when initial counter enrollment fails [ Upstream commit a8ddfd2425bbbafadae8700d63ed8a61a4109878 ] When target_get_sess_cmd() fails during session shutdown because percpu_ref_tryget_live() returns false, the command keeps the se_cmd->cmd_cnt pointer that __target_init_cmd() assigned earlier without owning a reference. Final release through target_release_cmd_kref() then issues an unmatched percpu_ref_put(). Commit 8e288be8606a ("scsi: target: Pass in cmd counter to use during cmd setup") moved the cmd_cnt assignment ahead of the reference acquisition. Clear se_cmd->cmd_cnt whenever the initial target_get_sess_cmd() fails in target_init_cmd() and target_submit_tmr(), so release performs exactly one matching put per acquired reference. Fixes: 8e288be8606a ("scsi: target: Pass in cmd counter to use during cmd setup") Signed-off-by: Leon Romanovsky Reviewed-by: Mike Christie Link: https://patch.msgid.link/20260722-reference-count-underflow-in-target-v1-1-63ab664f12fd@nvidia.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 54c6fb24c60218daca73332b5d489c9f97c4d188 Author: Benjamin Block Date: Mon Jul 20 09:27:36 2026 +0200 scsi: zfcp: Fix memory leak during adapter release by destroying gid_pn_req [ Upstream commit b601fa590e667bd9643feed8c869b6b3e418480d ] When releasing an adapter we don't free the mempool 'gid_pn_req' that is allocated during the enqueue. This leaks memory: unreferenced object 0xd8d29297de700 (size 256): comm "(udev-worker)", pid 2105, jiffies 4294945794 hex dump (first 32 bytes): 00 00 00 00 de ad 4e ad ff ff ff ff 00 00 00 00 ......N......... ff ff ff ff ff ff ff ff 00 0d c4 5f 67 9d 99 e0 ..........._g... backtrace (crc 4a5b5da2): [<000dc45f64da418c>] kmemleak_alloc+0x6c/0xa0 [<000dc45f62b430aa>] __kmalloc_cache_node_noprof+0x36a/0x4d0 [<000dc45f629a535a>] mempool_create_node_noprof+0xaa/0x150 [<000dc45ee2c065e6>] zfcp_allocate_low_mem_buffers+0x96/0x370 [zfcp] [<000dc45ee2c070f8>] zfcp_adapter_enqueue+0x598/0xd40 [zfcp] [<000dc45ee2c08eb0>] zfcp_ccw_set_online+0x160/0x210 [zfcp] [<000dc45f643d4762>] ccw_device_set_online+0x232/0xd80 [<000dc45f643d53d4>] online_store_recog_and_online+0x124/0x390 [<000dc45f643d8238>] online_store+0x298/0x5b0 [<000dc45f62eb0a04>] kernfs_fop_write_iter+0x2c4/0x480 [<000dc45f62c81150>] new_sync_write+0x370/0x4b0 [<000dc45f62c87abe>] vfs_write+0x43e/0x5b0 [<000dc45f62c87ff4>] ksys_write+0x114/0x1f0 [<000dc45f621c4a16>] do_syscall+0x2f6/0x430 [<000dc45f64d9d5d8>] __do_syscall+0xc8/0x1c0 [<000dc45f64dc2224>] system_call+0x74/0xa0 Fix this by destroying the mempool during the adapter's release. Fixes: 799b76d09aee ("[SCSI] zfcp: Decouple gid_pn requests from erp") Signed-off-by: Benjamin Block Tested-by: M Nikhil Acked-by: M Nikhil Reviewed-by: Chinmaya Kajagar Reviewed-by: Nihar Panda Link: https://patch.msgid.link/20260720072736.3381816-2-niharp@linux.ibm.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ff333def314762b94e0933be7e84947d876f20bf Author: Bart Van Assche Date: Wed Jul 15 10:12:28 2026 -0700 scsi: ufs: core: Revert "Delegate the interrupt service routine to a threaded IRQ handler" [ Upstream commit 8a309036f557d3ff4efb2beea5132ba91172d934 ] There have been multiple reports of performance regressions caused by commit 3c7ac40d7322 ("scsi: ufs: core: Delegate the interrupt service routine to a threaded IRQ handler"). Hence this revert. This patch reverts most of the following commits: * 3c7ac40d7322 ("scsi: ufs: core: Delegate the interrupt service routine to a threaded IRQ handler") * 6475cfb81fc4 ("scsi: ufs: core: Avoid IRQ thread wakeup during active UIC command") This patch preserves the following commits: * 034d319c8899 ("scsi: ufs: core: Fix interrupt handling for MCQ Mode") * eabcac808ca3 ("scsi: ufs: core: Fix IRQ lock inversion for the SCSI host lock") Cc: Neil Armstrong Cc: 孙魁 (Kui Sun) Cc: André Draszik Cc: Gregory CLEMENT Cc: Sebastian Andrzej Siewior Fixes: 3c7ac40d7322 ("scsi: ufs: core: Delegate the interrupt service routine to a threaded IRQ handler") Signed-off-by: Bart Van Assche Reviewed-by: Sebastian Andrzej Siewior Tested-by: André Draszik # on Pixel 6 Reviewed-by: André Draszik Link: https://patch.msgid.link/b70eb60a01f971bed68c42c5b555929db5f835df.1784135511.git.bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c249cfe1d8df2e9c1de5c25b75245ea0c683e65a Author: Peter Wang Date: Fri Mar 6 13:43:02 2026 +0800 scsi: ufs: core: Avoid IRQ thread wakeup during active UIC command [ Upstream commit 6475cfb81fc4f6175b6d15d1c205a5168dc10b46 ] Only return IRQ_WAKE_THREAD when MCQ and ESI are not enabled and no UIC command is active. The default UIC command timeout is 500ms, Using threaded IRQs during an active UIC command increases the risk of timeout due to possible preemption by other system IRQs. Signed-off-by: Peter Wang Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260306054419.3816557-1-peter.wang@mediatek.com Signed-off-by: Martin K. Petersen Stable-dep-of: 8a309036f557 ("scsi: ufs: core: Revert "Delegate the interrupt service routine to a threaded IRQ handler"") Signed-off-by: Sasha Levin commit e504204489993d334675685d2d4c2f70da68d7dd Author: Guangshuo Li Date: Wed Jul 15 01:27:26 2026 +0800 scsi: ufs: core: Cancel RTC work in active-active suspend [ Upstream commit f71b4a30983b846b4075bf544e835121e70e6a43 ] UFS RTC support schedules ufs_rtc_update_work to periodically update the device RTC. The work can issue query commands and access the UFS host controller. A previous change moved the RTC work cancellation before the PRE_CHANGE vendor suspend callback to close a race in the common suspend path. However, the active-active path jumps directly to vops_suspend after flushing exception handling work and therefore bypasses the cancellation. If the RTC work runs while the vendor suspend callback is gating or otherwise changing hardware state, it can access the controller during suspend and trigger an SError. Cancel the RTC work before entering the vendor suspend callback in the active-active path. Since this path now cancels the work, move the RTC work scheduling outside the device and link state restoration block in the resume path. This restarts RTC updates after an active-active suspend and resume cycle. Fixes: b0bd84c39289 ("scsi: ufs: core: Fix SError in ufshcd_rtc_work() during UFS suspend") Signed-off-by: Guangshuo Li Reviewed-by: Peter Wang Reviewed-by: Bean Huo Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260714172726.1736967-1-lgs201920130244@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bdd8a1297ef101bb5ac57e53b4fbe5e364afd8b1 Author: TanZheng Date: Fri Jul 24 15:58:50 2026 +0800 scsi: target: iblock: Fix wrong PR ops NULL check for PREEMPT/RELEASE [ Upstream commit 9c33222bd387312874fbe36ca8002e5c945b9653 ] In the iblock_execute_pr_out() function, PRO_PREEMPT, PRO_PREEMPT_AND_ABORT, and PRO_RELEASE all perform callback capability checks through ops->pr_clear. The error check allows unimplemented hooks to pass through the gate, resulting dereferencing a NULL function pointer. Check whether the hooks that need to be called are supported. Fixes: 394f81184882 ("scsi: target: Add block PR support to iblock") Signed-off-by: TanZheng Reviewed-by: Mike Christie Link: https://patch.msgid.link/20260724075850.280699-1-kensanya@163.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 613aaeeaf8cb129c7178bc8c73f2302137a05e25 Author: Christian Marangi Date: Sun Jul 26 17:08:05 2026 +0200 net: phylink: put link_gpio if phylink_create fails [ Upstream commit 0fe1e3e8f3380d7862296a73b528d164e96c76b8 ] In phylink_create() if phylink_register_sfp() returns an error, link_gpio obtained by phylink_parse_fixedlink() is never released. While this is a very unlikely scenario, it's worth to fix/handle this. This was present from the very first implementation of phylink but got relevant only with the introduction of ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages") where additional function were added after phylink_parse_fixedlink() making the release of link_gpio needed if such additional function errored out. While at it, restructure the exit condition of phylink_create() with the goto pattern to reduce code duplication on handling error conditions. Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages") Signed-off-by: Christian Marangi Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260726150806.2437-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5ea70ad040c1b397da5900255e211c88817dfb4d Author: Mauricio Faria de Oliveira Date: Thu Jul 23 20:08:04 2026 -0300 x86/boot: Add volatile, clobbers and zero-length test in memcmp() [ Upstream commit a8c171c107c0b61a5e7e10cedab0fb72aeaf640d ] Add the volatile qualifier and clobbers parameter to prevent bugs with instruction reordering and optimization. Also add TEST for the zero-length case to set ZF, as, if the count register is zero, the REPE prefix does not run the CMPSB instruction, leaving the ZF flag undetermined. [ bp: Add a comment about the len==0 case. ] Fixes: 62bd0337d0c4 ("Top header file for new x86 setup code") Closes: https://sashiko.dev/#/patchset/20260701-pvh-kasan-inline-v6-0-ba99045dfa9f%40igalia.com Suggested-by: Borislav Petkov Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/all/20260721-pvh-kasan-inline-v7-2-38979a50cef0@igalia.com Signed-off-by: Sasha Levin commit 5576afebf726c53d4bfe02d261ae8cc900be4f8b Author: Pauli Virtanen Date: Sat Jul 25 12:59:22 2026 +0300 Bluetooth: hci_sync: fix hci_conn_del() use in hci_le_create_conn_sync [ Upstream commit 2c1e4e00613dfd105f978be2276e5e265801ec9f ] hci_conn_del() caller must hold hdev->lock, check the conn was not concurrently deleted, and usually inform socket the conn is going to be deleted. Use hci_abort_conn_sync() instead of calling hci_conn_del() without locks etc. Fixes: 8e8b92ee60de5 ("Bluetooth: hci_sync: Add hci_le_create_conn_sync") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e8f9fef362bab431d95371d3406bc720350290c3 Author: Pauli Virtanen Date: Sat Jul 25 12:59:17 2026 +0300 Bluetooth: hci_conn: hold conn reference in abort_conn_sync() [ Upstream commit 5761d003daa987ac81463f570713ce9c9dd204e5 ] There is theoretical UAF if the conn is freed while the hci_sync task is running. Hold refcount to avoid that. Fixes: 227a0cdf4a02 ("Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit de17305393ec82bc025fe63a71344c1e64708f38 Author: Pauli Virtanen Date: Wed Mar 25 21:07:45 2026 +0200 Bluetooth: hci_sync: make hci_cmd_sync_run_once return -EEXIST if exists [ Upstream commit d288f4db0909c22342eb50cd1632b4d850517281 ] hci_cmd_sync_run_once() needs to indicate whether a queue item was added, so caller can know if callbacks are called, so it can avoid leaking resources. Change the function to return -EEXIST if queue item already exists. Modify all callsites vs. the changes. The only callsite is hci_abort_conn(). Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 5761d003daa9 ("Bluetooth: hci_conn: hold conn reference in abort_conn_sync()") Signed-off-by: Sasha Levin commit c618a9a5b08ea2e17bddf4e948be9f75d408fca4 Author: Zijun Hu Date: Sat Jul 25 01:54:40 2026 -0700 Bluetooth: btintel: Validate length before parsing diagnostics TLV [ Upstream commit b640ff9af3c809ff5ea2077fbba17df1594ec1e4 ] btintel_diagnostics() accesses tlv->val[0] without first validating that the diagnostics VSE is long enough to contain that field, so may cause reading data beyond the received frame. Fix by validating the length before access. Fixes: af395330abed ("Bluetooth: btintel: Add Intel devcoredump support") Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3b921533e8aa95b77aadcf31737595578e735f3c Author: Pauli Virtanen Date: Fri Jul 24 23:20:33 2026 +0300 Bluetooth: ISO: fix refcounting of iso_conn [ Upstream commit fdfde532ab1caa165fcd8985001157ac8b4db365 ] iso_conn_del() and iso_chan_del() have a race that results to double-put of iso_conn: [Task hdev->workqueue] [Task 2] iso_conn_del iso_chan_del iso_conn_hold_unless_zero iso_conn_lock iso_conn_lock conn->sk = NULL iso_conn_unlock sk = iso_sock_hold(conn) <---------´ if (!sk) iso_conn_put iso_conn_put iso_conn_put /* UAF */ The extra put for !sk in iso_conn_del() is currently required since failing iso_chan_add() may leave iso_conn not associated with any sk. Fix by having iso_pi(sk)->conn own refcount when non-NULL, so iso_conn_del does not need to put it. Adjust the iso_conn_add() refcounting so that conn is put if it does not get associated with an sk. Fixes: dc26097bdb86 ("Bluetooth: ISO: Use kref to track lifetime of iso_conn") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e941799c31f68e67ce0976efb38a79101f921b64 Author: Pauli Virtanen Date: Fri Jul 24 23:20:32 2026 +0300 Bluetooth: ISO: ensure no dangling hcon references in iso_conn [ Upstream commit aa9f7cb2bd3a2be998ceb739fc9a2f986eba43eb ] After iso_conn_del(), ISO sockets should not dereference the hcon any more. Currently, clearing iso_conn::hcon relies on iso_conn_del() releasing the last reference to the iso_conn. Simplify this by explicitly clearing conn->hcon in iso_conn_del(), to avoid more complex reasoning on races about who holds the last reference. Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: fdfde532ab1c ("Bluetooth: ISO: fix refcounting of iso_conn") Signed-off-by: Sasha Levin commit 82e982f54f962f72646868ddbb2c3bd9ea178568 Author: Pauli Virtanen Date: Fri Jul 24 23:20:31 2026 +0300 Bluetooth: ISO: avoid deadlocks in iso_sock_timeout [ Upstream commit 200fa1629c57a3ca2b03d3ca63fd3a9bfd910c43 ] iso_sock_timeout() takes lock_sock, so sync disabling the timer while holding that lock may deadlock. iso_sock_timeout() may also run concurrently with iso_conn_del(), which leads to UAF [Task 1] [Task hdev->workqueue] iso_sock_timeout iso_conn_del iso_conn_hold_unless_zero iso_chan_del `------------> iso_conn_put caller frees hcon iso_conn_put iso_conn_free conn->hcon->iso_data = NULL; /* UAF */ Fix the deadlock by removing the disable from the lock_sock sections. Move the timer from iso_conn to iso_pinfo to decouple it from iso_conn which may need to be freed in lock_sock section. Convert some of the clear_timer to disable_timer. Fixes: dc26097bdb86 ("Bluetooth: ISO: Use kref to track lifetime of iso_conn") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e76a0ae6542ae43241b2147bacf4990e7ae5316a Author: Pauli Virtanen Date: Fri Jul 24 23:20:30 2026 +0300 Bluetooth: ISO: fix leaking sk after socket release [ Upstream commit ce57442a379212fe3fda59c9437ee8217eceb5b1 ] iso_sock_kill() tests !sock_flag(sk, SOCK_ZAPPED) || sk->sk_socket || sock_flag(sk, SOCK_DEAD) for early return, but this is always true since sock_orphan(sk) sets SOCK_DEAD, so the sk reference released by socket always leaks, iso_sock_destruct is never called. The socket reference also leaks when __iso_sock_close() does not set SOCK_ZAPPED, since iso_conn_del() does not call iso_sock_kill() after zapping. Fix by replacing SOCK_DEAD by BT_SK_KILLED flag that is not used for something else, and lock_sock to ensure iso_sock_kill() puts sk only after socket release only once. Release and iso_conn_del may run concurrently. Call iso_sock_kill() from iso_conn_del() to clean sk up after zapping. Remove call to iso_sock_kill() from iso_sock_close(), as it's generally no-op there. Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4e9b5e8669b3602a4e01b6d1e9539b72e42c84d5 Author: Pauli Virtanen Date: Fri Jul 24 23:20:29 2026 +0300 Bluetooth: ISO: hold sk properly in iso_conn_ready [ Upstream commit 0d255e63fcf3f13a570d7ac11678fa1164ac015c ] sk deref in iso_conn_ready must be done either under conn->lock, or holding a refcount, to avoid concurrent close. conn->sk is currently accessed without either: [Task 1] [Task 2] iso_sock_release iso_conn_ready sk = conn->sk lock_sock(sk) conn->sk = NULL lock_sock(sk) release_sock(sk) iso_sock_kill(sk) UAF on sk deref Fix possible UAF by holding sk refcount in iso_conn_ready(). Also recheck after lock_sock that the socket is still valid. Adjust locking so conn->sk is cleared only under lock_sock. Fixes: 27c24fda62b60 ("Bluetooth: switch to lock_sock in SCO") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 09a69828ae59430dcf03a9e654ae6d6c193bfb82 Author: Pauli Virtanen Date: Fri Jul 24 23:20:24 2026 +0300 Bluetooth: ISO: fix CONNECTED -> CLOSED transition on shutdown/release [ Upstream commit 0786469ee242952008628ed0e2d386098e2065ab ] Commit d57e506f6a1e ("Bluetooth: ISO: clear iso_data always when detaching conn from hcon") merged a version of the UAF fix that breaks releasing connected ISO sockets. Since hci_conn::iso_data is set to NULL, iso_chan_del() won't be called when the hci_conn disconnects, and the ISO socket does not emit POLLHUP correctly. Fix by retaining full hci_conn <-> iso_conn association while in BT_DISCONNECT state, so that local disconnect via shutdown() follows similar ISO socket code path as remote disconnect. Use a separate flag to track whether hci_conn_drop() is needed, instead of setting iso_conn::hcon = NULL In iso_sock_ready(), disallow disconnecting socket going BT_CONNECTED, in case hcon connects while its drop is pending. Fixes: d57e506f6a1e ("Bluetooth: ISO: clear iso_data always when detaching conn from hcon") Fixes: fbdc4bc47268 ("Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 0d255e63fcf3 ("Bluetooth: ISO: hold sk properly in iso_conn_ready") Signed-off-by: Sasha Levin commit cde36776cfe6451736da07c4ad5e40d80295e812 Author: Luiz Augusto von Dentz Date: Mon Oct 6 16:53:35 2025 -0400 Bluetooth: ISO: Fix not updating BIS sender source address [ Upstream commit 577cf4c0a1e8471a0d6c0f36bb3716285e27ad5e ] The source address for a BIS sender/Broadcast Source shall be updated with the advertisement address since in case privacy is enabled it may use an RPA rather than an identity address. Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 0d255e63fcf3 ("Bluetooth: ISO: hold sk properly in iso_conn_ready") Signed-off-by: Sasha Levin commit dfce8d30fc5be816c06095868e1cc8fb8ee503cb Author: Pauli Virtanen Date: Fri Jul 24 23:20:28 2026 +0300 Bluetooth: ISO: validate sockaddr_iso first in iso_sock_rebind_bis() [ Upstream commit 4e20192d46a685d73e590a60a4a2419a0a8afcbf ] iso_sock_rebind_bis() updates socket iso_pi(sk)->bc_num_bis before validating the BIS values, so it's possible to end up with bc_num_bis inconsistent. Assign to iso_pi(sk)->bc_num_bis only after validation. Fixes: 80837140c1f2 ("Bluetooth: ISO: Allow binding a PA sync socket") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1fc2132950c23d65c203ad9b9ecb463a7088f9e5 Author: Pauli Virtanen Date: Fri Jul 24 23:20:27 2026 +0300 Bluetooth: ISO: fix timeout vs sync_timeout typo in check_bcast_qos [ Upstream commit e9cb51813d79fc9aae4a2098aab3ab6ebd7fb6c8 ] In iso.c check_bcast_qos(), missing bcast.timeout is not set to its default value, and appears typoed as bcast.sync_timeout. Fix the typo. Fixes: b37cab587aa3 ("Bluetooth: ISO: Don't reject BT_ISO_QOS if parameters are unset") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit e8e9cff6d80eeec28dec4cf7cc18662986945391 Author: Pauli Virtanen Date: Fri Jul 24 23:20:26 2026 +0300 Bluetooth: ISO: lock sk in iso_connect_ind [ Upstream commit 4311fd6f429065a8ba208660360a895627a00cf3 ] Accessing iso_pi(sk)->conn requires lock_sock, which is not taken in the "ev3" part of iso_connect_ind. It may also be NULL if socket has transitioned away from the LISTEN/CONNECT states before locking. Fix by adding lock/release. Recheck hcon is valid after lock acquire where needed. Fixes: 168d9bf9c7f0 ("Bluetooth: ISO: Reassemble PA data for bcast sink") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3120664aa3330488386d3809af06e4944d073c5f Author: SeungJu Cheon Date: Tue Apr 21 11:51:22 2026 +0900 Bluetooth: ISO: Fix data-race on iso_pi(sk) in socket and HCI event paths [ Upstream commit f958c7805b18e9d69f6b322b231ecee46ec6f331 ] Several iso_pi(sk) fields (qos, qos_user_set, bc_sid, base, base_len, sync_handle, bc_num_bis) are written under lock_sock in iso_sock_setsockopt() and iso_sock_bind(), but read and written under hci_dev_lock only in two other paths: - iso_connect_bis() / iso_connect_cis(), invoked from connect(2), read qos/base/bc_sid and reset qos to default_qos on the qos_user_set validation failure -- all without lock_sock. - iso_connect_ind(), invoked from hci_rx_work, writes sync_handle, bc_sid, qos.bcast.encryption, bc_num_bis, base and base_len on PA_SYNC_ESTABLISHED / PAST_RECEIVED / BIG_INFO_ADV_REPORT / PER_ADV_REPORT events. The BIG_INFO handler additionally passes &iso_pi(sk)->qos together with sync_handle / bc_num_bis / bc_bis to hci_conn_big_create_sync() while setsockopt may be mutating them. Acquire lock_sock around the affected accesses in both paths. The locking order hci_dev_lock -> lock_sock matches the existing iso_conn_big_sync() precedent, whose comment documents the same requirement for hci_conn_big_create_sync(). The HCI connect/bind helpers do not wait for command completion -- they enqueue work via hci_cmd_sync_queue{,_once}() / hci_le_create_cis_pending() and return -- so the added hold time is comparable to iso_conn_big_sync(). KCSAN report: BUG: KCSAN: data-race in iso_connect_cis / iso_sock_setsockopt read to 0xffffa3ae8ce3cdc8 of 1 bytes by task 335 on cpu 0: iso_connect_cis+0x49f/0xa20 iso_sock_connect+0x60e/0xb40 __sys_connect_file+0xbd/0xe0 __sys_connect+0xe0/0x110 __x64_sys_connect+0x40/0x50 x64_sys_call+0xcad/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f write to 0xffffa3ae8ce3cdc8 of 60 bytes by task 334 on cpu 1: iso_sock_setsockopt+0x69a/0x930 do_sock_setsockopt+0xc3/0x170 __sys_setsockopt+0xd1/0x130 __x64_sys_setsockopt+0x64/0x80 x64_sys_call+0x1547/0x1c60 do_syscall_64+0x133/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reported by Kernel Concurrency Sanitizer on: CPU: 1 UID: 0 PID: 334 Comm: iso_setup_race Not tainted 7.0.0-10949-g8541d8f725c6 #44 PREEMPT(lazy) The iso_connect_ind() races were found by inspection. Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Signed-off-by: SeungJu Cheon Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 4311fd6f4290 ("Bluetooth: ISO: lock sk in iso_connect_ind") Signed-off-by: Sasha Levin commit f1f167991a68fb4a458ebbd98e511733abdd0e11 Author: Luiz Augusto von Dentz Date: Tue Sep 2 11:11:40 2025 -0400 Bluetooth: HCI: Add initial support for PAST [ Upstream commit 33b2835f0b7e2a458473b0e3a23b54b92108b6b0 ] This adds PAST related commands (HCI_OP_LE_PAST, HCI_OP_LE_PAST_SET_INFO and HCI_OP_LE_PAST_PARAMS) and events (HCI_EV_LE_PAST_RECEIVED) along with handling of PAST sender and receiver features bits including new MGMG settings ( HCI_EV_LE_PAST_RECEIVED and MGMT_SETTING_PAST_RECEIVER) which userspace can use to determine if PAST is supported by the controller. Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 4311fd6f4290 ("Bluetooth: ISO: lock sk in iso_connect_ind") Signed-off-by: Sasha Levin commit 72d5bb1d77d7c3330146dc0cfd43f704c64b9594 Author: Pauli Virtanen Date: Fri Jul 24 23:20:25 2026 +0300 Bluetooth: ISO: lock sk in iso_sock_getname [ Upstream commit 89cf154d7c18e6e94a3da83051f3cf2bac317ae2 ] Accessing iso_pi(sk)->conn requires lock_sock, which is not held here. Fix by adding the lock/release. Fixes: 2df108c227b2 ("Bluetooth: ISO: Fix using BT_SK_PA_SYNC to detect BIS sockets") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 58e3c5289ad230a7e24ae4b0c7b43f5ee6e32136 Author: Jiale Yao Date: Thu Jul 23 14:48:45 2026 +0800 Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp [ Upstream commit c4740e7f23ff9a8210198d8b4703259e21b9f69d ] l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers. Fixes: f1496dee9cbd ("Bluetooth: Add initial code for LE L2CAP Connect Request") Assisted-by: Claude:deepseek-v4-pro Signed-off-by: Jiale Yao Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 63c0f396a18b767eb28e895eb95bbdce6c172c59 Author: Pauli Virtanen Date: Mon Jul 20 17:53:33 2026 +0300 Bluetooth: ISO: clear iso_data always when detaching conn from hcon [ Upstream commit d57e506f6a1e3929611340fae87c1e4823f4d85c ] When setting conn->hcon = NULL, also conn->hcon->iso_data = NULL is necessary, otherwise later iso_conn_free() will UAF. Fix clearing of iso_data in iso_sock_disconn() Fixes KASAN: slab-use-after-free in iso_conn_hold_unless_zero on iso_sock_release() followed by hci_abort_conn_sync(). Fixes: fbdc4bc47268 ("Bluetooth: ISO: Use defer setup to separate PA sync and BIG sync") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 4e1f45de5b313db2a3f2eea72d79b82463bb21e1 Author: Przemyslaw Korba Date: Wed May 20 13:50:06 2026 +0200 ice: suppress DPLL errors during reset recovery [ Upstream commit b00be7c6b4bd7da3d510753b27ff6cb7ec647d07 ] During reset recovery, the admin queue returns EBUSY which is expected behavior. However, the DPLL subsystem was logging these as errors and incrementing the error counter, potentially leading to unnecessary warnings and even disabling the DPLL periodic worker if the threshold was reached. Suppress error logging and error counter increments when the admin queue returns EBUSY, as this is expected during reset recovery and not a real failure condition. test case: - ethtool --reset eth3 irq-shared dma-shared filter-shared offload-shared mac-shared phy-shared ram-shared - observe if dmesg EBUSY errors are gone Fixes: d7999f5ea64b ("ice: implement dpll interface to control cgu") Signed-off-by: Przemyslaw Korba Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 6ebbf198e76cab27a41570b644b6c58246e8cf95 Author: Yuho Choi Date: Fri Jul 3 01:03:32 2026 -0400 idpf: Fix mailbox IRQ name leak on request failure [ Upstream commit 9bff30482c10f70d9e56c0633a6616e07140e217 ] idpf_mb_intr_req_irq() allocates the mailbox IRQ name before calling request_irq(). On success, the name is released later through kfree(free_irq()), but request_irq() failure returns without freeing it. Free the allocated name on the request_irq() failure path. Fixes: 4930fbf419a7 ("idpf: add core init and interrupt request") Signed-off-by: Yuho Choi Reviewed-by: Aleksandr Loktionov Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit d44081c61dc9244283c86f12fee037834f8b4600 Author: Joshua Hay Date: Tue Jun 30 16:56:19 2026 -0700 idpf: adjust TxQ ring count minimum [ Upstream commit bef152db47debcd14cbacefc5767f6f026c4bc89 ] Set the TxQ ring count minimum to 128 descriptors. Any lower than this, and the queue will stall and trigger Tx timeouts in flow based scheduling mode. This is because next_to_clean might never be updated. In flow based scheduling mode, next_to_clean is only updated after a descriptor completion is processed, i.e. after the RE bit is set in the last descriptor of a Tx packet. This will never happen with a ring size of 64 and an IDPF_TX_SPLITQ_RE_MIN_GAP of 64. No matter what the value of last_re is initialized/set to, the calculated gap will be at most 63 and never trigger the RE bit. Even a ring size of 96 does not solve this. Because of how infrequent next_to_clean is updated and how small the ring is, IDPF_DESC_UNUSED will be much smaller on average. This increases the chance the queue will be stopped because a multi-descriptor packet, e.g. a large LSO packet, does not see enough resources on the ring. In this case, the queue will trigger the stop logic. The queue permanently stalls because there is no chance for a descriptor completion to update next_to_clean since it is dependent on a packet being sent. Fixes: 5f417d551324 ("idpf: replace flow scheduling buffer ring with buffer pool") Signed-off-by: Joshua Hay Reviewed-by: Aleksandr Loktionov Tested-by: Samuel Salin Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit ae7120102e1bbe2c6167a98454bddde55ecc8357 Author: Guenter Roeck Date: Tue Jul 28 08:41:40 2026 -0700 hwmon: (pmbus) Fix return value from pmbus_update_byte_data() [ Upstream commit a19038a200f18d9e74ac30081797917d0886e16b ] pmbus_update_byte_data() is supposed to return a negative error code or 0. However, if no change is made to the register, it actually returns the register value. This can result in problems if the calling code explicitly expects to see an error code or 0. Fix it to return 0 on success or the error code as expected. Fixes: 11c119986f270 ("hwmon: (pmbus) add helpers for byte write and read modify write") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 276f1f180f55d56cf5992a581e20ed2b3dfa6ced Author: Chenguang Zhao Date: Thu Jul 23 13:57:35 2026 +0800 net: ethernet: mtk_eth_soc: pass eth to mtk_handle_irq_rx in poll_controller [ Upstream commit e095f249e2209674f6366f6db0383a2b96e19239 ] mtk_handle_irq_rx expects a struct mtk_eth * (matching the request_irq cookie), but mtk_poll_controller incorrectly passed the net_device *. Calling ndo_poll_controller with CONFIG_NET_POLL_CONTROLLER enabled would then crash. Fixes: 8186f6e382d8 ("net-next: mediatek: fix compile error inside mtk_poll_controller()") Signed-off-by: Chenguang Zhao Link: https://patch.msgid.link/20260723055735.885112-1-chenguang.zhao@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2c148a31ca01fc160aceec777bbc0041b0d0b8bd Author: Yichong Chen Date: Mon Jul 27 14:07:14 2026 +0100 netfs: release readahead folios on iterator preparation failure [ Upstream commit 87eb3d272dcbcbbfe5c1576c10e5dc72810cf1f6 ] netfs_prepare_read_iterator() batches readahead folios in put_batch so that the folio references can be dropped after the I/O iterator has been prepared. If rolling_buffer_load_from_ra() fails after earlier folios have been batched, the function returns immediately and leaves those references held. Release the batch before returning the error. Fixes: 06fa229ceb36 ("netfs: Abstract out a rolling folio buffer implementation") Signed-off-by: Yichong Chen Signed-off-by: David Howells Link: https://patch.msgid.link/20260727130716.1099906-4-dhowells@redhat.com cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 291ebecdf315d222afd6ef3fc6b67c8bba51c2f1 Author: Yichong Chen Date: Mon Jul 27 14:07:13 2026 +0100 netfs: handle single writeback rolling buffer allocation failure [ Upstream commit 37a1c535c80c67d98668d190c7432f9ebda43310 ] netfs_write_folio_single() takes an extra folio reference before appending the folio to the rolling buffer. rolling_buffer_append() can fail if it cannot allocate another folio_queue. Check the return value and drop the extra folio reference before returning the error. Fixes: 49866ce7ea8d ("netfs: Add support for caching single monolithic objects such as AFS dirs") Signed-off-by: Yichong Chen Signed-off-by: David Howells Link: https://patch.msgid.link/20260727130716.1099906-3-dhowells@redhat.com cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 627826ef4208042b0470d1a3fdb729ce35471a0d Author: Yichong Chen Date: Mon Jul 27 14:07:12 2026 +0100 netfs: clear PG_private_2 on copy-to-cache append failure [ Upstream commit a81fc9266e1c5fef9ccf675a9b44b2f4ab464923 ] netfs_pgpriv2_copy_to_cache() marks the folio with PG_private_2 before netfs_pgpriv2_copy_folio() appends it to the copy-to-cache rolling buffer. If the append fails, the folio is not queued for cache writeback, so the PG_private_2 state and its reference must be released immediately. Fixes: e2d46f2ec332 ("netfs: Change the read result collector to only use one work item") Signed-off-by: Yichong Chen Signed-off-by: David Howells Link: https://patch.msgid.link/20260727130716.1099906-2-dhowells@redhat.com cc: Paulo Alcantara cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit b558e07708d886acfcf4b0391ed7a8546e81d326 Author: Zhao Li Date: Thu Jul 23 09:09:28 2026 +0800 wifi: mac80211: validate individual TWT params before driver setup [ Upstream commit 0502d5077e419427d80f4d46ba95d0067f5fb916 ] ieee80211_process_rx_twt_action() only partially validates a received S1G TWT setup frame before queueing it. An individual agreement can therefore reach ieee80211_s1g_rx_twt_setup() with twt->length too short for the full struct ieee80211_twt_params. The individual path passes twt to drv_add_twt_setup(). Both the tracepoint and the driver callback consume the complete parameters block, not merely req_type. Do not pass a short individual agreement to the driver. Broadcast agreements remain unchanged because they are rejected locally after accessing only req_type. Fixes: f5a4c24e689f ("mac80211: introduce individual TWT support in AP mode") Assisted-by: Codex:gpt-5 Assisted-by: Claude:opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260723010928.76551-1-enderaoelyther@gmail.com [edit commit message to not overclaim lack of validation nor understate driver impact] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f82a2ded3d7a9098267c84f14eafdb98c4550ac5 Author: Eric Dumazet Date: Fri Jul 24 09:11:37 2026 +0000 net: udp_tunnel: fix memory leak in udp_tunnel_nic_unregister() [ Upstream commit 080695e6f005e2396f1207fd69d24c442cb230c6 ] syzbot reported a memory leak [1] in the UDP tunnel NIC offload code. When device registration fails (e.g. in register_netdevice()), netdev core unwinds by sending a single NETDEV_UNREGISTER notification. If work was queued during NETDEV_REGISTER (utn->work_pending is set), udp_tunnel_nic_unregister() returns early: if (utn->work_pending) return; Because failed registrations do not enter netdev_wait_allrefs_any(), no subsequent NETDEV_UNREGISTER rebroadcast will ever occur. As a result, the struct udp_tunnel_nic allocated in udp_tunnel_nic_alloc() is leaked permanently. Fix this by removing the early return. Instead, synchronously cancel any pending work with cancel_delayed_work_sync() before freeing @utn. To be able to call cancel_delayed_work_sync() while holding RTNL (the work also needs RTNL), switch udp_tunnel_nic_device_sync_work() to rtnl_trylock(). If RTNL is contended, requeue the work with a 1 jiffy delay (via queue_delayed_work()) to prevent high CPU contention while waiting for RTNL lock. The utn->work_pending bookkeeping is no longer needed and is removed, as the workqueue core already tracks the pending/running state of the work. [1] BUG: memory leak unreferenced object 0xffff888127d5f840 (size 96): comm "syz-executor", pid 5806, jiffies 4294942188 backtrace (crc 99fdb6c8): __kmalloc_noprof+0x3bf/0x550 udp_tunnel_nic_alloc net/ipv4/udp_tunnel_nic.c:756 [inline] udp_tunnel_nic_register net/ipv4/udp_tunnel_nic.c:833 [inline] udp_tunnel_nic_netdevice_event+0x804/0xab0 net/ipv4/udp_tunnel_nic.c:931 notifier_call_chain+0x59/0x160 kernel/notifier.c:85 call_netdevice_notifiers_info+0x7d/0xb0 net/core/dev.c:2250 register_netdevice+0xc10/0xeb0 net/core/dev.c:11478 Fixes: cc4e3835eff4 ("udp_tunnel: add central NIC RX port offload infrastructure") Reported-by: syzbot+eca845fb8c18dd6b44c1@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a632b15.dde6c935.cf6c8.0011.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Link: https://patch.msgid.link/20260724091137.1792543-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit acbf711a20669395d34efa8070f57a1a43bc18ed Author: Thorsten Blum Date: Thu Jul 2 23:15:57 2026 +0200 powerpc/boot: Fix treeboot-akebono CPU node lookup check [ Upstream commit b24fc8278b70a9d27ec801a427ab4de9b769d69a ] fdt_node_offset_by_prop_value() returns a negative error code on failure - fix the check accordingly. Fixes: 2a2c74b2efcb ("IBM Akebono: Add the Akebono platform") Signed-off-by: Thorsten Blum Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260702211554.56923-6-thorsten.blum@linux.dev Signed-off-by: Sasha Levin commit b407b98cf665d230d9c89fc8c2b4ba87a7205b42 Author: Thorsten Blum Date: Thu Jul 2 23:15:56 2026 +0200 powerpc/boot: Fix treeboot-currituck CPU node lookup check [ Upstream commit 43863f6575d2211e8c5157fefb83ad0ad046aab4 ] fdt_node_offset_by_prop_value() returns a negative error code on failure - fix the check accordingly. Fixes: 228d55053397 ("powerpc/47x: Add support for the new IBM currituck platform") Signed-off-by: Thorsten Blum Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260702211554.56923-5-thorsten.blum@linux.dev Signed-off-by: Sasha Levin commit 3d24f2e5641b24ce961c0161e8ec1bd33cd92142 Author: Thorsten Blum Date: Thu Jul 2 23:15:55 2026 +0200 powerpc/boot: Fix simpleboot CPU node lookup check [ Upstream commit c824ab65685bb119c6c6a3a200b3428c72862d5a ] fdt_node_offset_by_prop_value() returns a negative error code on failure - fix the check accordingly. Fixes: d2477b5cc8ca ("[POWERPC] bootwrapper: Add a firmware-independent simpleboot target.") Signed-off-by: Thorsten Blum Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260702211554.56923-4-thorsten.blum@linux.dev Signed-off-by: Sasha Levin commit db986098f30881fafcc752800aa3b13fd289c922 Author: Yun Lu Date: Tue Jul 21 10:38:36 2026 +0800 rtase: fix double free of multi-frag skb on DMA map failure [ Upstream commit 6fb7b769d6ed6d1d2e02af4a80e57a2477f35086 ] In rtase_start_xmit(), when the head buffer DMA mapping fails after rtase_xmit_frags() has mapped all fragments, the error path clears the fragment descriptors with rtase_tx_clear_range(), which frees the skb through the last-frag slot and accounts tx_dropped. Control then falls through to the common error label, which frees the same skb a second time and counts it again. Return right after clearing the fragments when the skb owns frags; the no-frag case still drops through and frees the head skb once. Fixes: d6e882b89fdf ("rtase: Implement .ndo_start_xmit function") Signed-off-by: Yun Lu Reviewed-by: Jacob Keller Reviewed-by: Justin Lai Link: https://patch.msgid.link/20260721023836.6691-1-luyun_611@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5a6b0ccb8b01819c24a8f0af4b67b6f5833032ec Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:24 2026 -0300 hwmon: (adt7470) Fix PWM auto temp state array and bounds check [ Upstream commit 92413f439d1ec5e55b73ede8d66a7b971cbd1ced ] In pwm_auto_temp_store(), the parsed user input was missing bounds checks, allowing values > 0xF to overflow into the adjacent channel's bits. Furthermore, the value was being incorrectly written to the pwm_automatic state array instead of pwm_auto_temp. Fix this by rejecting values > 0xF with -EINVAL, and assigning the value to the correct array only after a successful I2C write. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260727034932.0B7C41F000E9@smtp.kernel.org/#t Fixes: 6f9703d0be16 ("hwmon: add support for adt7470") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-8-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 96ad57d31763559d376416cdf3bf5ae79bbbebec Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:23 2026 -0300 hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read [ Upstream commit 1b46fe9dc8f8de59310f37e6c5e5c0e05ded46c3 ] If the fan data becomes 0 between the FAN_DATA_VALID() check and the FAN_PERIOD_TO_RPM() conversion, it will result in a divide-by-zero crash due to a race with a concurrent update of the cached fan value. Fix a TOCTOU issue by reading fan data once. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/r/20260727034929.E29B71F000E9@smtp.kernel.org/ Fixes: fc958a61ff6d ("hwmon: (adt7470) Convert to devm_hwmon_device_register_with_info API") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-7-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ddd689bd7226435576e07346b7c4b0e1e808590c Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:22 2026 -0300 hwmon: (adt7470) Use cached PWM frequency value [ Upstream commit 60677cd4c28f44d5b307d3029dccece38fcce90f ] adt7470_pwm_read() currently ignores failures returned by pwm1_freq_get(). If the register read fails, the negative error code is returned through *val while the function itself reports success, potentially exposing a negative PWM frequency through sysfs. Fix this by using the cached PWM frequency maintained by the driver, eliminating the register access from the read path. Apart from the corrected error propagation and using the cached value, no functional change is intended. Fixes: ef67959c4253 ("hwmon: (adt7470) Convert to use regmap") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-6-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 1d6b54dbe88500c927298f2cb0062b6a6fa4b865 Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:20 2026 -0300 hwmon: (adt7470) Fix swapped PWM3 and PWM4 auto mode masks [ Upstream commit a3850231521b06bbbb18c8ebea100320c14a08be ] The ADT7470_PWM3_AUTO_MASK and ADT7470_PWM4_AUTO_MASK macros are currently defined with swapped bit values. According to Table 22 of the ADT7470 datasheet, the Fan Control Mode Configuration for register 0x69 follows the exact same bit position layout as register 0x68: - 0x68 Bit[7] corresponds to BHVR1 (PWM1) -> 0x80 - 0x68 Bit[6] corresponds to BHVR2 (PWM2) -> 0x40 - 0x69 Bit[7] corresponds to BHVR3 (PWM3) -> 0x80 - 0x69 Bit[6] corresponds to BHVR4 (PWM4) -> 0x40 Consequently, PWM3 should use mask 0x80 and PWM4 should use 0x40. This typo did not cause any functional bugs because these specific macros are never referenced in the driver code. Instead, the driver correctly applies the configuration by relying on the modulo parity of the channel index (e.g., `channel % 2`) to selectively apply either ADT7470_PWM1_AUTO_MASK (0x80) or ADT7470_PWM2_AUTO_MASK (0x40). Since the bit layout is identical between the two configuration registers, the hardware is currently configured correctly. Fix the macro definitions to reflect the datasheet accurately and prevent future bugs or confusion during code review and refactoring. As this is a purely cosmetic fix with no functional impact, a backport to stable kernels is not necessary. Fixes: 6f9703d0be16 ("hwmon: add support for adt7470") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-4-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit d5d4034bb6f6ee0aba4baf0daf9b81c8a3165bf0 Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:21 2026 -0300 hwmon: (adt7470) Fix temperature alarm logic in hwmon_temp_read() [ Upstream commit 1a18c79c4bc44cc5349c60e16b0b744dc6ec5f77 ] During the conversion the alarm callback started interpreting the channel index as an alarm bitmask, resulting in incorrect alarm reporting. Compute the proper alarm bit instead. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/r/20260717211224.B9E291F000E9@smtp.kernel.org Fixes: fc958a61ff6d ("hwmon: (adt7470) Convert to devm_hwmon_device_register_with_info API") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-5-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 82d65f7ef11edcea0228745440b8b4b1f222c34c Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:19 2026 -0300 hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread [ Upstream commit cb0b7f9c43b0abbd422a7e4c2c85e91db429207c ] When userspace configures 'auto_update_interval' to 0 via sysfs, the background kthread executes schedule_timeout_interruptible(0), which returns immediately. If 'num_temp_sensors' is concurrently or previously set to 0, the msleep_interruptible() delay inside adt7470_read_temperatures() also becomes 0. This combination forces the background thread into a tight, unbounded busy-loop, hogging the CPU and flooding the I2C bus with a continuous stream of transactions. Fix this vulnerability by raising the lower limit of the clamp_val in auto_update_interval_store() from 0 to 500 milliseconds. This guarantees a reasonable minimum sleep window between sensor updates, protecting the system from intentional or accidental I2C bus denial of service. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/r/20260716213252.EACA71F000E9@smtp.kernel.org Fixes: 89fac11cb3e7 ("adt7470: make automatic fan control really work") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-3-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 3e06ff0c79ea3e9ad431e1b75c020aceb325d0f1 Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:18 2026 -0300 hwmon: (adt7470) Fix cache updated before hardware write on I2C error [ Upstream commit 05270bd38d9bf88a2f4c212246a8fa29f4032078 ] adt7470_temp_write() and adt7470_pwm_write() update the driver's cached values (temp_min, temp_max, pwm_input, pwm_enable) before issuing the corresponding regmap_write(), and never check whether the write succeeded before committing that update. If the I2C transaction fails, the function correctly propagates the error to the caller, but the cache silently keeps the new value, which was never actually applied to the hardware. Subsequent reads then report a value that does not match the device state. Reorder both write paths to update the cache only after a successful regmap_write(), so the cache always reflects what was actually written to the hardware. Fixes: ef67959c4253 ("hwmon: (adt7470) Convert to use regmap") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-2-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 28548ecc2b4587969397aacc801895fd04a00682 Author: Luiz Angelo Daros de Luca Date: Mon Jul 27 21:22:17 2026 -0300 hwmon: (adt7470) Fix fans stuck in manual mode on I2C errors [ Upstream commit 625a2c02a1c04571232a746fe188b4d9a8d63edd ] During adt7470_read_temperatures(), the driver temporarily switches the PWM channels to manual mode, performs the temperature collection, and then restores the original configuration registers. However, if an I2C transaction fails at any point after entering manual mode, the function aborts and returns immediately. This leaves the configuration registers un-restored, permanently trapping the fans in manual mode. Introduce a recovery path to ensure that the original PWM configuration registers are always restored, even when intermediate I2C operations fail. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/r/20260716213252.EACA71F000E9@smtp.kernel.org Fixes: ef67959c4253 ("hwmon: (adt7470) Convert to use regmap") Signed-off-by: Luiz Angelo Daros de Luca Link: https://lore.kernel.org/r/20260727-adt7470_fixes-v2-1-598e38a46ba6@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ae20a8a4de06a289d40b0a0633d8d573f1fcb049 Author: Chenguang Zhao Date: Thu Jul 23 17:26:37 2026 +0800 forcedeth: fix UAF of txrx_stats in nv_remove [ Upstream commit 22666ba1420164753d7b0f5a841986b25ace5435 ] nv_remove() frees the per-CPU txrx_stats before unregister_netdev(). Until unregister completes, ndo_get_stats64, the NAPI/xmit data path, and nv_close()/drain may still access txrx_stats, leading to a use-after-free. Free the stats only after unregister_netdev(). Fixes: f4b633b911fd ("forcedeth: use per cpu to collect xmit/recv statistics") Signed-off-by: Chenguang Zhao Reviewed-by: Vadim Fedorenko Reviewed-by: Zhu Yanjun Link: https://patch.msgid.link/20260723092637.2135095-1-chenguang.zhao@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2e0c6761c055325772a25595caa589ae92f51e30 Author: David Corvaglia Date: Sun Jul 26 06:26:05 2026 +0000 net: bridge: mrp: fix Option TLV length in MRP_Test frames [ Upstream commit 5546da86894d5906f131b05890705a7abf949d84 ] oui is a pointer, so sizeof(oui) is the pointer size. The MRA Option TLV thus advertises a wrong length (15 vs 10 on x86_64), causing misparsing of the frame on peers. Fix is to replace with sizeof(*oui). Fixes: f7458934b079 ("net: bridge: mrp: Update the Test frames for MRA") Signed-off-by: David Corvaglia Acked-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260726062605.2746-1-david@corvaglia.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1b722740ac5c2b2070f9ba922f4e0f227faf0246 Author: Guenter Roeck Date: Mon Jul 27 13:35:37 2026 -0700 hwmon: (nct6775-core) Prevent access to unsupported weight registers [ Upstream commit d0b704e569ac3b8416d8e02270cdc9bf830ed395 ] Sashiko reports: During initialization of the nct6116 chip, the driver sets data->pwm_num to 5. However, it assigns several NCT6106 register arrays (such as NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and NCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP. These arrays only contain 3 elements. In nct6775_update_pwm(), the driver iterates up to data->pwm_num. If data->has_pwm has bits 3 or 4 set (which is structurally possible for nct6116), the loop attempts to read elements at index 3 and 4 from these 3-element arrays. This results in a global out-of-bounds read, which can be caught by KASAN. Furthermore, the driver uses these garbage out-of-bounds values as hardware register addresses for subsequent read and write operations. This leads to invalid hardware register access, potentially causing hardware misconfiguration or system crashes. The underlying problem is that the chip does support up to five fan control channels, but only the first three support weight control. Fix the problem by extending the affected weight register arrays with zeroed fields. The driver uses zeroed register addresses to determine if a register is supported or not, and skips accesses for unsupported registers. Reported-by: Sashiko Fixes: 29c7cb485b32 ("hwmon: (nct6775) Integrate new model nct6116") Cc: Björn Gerhart Cc: Florian Bezdeka Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 5ec5f00fc606a6df8434948c4552b3cb1176595d Author: Eric Dumazet Date: Fri Jul 24 07:29:01 2026 +0000 net: do not send ICMP/NDISC Redirects when peer allocation fails [ Upstream commit dbc3791e3b2472e1ccc08947e0f83b443470ff4f ] When inet_getpeer_v4() or inet_getpeer_v6() fails to allocate a peer entry under memory pressure or tree size caps, redirect handlers previously fell back to sending un-rate-limited ICMP/NDISC Redirect messages. In IPv4, ip_rt_send_redirect() called icmp_send() directly when peer == NULL. In IPv6, ip6_forward() and ndisc_send_redirect() passed a NULL peer into inet_peer_xrlim_allow(), which returned true when peer == NULL. Because ICMP/NDISC Redirects are not part of the default global rate limit mask (sysctl_icmp_ratemask), sending redirects when peer == NULL creates an un-rate-limited ICMP packet storm. Fix this by failing closed in ip_rt_send_redirect(), ip6_forward(), and ndisc_send_redirect() when peer is NULL. Fixes: 92d868292634 ("inetpeer: Move ICMP rate limiting state into inet_peer entries.") Signed-off-by: Eric Dumazet Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260724072901.1633601-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2332d35aaf206c17acf848522817252732596676 Author: Guenter Roeck Date: Mon Jul 27 09:54:23 2026 -0700 hwmon: (nzxt-smart2) DMA-align output buffer [ Upstream commit 080bbf42faf77e6489ab30d5114c5f8f6ccbb1b8 ] Sashiko reports: When send_output_report() calls hid_hw_output_report(), the underlying USB HID core calls usb_interrupt_msg() which maps this buffer directly for DMA. When the DMA mapping flushes or invalidates the cacheline, it will corrupt the adjacent variables (mutex, update_interval) that were modified concurrently by the CPU. This causes memory corruption due to cacheline sharing on non-coherent CPU architectures (such as ARM or MIPS). The DMA API debugging tool (CONFIG_DMA_API_DEBUG) will trigger runtime warnings for this violation. Any operation that triggers send_output_report() (like setting a fan speed or updating the interval) causes the USB DMA mapping. On systems with non-coherent caches, this structural bug causes immediate and deterministic memory corruption. Align the output buffer to ARCH_DMA_MINALIGN to fix the problem. Reported-by: Sashiko Fixes: 53e68c20aeb1 ("hwmon: add driver for NZXT RGB&Fan Controller/Smart Device v2.") Cc: Aleksandr Mezin Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 075fce376cf852db9293481edce07c181a9b1f46 Author: Guenter Roeck Date: Sat Jul 25 15:27:28 2026 -0700 hwmon: (lm90) Only report alarms if driver is ready [ Upstream commit aa9429edf9fc0e90d6f4da19ea4b5495a54ab117 ] Userspace can read sysfs attributes before driver registration is complete, immediately after devm_hwmon_device_register_with_info() has been called. At that time, data->hwmon_dev is not yet initialized. This can trigger a NULL pointer access since lm90_update_device() and with it lm90_update_alarms_locked() will be called. This call schedules report_work and lm90_report_alarms(), which passes the still-NULL data->hwmon_dev to hwmon_notify_event() and triggers a NULL pointer dereference. Fix the problem by only scheduling the report and alert workers data->hwmon_dev is set. Reported-by: Sashiko Fixes: f6d0775119fb9 ("hwmon: (lm90) Rework alarm/status handling") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit c498adfd4c3e85306ccdc19b76e639bfc215f0e7 Author: Guenter Roeck Date: Sat Jul 25 09:34:46 2026 -0700 hwmon: (sht3x) Fix unaligned accesses [ Upstream commit f46d5ab43a572b84773015a76966f5da56fc1748 ] Sashiko reports: In sht3x_update_client(), the 16-bit temperature and humidity values are extracted from a stack-allocated byte array using be16_to_cpup(). The pointers passed to this function are calculated as buf and buf + 3. Since the difference between the two pointers is an odd number of bytes, at least one of them is guaranteed to be at an unaligned offset. This will trigger an alignment fault on strict-alignment architectures such as ARMv5 or SPARC, resulting in a kernel panic. Fix the problem by using get_unaligned_be16() instead of be16_to_cpup(), and put_unaligned_be16() instead of cpu_to_be16(). Fixes: 7c84f7f80d6f ("hwmon: add support for Sensirion SHT3x sensors") Reported-by: Sashiko Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 08aee6d45eefc9e0b94c21bd442f47b21d64fa2c Author: Guenter Roeck Date: Wed Feb 5 12:27:15 2025 -0800 hwmon: (ltc4282) Fix reading the minimum alarm voltage [ Upstream commit 00feb1cce93dab948a299b69753d99c681d45a0b ] Coverity reports an out-of-bounds access when reading the minimum alarm voltage for the VGPIO channel. Add the missing return statement to fix the problem. Fixes: cbc29538dbf7 ("hwmon: Add driver for LTC4282") Cc: Nuno Sa Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit b60e8486c04def0712ba85a9ee058e5ed90d7633 Author: Guenter Roeck Date: Wed Jun 10 07:46:16 2026 -0700 hwmon: (ina2xx) Fix various overflow issues [ Upstream commit e6c80061ca239f45c0eaf7e47a91d6d6df9bd636 ] Sashiko reports several integer overflow problems in the ina2xx driver caused by unbounded multiplications and inadequate types for intermediate calculations. Specifically: - In ina2xx_get_value(), the return type is changed from int to long. Intermediate calculations for current are now performed using 64-bit types to prevent 32-bit integer overflow before the division by 1000. - When calculating power in ina2xx_get_value() and sy24655_average_power_read(), interim values are cast to u64 and clamped to LONG_MAX. This prevents overflow when regval or accumulator_24 is multiplied by power_lsb_uW. - In ina226_alert_to_reg(), the clamping logic is rewritten using min_t(). This safely avoids integer overflows when scaling user-provided values for shunt voltage, bus voltage, power, and current limits. Cc: Loic Poulain Fixes: ab7fbee452be ("hwmon: (ina2xx) Fix various overflow issues") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit e627f4ad9eea21786f4ac9eab039d0f91118bd67 Author: Jonas Rebmann Date: Tue Mar 3 12:07:02 2026 +0100 hwmon: (ina2xx) Shift INA234 shunt and current registers [ Upstream commit eeca1114d1e2cc0eacaebb80f3f2afbaebfc60be ] The INA219 has the lowest three bits of the bus voltage register zero-reserved, the bus_voltage_shift ina2xx_config field was introduced to accommodate for that. The INA234 has four bits of the bus voltage, of the shunt voltage, and of the current registers zero-reserved but the latter two were implemented by choosing a 16x higher shunt_div instead of a separate field specifying a bit shift. This is possible because shunt voltage and current are divided by shunt_div, hence a 16x higher shunt_div results in a 16x smaller LSB for both the shunt voltage and the current register, perfectly accounting for the missing bit shift. For consistency and correctness, account for the reserved bits via shunt_voltage_shift and current_shift configuration fields as already done for voltage registers and use the conversion constants given in the INA234 datasheet. Signed-off-by: Jonas Rebmann Link: https://lore.kernel.org/r/20260303-ina234-shift-v1-2-318c33ac4480@pengutronix.de Signed-off-by: Guenter Roeck Stable-dep-of: e6c80061ca23 ("hwmon: (ina2xx) Fix various overflow issues") Signed-off-by: Sasha Levin commit fdfde077e025c72d49ae9be064eeefb48729a829 Author: Ian Ray Date: Fri Feb 20 13:20:22 2026 +0200 hwmon: (ina2xx) Add support for INA234 [ Upstream commit 88a928eebccdc5445d874ddcbf1683b76c9f1431 ] INA234 is register compatible to INA226 (excepting manufacturer and die or device id registers) but has different scaling. Signed-off-by: Ian Ray Reviewed-by: Bence Csókás # v2 Tested-by: Jens Almer Tested-by: Jonas Rebmann Link: https://lore.kernel.org/r/20260220112024.97446-4-ian.ray@gehealthcare.com Signed-off-by: Guenter Roeck Stable-dep-of: e6c80061ca23 ("hwmon: (ina2xx) Fix various overflow issues") Signed-off-by: Sasha Levin commit 8da94361f9ae149926b23c29ebcd08c1f5592845 Author: Ian Ray Date: Fri Feb 20 13:20:21 2026 +0200 hwmon: (ina2xx) Make it easier to add more devices [ Upstream commit f6e14b5bcabf4ee97a2d535c3c2d7e72c8da4c15 ] * Make sysfs entries documentation easier to maintain. * Use multi-line enum. * Correct "has_power_average" comment. Create a new "has_update_interval" member for chips which support averaging. Signed-off-by: Ian Ray Reviewed-by: Bence Csókás # v2 Tested-by: Jens Almer Link: https://lore.kernel.org/r/20260220112024.97446-3-ian.ray@gehealthcare.com Signed-off-by: Guenter Roeck Stable-dep-of: e6c80061ca23 ("hwmon: (ina2xx) Fix various overflow issues") Signed-off-by: Sasha Levin commit a42d727dae5701deac8bb2a75effadae7d681153 Author: Guenter Roeck Date: Wed Jul 22 07:14:36 2026 -0700 hwmon: (nct6775-core) Fix number of temperature registers for NCT6116 [ Upstream commit b0e8adb2ccb43009796897ced09f91636685c9d3 ] Unlike NCT6106, NCT6116 only has three temperature registers, and with it only three temperature source and temperature source configuration registers. The register addresses match those of NCT6106 and can be re-used. The code used a separate array to list the temperature source registers for NCT6116, but used the size of the NCT6106 register array to set the number of registers. The NCT6106 register array provides six addresses, while the temperature source register array for NCT6116 only provides three addresses. This causes a KASAN report. BUG: KASAN: global-out-of-bounds in nct6775_probe+0x936/0x46f0 [nct6775] Read of size 2 at addr ffffffffc19561a6 by task modprobe/954 ... Call Trace: dump_stack+0x7d/0xa7 print_address_description.constprop.0+0x1c/0x220 ? __kasan_kmalloc.constprop.0+0xc9/0xd0 ? __kmalloc_node_track_caller+0x194/0x5b0 ? nct6775_probe+0x936/0x46f0 [nct6775] ? nct6775_probe+0x936/0x46f0 [nct6775] ... Fix the problem by hard-coding the number of temperature and temperature configuration registers to three for NCT6116. Drop the unnecessary NCT6116_REG_TEMP_SOURCE array and re-use NCT6106_REG_TEMP_SOURCE. Reported-by: Florian Bezdeka Closes: https://lore.kernel.org/linux-hwmon/57cfc3fa-d4e9-4c10-8aa7-4ad0af7ebebe@roeck-us.net/T/#t Fixes: 29c7cb485b32 ("hwmon: (nct6775) Integrate new model nct6116") Cc: Björn Gerhart Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit e28d478c003d7a44f3ffba6ca6330d03fcc3ee08 Author: Srikanth Boyapally Date: Mon Jul 20 18:25:10 2026 +0530 spi: spi-cadence: Move TX FIFO full busy-wait into FIFO [ Upstream commit d9eadfce2fac49445db40808fe4d8259f20a9d2b ] SPI host transfers could intermittently stall with spi_transfer timeouts. The TXFULL condition was checked only once in cdns_transfer_one() before cdns_spi_process_fifo(), so if the FIFO became full again during refill, writes could be dropped and the transfer would never complete. Move the TXFULL busy-wait into the TX path of cdns_spi_process_fifo() so the 10µs back-off is applied per FIFO entry during filling, ensuring forward progress and eliminating spurious timeouts. Restrict the delay to host mode using spi_controller_is_target(), the controller is passed into cdns_spi_process_fifo() so the check is made at the point of use. In target mode this delay must not run as it causes the target to miss its transfer window and corrupt data. Fixes: 49530e641178 ("spi: cadence: Add usleep_range() for cdns_spi_fill_tx_fifo()") Signed-off-by: Srikanth Boyapally Reviewed-by: Radhey Shyam Pandey Link: https://patch.msgid.link/20260720125510.60166-1-srikanth.boyapally@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d3337eefab626c52511ea640e9545b7c14e979d4 Author: Jun Guo Date: Fri Oct 31 15:30:02 2025 +0800 spi: spi-cadence: supports transmission with bits_per_word of 16 and 32 [ Upstream commit 4e00135b2dd1d7924a58bffa551b6ceb3bd836f2 ] The default FIFO data width of the Cadence SPI IP is 8 bits, but the hardware supports configurations of 16 bits and 32 bits. This patch enhances the driver to support communication with both 16-bits and 32-bits FIFO data widths. Signed-off-by: Jun Guo Link: https://patch.msgid.link/20251031073003.3289573-3-jun.guo@cixtech.com Signed-off-by: Mark Brown Stable-dep-of: d9eadfce2fac ("spi: spi-cadence: Move TX FIFO full busy-wait into FIFO") Signed-off-by: Sasha Levin commit fcc3d77fef02ceabde756bf9b93339c82f207c72 Author: wangdicheng Date: Mon Jul 20 16:16:16 2026 +0800 ASoC: tas2781: Use correct calibration data for SINEGAIN2 register [ Upstream commit dd88cf6273de61f2f7206c2066af97798dbb38b0 ] The SINEGAIN2_REG case in cali_reg_update() references t->sin_gn[] rather than t->sin_gn2[], causing the second pilot tone gain calibration to be programmed with the wrong register address. These are distinct fields in struct fct_param_address and are populated from separate firmware parameters by the parser in tas2781-fmwlib.c. Fixes: 84d6a465f211 ("ASoC: tas2781: Support dsp firmware Alpha and Beta seaies") Signed-off-by: wangdicheng Link: https://patch.msgid.link/20260720081616.631413-1-wangdich9700@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b2851429afc5b39aded7a2c14dd91a51c1bd926e Author: Dawei Feng Date: Sun Jun 28 14:59:09 2026 +0800 smb: client: fix buffer leaks in SMB1 read and write [ Upstream commit 6a3e16d60e81a4aa3056ab15617036cfbea2e07d ] CIFSSMBRead(), CIFSSMBWrite() and CIFSSMBWrite2() allocate a request buffer before checking whether tcon->ses->server is NULL. If that defensive check ever fails, the helper returns -ECONNABORTED without releasing the request buffer. Fix these leaks by releasing the allocated request buffer before returning from these error paths. Use cifs_small_buf_release() for the buffers allocated by small_smb_init() and cifs_buf_release() for the buffer allocated by smb_init(). 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. Runtime validation used a temporary fault-injection hook to force tcon->ses->server to NULL after request-buffer initialization. On the unfixed kernel, the harness observed two leaked small request buffers and one leaked large request buffer, with directed kmemleak dumps confirming the CIFS buffer allocation stacks. After the fix, no CIFS request-buffer deltas remained. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Dawei Feng Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 9e24b47ef81d43b3fb1b14294f09991640c79fcc Author: Xingui Yang Date: Thu Jul 16 16:11:45 2026 +0800 scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race [ Upstream commit 3dbbbf656b850c9c8de05df6ad4a1dfc6ff02845 ] Commit fbefe22811c3 ("scsi: libsas: Don't always drain event workqueue for HA resume") introduced sas_resume_ha_no_sync() to avoid a deadlock: the PHYE_RESUME_TIMEOUT handler, running on the HA event workqueue, calls sas_deform_port() -> sas_destruct_devices(), which removes SCSI devices and waits for the host to become runtime-active. But the host cannot resume until sas_resume_ha() -> sas_drain_work() returns, and the drain is blocked on that very handler. However skipping the drain reintroduces a race: hisi_sas returns from resume before all PHY UP work and libsas discovery work finish. The controller may then autosuspend while disks are still waking up. The disks issue IO to a suspended controller, the IO fails, and the disks get disabled. Fix the deadlock at its source by moving the PHYE_RESUME_TIMEOUT notification to after sas_drain_work(). By then the host resume is about to complete, so device removal through device_link no longer blocks on the resume and the cycle is broken. With the deadlock gone, restore sas_resume_ha() (the draining variant) in hisi_sas and remove sas_resume_ha_no_sync(). The reorder is safe for the other libsas consumers (isci, pm8001, aic94xx, mvsas). During suspend, sas_suspend_devices() calls sas_notify_lldd_dev_gone() for each device, which sets dev->lldd_dev to NULL. When scsi_unblock_requests re-enables I/O in resume, any I/O to a timed-out phy's disk is immediately rejected by the LLDD before reaching hardware: isci returns SAS_DEVICE_UNKNOWN (mapped to DID_BAD_TARGET), and pm8001 returns SAS_PHY_DOWN (mapped to DID_NO_CONNECT). Both complete directly via scsi_done() without entering SCSI EH. This is identical in both the old and new ordering since lldd_dev_gone runs during suspend, before resume. The reorder only affects when the PHYE_RESUME_TIMEOUT handler runs (synchronized by sas_drain_work() vs. asynchronous after resume returns), not whether I/O can reach the device. aic94xx and mvsas do not register any PM ops and never reach this code path. Fixes: fbefe22811c3 ("scsi: libsas: Don't always drain event workqueue for HA resume") Signed-off-by: Xingui Yang Reviewed-by: John Garry Link: https://patch.msgid.link/20260716081145.3950172-1-yangxingui@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 72815741715bd41556dac5eeb068bf0f8af06ee7 Author: HyeongJun An Date: Thu Jul 16 15:58:48 2026 +0900 scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer [ Upstream commit c1dea15f819cded9b3faf58f8bec72323568b6e6 ] iscsi_tcp_hdr_dissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP, REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer. The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its data segment (sense/response data) into conn->data via iscsi_tcp_data_recv_prep(), but it does so without the same check. The only upstream bound on in.datalen is conn->max_recv_dlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and max_recv_dlength therefore overflows the 8192-byte conn->data buffer. Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check. Fixes: a081c13e39b5 ("[SCSI] iscsi_tcp: split module into lib and lld") Suggested-by: Chris Leech Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Acked-by: Chris Leech Link: https://patch.msgid.link/20260716065848.1653431-1-sammiee5311@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3ef209ca0b4b68c75e9a814d90cc916026b5a6ac Author: HyeongJun An Date: Tue Jul 14 19:49:34 2026 +0900 scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer [ Upstream commit 98b87885de4b7f605533a2860685f5689fce8e82 ] iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the target-supplied data segment. The segment carries a 2-byte sense length followed by the sense bytes, so it must hold 2 + senselen bytes, but the bounds check only requires datalen >= senselen: senselen = get_unaligned_be16(data); if (datalen < senselen) goto invalid_datalen; memcpy(sc->sense_buffer, data + 2, min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE)); A target that returns a SCSI Response whose datalen equals senselen (with senselen <= SCSI_SENSE_BUFFERSIZE) makes the memcpy() from data + 2 read up to two bytes past the received data. Those bytes are stale conn->data contents and end up in the command's sense buffer, which is returned to userspace. Account for the 2-byte sense length prefix in the check. Fixes: 7996a778ff8c ("[SCSI] iscsi: add libiscsi") Suggested-by: Sashiko AI Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An Acked-by: Chris Leech Link: https://patch.msgid.link/20260714104934.1404423-1-sammiee5311@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8e0996418590ba614b5d7a473bdd17cf9bcf45ef Author: Mario Limonciello Date: Mon Jul 20 11:28:44 2026 -0500 pinctrl-amd: Don't clear S4 wake bits at probe [ Upstream commit ffe8a0c6b55285ceaf2f42fc20c3a0594d14f1e9 ] commit 6bc3462a0f5e ("pinctrl: amd: Mask wake bits on probe again") introduced a regression where Wake-on-LAN no longer works after suspend or shutdown on some AMD platforms. Firmware-programmed S4 wake bits for devices like PCIe NICs using PCI PME are cleared at probe, but nothing restores them. Unlike S0i3/S3 wake sources that use enable_irq_wake() -> amd_gpio_irq_set_wake(), PCIe PME does not use GPIO IRQ infrastructure and relies on firmware configuration. The original intent of commit 6bc3462a0f5e ("pinctrl: amd: Mask wake bits on probe again") was to clear spurious wake bits left by firmware to prevent unwanted wakeups. However, S4 wake bits are used for hardware-level wake sources like WoL that bypass the kernel's IRQ wake API. Fix by preserving S4 wake bits at probe and only clearing S0i3/S3 bits: - Firmware-configured S4 wake sources (WoL) continue working - Kernel maintains control of S3/S0i3 wake policy via set_wake() - S3-only wake sources work correctly per commit f31f33dbb3ba ("pinctrl: amd: Take suspend type into consideration which pins are non-wake") The trade-off is that firmware-programmed spurious S4 wake bits remain set, but this is less problematic than breaking WoL. Fixes: 6bc3462a0f5e ("pinctrl: amd: Mask wake bits on probe again") Signed-off-by: Mario Limonciello Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit ceb00cb87a22c42d20c39336213db2b843ca9e34 Author: Jason Xing Date: Sun Jul 19 15:56:05 2026 +0200 xsk: drain continuation descs after overflow in xsk_build_skb() [ Upstream commit bd44a6dcd4248883de90f5dad53ae80066e27096 ] Fix generic xmit path multi-buffer logic when packets are either too big (count of descriptors exceed MAX_SKB_FRAGS) or an invalid descriptor is included in fragmented packet. Introduce xdp_sock::drain_cont and act upon this flag - when it is set, keep on consuming descriptors from AF_XDP Tx ring and put them directly onto Cq. Previously these descriptors were silently lost and could never be reached again. Fixes: cf24f5a5feea ("xsk: add support for AF_XDP multi-buffer on Tx path") Closes: https://lore.kernel.org/all/20260425041726.85FB3C2BCB2@smtp.kernel.org/ Reviewed-by: Jason Xing Co-developed-by: Maciej Fijalkowski # wrapped cq addr submission onto routine Signed-off-by: Maciej Fijalkowski Signed-off-by: Jason Xing Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20260719135609.147823-3-maciej.fijalkowski@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 411554cb868b879268e377c96bab3802d63e0b97 Author: Jason Xing Date: Thu Oct 30 08:06:46 2025 +0800 xsk: use a smaller new lock for shared pool case [ Upstream commit 30ed05adca4a05c50594384cff18910858dd1d35 ] - Split cq_lock into two smaller locks: cq_prod_lock and cq_cached_prod_lock - Avoid disabling/enabling interrupts in the hot xmit path In either xsk_cq_cancel_locked() or xsk_cq_reserve_locked() function, the race condition is only between multiple xsks sharing the same pool. They are all in the process context rather than interrupt context, so now the small lock named cq_cached_prod_lock can be used without handling interrupts. While cq_cached_prod_lock ensures the exclusive modification of @cached_prod, cq_prod_lock in xsk_cq_submit_addr_locked() only cares about @producer and corresponding @desc. Both of them don't necessarily be consistent with @cached_prod protected by cq_cached_prod_lock. That's the reason why the previous big lock can be split into two smaller ones. Please note that SPSC rule is all about the global state of producer and consumer that can affect both layers instead of local or cached ones. Frequently disabling and enabling interrupt are very time consuming in some cases, especially in a per-descriptor granularity, which now can be avoided after this optimization, even when the pool is shared by multiple xsks. With this patch, the performance number[1] could go from 1,872,565 pps to 1,961,009 pps. It's a minor rise of around 5%. [1]: taskset -c 1 ./xdpsock -i enp2s0f1 -q 0 -t -S -s 64 Signed-off-by: Jason Xing Acked-by: Maciej Fijalkowski Link: https://patch.msgid.link/20251030000646.18859-3-kerneljasonxing@gmail.com Signed-off-by: Paolo Abeni Stable-dep-of: bd44a6dcd424 ("xsk: drain continuation descs after overflow in xsk_build_skb()") Signed-off-by: Sasha Levin commit 05e283466b86e0b25a5209a3eafe87aa9886064a Author: Jason Xing Date: Sun Jul 19 15:56:04 2026 +0200 xsk: fix buffer leak in xsk_drop_skb() for AF_XDP multi-buffer Tx [ Upstream commit a3c8382ebce4780c6b3ace2c09bc342313ac0186 ] This patch is inspired by the check[1] from sashiko. It says when overflow happens, the address of cq to be published is invalid. Actually the severer thing is the whole process of publishing the address of cq in this particular case is not right: it should truely publish the address and advance the cached_prod in cq as long as it reads descriptors from txq. The following is the full analysis. xsk_drop_skb() is called in three places, which all discard a partially built multi-buffer skb: 1) xsk_build_skb() -EOVERFLOW error path: packet exceeds MAX_SKB_FRAGS 2) __xsk_generic_xmit() post-loop cleanup: an invalid descriptor in the TX ring prevents the partial packet from completing 3) xsk_release(): socket close while xs->skb holds an incomplete packet In all three cases, the TX descriptors for the already-processed frags have been consumed from the TX ring (xskq_cons_release), and CQ slots have been reserved. However, xsk_drop_skb() calls xsk_consume_skb() which cancels the CQ reservations via xsk_cq_cancel_locked(). Since the buffer addresses never appear in the completion queue, userspace permanently loses track of these buffers. Fix this by letting consume_skb() trigger the existing xsk_destruct_skb destructor, which already submits buffer addresses to the CQ via xsk_cq_submit_addr_locked(). Note that cancelling the descriptors back to the TX ring (via xskq_cons_cancel_n) is not a appropriate option because an oversized packet that always exceeds MAX_SKB_FRAGS would be retried indefinitely, which is an obviously deadlock bug in the TX path. Also move the desc->addr assignment in xsk_build_skb() above the overflow check so that the current descriptor's address is recorded before a potential -EOVERFLOW jump to free_err, consistent with the zerocopy path in xsk_build_skb_zerocopy(). [1]: https://lore.kernel.org/all/20260425041726.85FB3C2BCB2@smtp.kernel.org/ Fixes: cf24f5a5feea ("xsk: add support for AF_XDP multi-buffer on Tx path") Acked-by: Maciej Fijalkowski Signed-off-by: Jason Xing Acked-by: Stanislav Fomichev Link: https://patch.msgid.link/20260719135609.147823-2-maciej.fijalkowski@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 814c5b1590037330381a4ae83aaf40c0986ba2bb Author: John Ericson Date: Sat Jul 18 14:29:02 2026 -0400 selftests/net/af_unix: test listen() rejects wrong socket states [ Upstream commit 7f57c650d08b8793bb551bdb33ad876535ef9fe8 ] Add a regression test for the unix_listen() state check. The key case is listen() on a bound socket that has already been connected: it is no longer in TCP_CLOSE or TCP_LISTEN, so it must fail with EINVAL. A prepare_peercred() call slipped in ahead of that check once left err at 0 and made listen() silently succeed there instead; this guards against a repeat. The neighbouring outcomes are covered too so they cannot regress the same way: a bound socket in TCP_CLOSE listens fine, calling listen() again on a socket already in TCP_LISTEN is allowed, and an unbound socket fails with EINVAL. Each case runs for both listenable socket types (SOCK_STREAM and SOCK_SEQPACKET) and both pathname and abstract addresses. Fixes: fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid") Signed-off-by: John Ericson Link: https://patch.msgid.link/20260718182903.2295560-2-John.Ericson@Obsidian.Systems Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 643ec3e24a490e3f07cc1b96282830e38155a0a8 Author: Kuniyuki Iwashima Date: Mon Nov 24 21:26:39 2025 +0000 selftest: af_unix: Create its own .gitignore. [ Upstream commit adb6b68c50604f3113d62758e839cc0186b94ce8 ] Somehow AF_UNIX tests have reused ../.gitignore, but now NIPA warns about it. Let's create .gitignore under af_unix/. Signed-off-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20251124212805.486235-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 7f57c650d08b ("selftests/net/af_unix: test listen() rejects wrong socket states") Signed-off-by: Sasha Levin commit 0372a52191127c38a84909babb5e9b397b451975 Author: Sunday Adelodun Date: Thu Nov 13 12:28:02 2025 +0100 selftests: af_unix: Add tests for ECONNRESET and EOF semantics [ Upstream commit 45a1cd8346ca245a1ca475b26eb6ceb9d8b7c6f0 ] Add selftests to verify and document Linux’s intended behaviour for UNIX domain sockets (SOCK_STREAM and SOCK_DGRAM) when a peer closes. The tests verify that: 1. SOCK_STREAM returns EOF when the peer closes normally. 2. SOCK_STREAM returns ECONNRESET if the peer closes with unread data. 3. SOCK_SEQPACKET returns EOF when the peer closes normally. 4. SOCK_SEQPACKET returns ECONNRESET if the peer closes with unread data. 5. SOCK_DGRAM does not return ECONNRESET when the peer closes. This follows up on review feedback suggesting a selftest to clarify Linux’s semantics. Suggested-by: Kuniyuki Iwashima Signed-off-by: Sunday Adelodun Link: https://patch.msgid.link/20251113112802.44657-1-adelodunolaoluwa@yahoo.com Signed-off-by: Paolo Abeni Stable-dep-of: 7f57c650d08b ("selftests/net/af_unix: test listen() rejects wrong socket states") Signed-off-by: Sasha Levin commit 5c170577049f9f3db07a6733b956069fb2cd5b53 Author: John Ericson Date: Sat Jul 18 14:29:01 2026 -0400 af_unix: fix listen() succeeding on sockets in the wrong state [ Upstream commit f0d9c3ffc2b5fc2ffacb56b3036155ce7a940a12 ] Commit fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid") inserted a prepare_peercred() call between err = -EINVAL and the socket-state check in unix_listen(). Since prepare_peercred() leaves err at 0 on success, listen() on an AF_UNIX socket that is not in TCP_CLOSE or TCP_LISTEN state (e.g. one that is already connected) now silently returns success without doing anything, instead of failing with EINVAL as it did before. Fixes: fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid") Signed-off-by: John Ericson Link: https://patch.msgid.link/20260718182903.2295560-1-John.Ericson@Obsidian.Systems Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b1d480fce05f857dc438080cd8c9244b84a83494 Author: Xiang Mei Date: Wed Jul 22 14:02:03 2026 -0700 rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check() [ Upstream commit 78f75d632f74b8de0f081a128588f7c37d0d1164 ] rds_tcp_laddr_check() looks up a scoped IPv6 interface with dev_get_by_index_rcu(), drops the RCU read-side lock, and only then passes the bare struct net_device * into ipv6_chk_addr(). dev_get_by_index_rcu() only keeps the device alive within the same RCU read-side section. After rcu_read_unlock(), a concurrent RTM_DELLINK can free the net_device; ipv6_chk_addr() then dereferences the stale pointer in __ipv6_chk_addr_and_flags() (e.g. l3mdev_master_dev_rcu(dev)), reading freed memory. Keep the RCU read-side lock held across the ipv6_chk_addr() call instead of dropping it right after the lookup, so the device cannot be freed while it is in use. BUG: KASAN: slab-use-after-free in __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) Read of size 8 at addr ffff8880106ec000 by task exploit/153 Call Trace: ... kasan_report (mm/kasan/report.c:595) __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) ipv6_chk_addr (net/ipv6/addrconf.c:2031 net/ipv6/addrconf.c:1972) rds_tcp_laddr_check (net/rds/tcp.c:370) rds_bind (net/rds/bind.c:248) __sys_bind (net/socket.c:1920) __x64_sys_bind (net/socket.c:1956) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Fixes: eee2fa6ab322 ("rds: Changing IP address internal representation to struct in6_addr") Reported-by: Weiming Shi Signed-off-by: Xiang Mei Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20260722210203.565803-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f6787fdffcae5490c779f0f3f33b11597525d1ae Author: Ilia Gavrilov Date: Thu Jul 9 16:27:54 2026 +0000 rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled [ Upstream commit 9c805e592a29be9e4e61ff1bd567da04aa8fd6f9 ] When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: eee2fa6ab322 ("rds: Changing IP address internal representation to struct in6_addr") Fixes: 1e2b44e78eea ("rds: Enable RDS IPv6 support") Signed-off-by: Ilia Gavrilov Reviewed-by: Allison Henderson Link: https://patch.msgid.link/20260709162723.367523-1-Ilia.Gavrilov@infotecs.ru Signed-off-by: Jakub Kicinski Stable-dep-of: 78f75d632f74 ("rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check()") Signed-off-by: Sasha Levin commit 4147866087fbef2ea602e274c046c79d469fa478 Author: Charles Keepax Date: Wed Jul 22 11:35:00 2026 +0100 ASoC: SDCA: Ensure that Control Range is large enough for header [ Upstream commit 951e921b039b793bef7050eaf5c5fb1a4a5341d1 ] When reading the Ranges structure from an SDCA Control, ensure that the read data is large enough to encompass the required header before accessing it. Fixes: 64fb5af1d1bb ("ASoC: SDCA: Add parsing for Control range structures") Signed-off-by: Charles Keepax Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20260722103500.872714-5-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 16b553c46e347bc9de9946c4960654d5884a86de Author: Xiang Mei (Microsoft) Date: Sun Jul 19 22:15:23 2026 +0000 netfilter: nft_payload: fix mask build for partial field offload [ Upstream commit 39e88f28fb32bf02bd4b525c24c842c9cff5663d ] nft_payload_offload_mask() builds the offload match mask for a payload expression that covers only part of a header field. For a partial IPv6 address match (field_len = 16, priv_len = 1) that shift is 1 << 120, which is undefined on the 32-bit int operand. It also trims only one word, so the remaining words stay 0xffffffff (and when priv_len is a multiple of 4 the trim is skipped entirely), leaving the mask covering more bytes than the rule matches. UBSAN: shift-out-of-bounds in net/netfilter/nft_payload.c:278:20 shift exponent 120 is too large for 32-bit type 'int' ... The match is byte-granular and struct nft_data is zero-initialised, so the correct mask is simply the first priv_len bytes set to 0xff. Set those bytes directly and drop the word/shift trimming; this removes the undefined shift and no longer over-masks the trailing bytes. Fixes: a5d45bc0dc50 ("netfilter: nftables_offload: build mask based from the matching bytes") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e6f4b4b40db87ef35bf141ad2fb8815b8b746508 Author: Julian Anastasov Date: Wed Jul 22 13:15:17 2026 +0300 ipvs: do not mangle ICMP replies for non-first fragments [ Upstream commit 342e24a339b90e8e339a0f8c151ca479b8565661 ] Sashiko warns that ip_vs_nat_icmp() unconditionally mangles the payload for embedded non-first IPv4 fragments. The problem is in the very old inverted pp->dont_defrag check which should not continue when embedded is a non-first TCP/UDP/SCTP fragment. Check for embedded non-first fragment is also missing from ip_vs_out_icmp_v6(), it is needed before any connection lookups that expect ports after the network headers. Drop the blocking code from ip_vs_in_icmp_v6() which prevents ICMPv6 from local clients to use non-MASQ forwarding. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://sashiko.dev/#/patchset/20260720201122.79882-1-ja%40ssi.bg Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ce96c40a049be2c539b8bfabb43b33d1775a549e Author: Julian Anastasov Date: Wed Jul 22 13:15:16 2026 +0300 ipvs: fix places with wrong packet offsets [ Upstream commit 15cab31a3730e05f0767b922a7450e5d784b2607 ] The offsets we use to packet headers and payloads should be based on skb->data. We even already respect non-zero network offset in ip_vs_fill_iph_skb() but some places do it wrongly and support only zero offset which is expected for the IP layer where IPVS has hooks. Change all places that instead of skb->data use offsets based on the network header (skb_network_header, ip_hdr, etc) because this doubles the network offset as noted by Sashiko. For ip_vs_nat_icmp_v6() we can even rely on the IPv6 header parsing done by the caller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://sashiko.dev/#/patchset/20260710143733.29741-2-fw%40strlen.de Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 00eb23829fd08df1b5e057cb6b625996a70e7e65 Author: Julian Anastasov Date: Wed Jul 22 13:15:15 2026 +0300 ipvs: fix the checksum validations [ Upstream commit e876b75b9020a97bbdc79721e7fc749024891c65 ] ip_vs_in_icmp_v6() is missing checksum validation for ICMPv6 packets from clients. In fact, as for TCP/UDP we should validate the checksum for ICMP packets only when we mangle the packets on MASQ or on reply for tunnel. Also, Sashiko points out that handle_response_icmp() being common for IPv4 and IPv6 is missing the pseudo-header calculation while validating ICMPv6 messages from real servers which is a problem if checksum is not validated by the hardware. Fix the problems by creating ip_vs_checksum_common_check() helper and use it for TCP/UDP/ICMP both for IPv4 and IPv6. Rely on the nf_checksum() for validating the ICMP messages but use it also for TCP and UDP. Use correct IP offset for IP_VS_DBG_RL_PKT for TCP/UDP/SCTP. IPVS packets (TCP/UDP/SCTP/ICMP) do not need checksum validation on LOCAL_OUT (local clients or local real servers) and on FORWARD (traffic from servers on LAN). Do it only on LOCAL_IN, in case nf_checksum() is not called on PRE_ROUTING. Also, ip_vs_checksum_complete() can be marked static. Fixes: 2a3b791e6e11 ("IPVS: Add/adjust Netfilter hook functions and helpers for v6") Link: https://sashiko.dev/#/patchset/20260708180315.77413-1-ja%40ssi.bg Signed-off-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit d186f77d18bdfb252d401ff992ca3001a6a65a0f Author: Pablo Neira Ayuso Date: Tue Jul 21 22:02:46 2026 +0200 netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH [ Upstream commit 305b63e1402267459fdabb183af4527f6799eebf ] The XT_HASHLIMIT_RATE_MATCH flag mode changes the semantics of the dsthash_ent structure which represents an entry in the hashtable. There is a union area which uses a different layout to express the rate match mode. Update .checkentry path to validate the XT_HASHLIMIT_RATE_MATCH mode flag is requested by two or more different rules that refer to the same hashtable. Otherwise, uninitialized access to the burst field in the union is possible. Reject the use of the XT_HASHLIMIT_RATE_MATCH mode flag if set on by revision less than 3 too. Fixes: bea74641e378 ("netfilter: xt_hashlimit: add rate match mode") Reported-and-tested-by: Talha Berk Arslan Link: https://patch.msgid.link/20260721074629.668-1-talha.anything.info@gmail.com/ Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 63ba12b664a2cd3220ed43e22c717715f4cc2ae8 Author: Pablo Neira Ayuso Date: Thu Jul 16 10:13:37 2026 +0200 netfilter: nf_tables: make nft_object rhltable per table [ Upstream commit f4f699790590bd0896c48a71e9232a65198f92f0 ] The nft_object rhltable is global, this allows for accessing objects that are being dismangled from lookup path by other existing netns. Given the nft_obj_destroy() releases the object inmediately, this might lead to use-after-free of these objects that are being released. Make the existing rhltable per table to address this issue to deal with with the nft_rcv_nl_event() path too. Update nft_obj_lookup() to take the table as non-const, otherwise, compiler complains when passing the objname_ht to rhltable_lookup(). Fixes: 4d44175aa5bb ("netfilter: nf_tables: handle nft_object lookups via rhltable") Suggested-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit adf1a3ba27ad1ea57f1fd31e07f00f76bc464b2d Author: Michael Bommarito Date: Sun Jul 19 12:15:05 2026 -0400 assoc_array: trim the final shortcut word using the current chunk end [ Upstream commit a82c8a05e86f3f84e09698f65b4515b5d04633f6 ] assoc_array_walk() masks off the bits past shortcut->skip_to_level in the word that contains skip_to_level, gated on round_up(sc_level, ASSOC_ARRAY_KEY_CHUNK_SIZE) > skip_to_level. That guard is wrong in two opposite ways: - When sc_level is word-aligned (every word after the first) round_up() is a no-op, so the guard is sc_level > skip_to_level and never fires for the word that holds skip_to_level. A shortcut that spans more than one word and ends in the middle of its last word leaves that word untrimmed, and its stale high bits leak into the dissimilarity word and can steer the walk down the wrong descendant. - When sc_level is unaligned (the first word) and skip_to_level sits on the next chunk boundary, sc_level + CHUNK would exceed skip_to_level and fire the trim with shift = skip_to_level & CHUNK_MASK == 0, which clears the whole dissimilarity word and makes a differing shortcut compare equal. Use the end of the chunk that contains sc_level instead: skip_to_level < round_down(sc_level, CHUNK) + CHUNK For an aligned sc_level whose word holds skip_to_level this now fires (the first bug); for an unaligned sc_level with skip_to_level on the following boundary it does not, so shift is never 0 when the branch runs and the trim never clears the whole word. Fixes: 3cb989501c26 ("Add a generic associative array implementation.") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260719161505.2423935-4-michael.bommarito@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 3d9f16c0b643ceac305526b2e2fe25c2c6166926 Author: Michael Bommarito Date: Sun Jul 19 12:15:04 2026 -0400 keys: make keyring key-chunk byte order agree with keyring_diff_objects() [ Upstream commit 58565eef0f8d861aae92abfb7658458d661cee17 ] keyring_get_key_chunk() loads description bytes into the index chunk low address first, while keyring_diff_objects() numbers the first differing bit from the low end and folds the absolute byte index into the level without removing the inline-prefix offset the level already carries. The two disagree on byte order and bit position, so the array can be told two keys first differ at a bit that does not differ in the chunk the walker uses, letting crafted descriptions collide into one node. Load the chunk in the order keyring_diff_objects() assumes and drop the inline-prefix length when folding the byte index into the level. This only changes the in-memory ordering used to place keys within a keyring; add, search and read of non-colliding keys are unaffected. Fixes: f771fde82051 ("keys: Simplify key description management") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260719161505.2423935-3-michael.bommarito@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit e9417d21a22ad2ec398e78fcf084b717ce92cf2f Author: Michael Bommarito Date: Sun Jul 19 12:15:03 2026 -0400 keys: fix out-of-bounds read in keyring_get_key_chunk() [ Upstream commit 63918731f9ae25b5deb022f118e941e6dddfcef4 ] For description-level chunks keyring_get_key_chunk() advances the read pointer by level * sizeof(long) past the inline prefix but only bounds-checks the prefix, so a long enough key description is read past its kmemdup(desc, desc_len + 1) allocation. Compute the full byte offset and bounds-check the description against it before reading. The walk only reaches a description-level chunk when two keys collide through the hash, x, type and domain_tag chunks, so this is reached from an unprivileged add_key(2) with a crafted pair of same-type keys whose index hashes collide; KASAN reports a slab-out-of-bounds read. Fixes: f771fde82051 ("keys: Simplify key description management") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260719161505.2423935-2-michael.bommarito@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 6469ad3005087127f1b55cb7e72cc577fb07fc87 Author: Fabrice Derepas Date: Wed Jul 22 19:22:30 2026 +0300 KEYS: trusted: dcp: fix key_len validation and calc_blob_len() return type [ Upstream commit 35d661c98fe4733490f20b4311616a3c2c30abc0 ] Two correctness and type-hygiene issues exist in the DCP trusted keys implementation. First, trusted_dcp_unseal() reads p->key_len from a user-supplied blob without checking if it exceeds MAX_KEY_SIZE. If a crafted blob provides a payload_len larger than 128, the subsequent do_aead_crypto() call writes past the end of the p->key array into the adjacent p->blob buffer within the same struct trusted_key_payload -- the caller's own input, not unrelated kernel memory. While not exploitable, this violates strict array bounds and triggers static analyzers. Fix this by adding a validation check against MIN_KEY_SIZE and MAX_KEY_SIZE immediately after reading the length, matching the checks already done in trusted_core.c. Second, calc_blob_len() calculates a sum in size_t that truncates to unsigned int on 64-bit platforms. Because the DCP hardware is only present on 32-bit i.MX SoC platforms, size_t and unsigned int are functionally equivalent in production, making this truncation harmless in practice. Nevertheless, updating the return type to size_t (and subsequently updating 'blen' in the seal/unseal paths) resolves type-narrowing warnings and improves overall code hygiene. Fixes: 2e8a0f40a39c ("KEYS: trusted: Introduce NXP DCP-backed trusted keys") Signed-off-by: Fabrice Derepas Reviewed-by: David Gstir Reviewed-by: Richard Weinberger Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260719163939.3624767-1-fabrice.derepas@canonical.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 31d491f9da948a4831b50acebfdac609eb1d99c6 Author: Alexandru Elisei Date: Wed Jul 22 10:03:54 2026 +0100 KVM: arm64: Reject guest_memfd memslots when the VM has MTE [ Upstream commit 679d7201c1f09e37fa1c12ce28d84079c17fc87f ] The user cannot use MTE on VMAs created by mapping a guest_memfd file, as arch_calc_vm_flag_bits() does not set VM_MTE_ALLOWED. When creating a guest_memfd backed memslot, kvm_arch_prepare_memory_region() rejects the memslot if MTE is enabled for the VM and if guest_memfd has been mapped in a VMA that intersects the memslot. However, the documentation for KVM_SET_USER_MEMORY_REGION2 explicitly states that the only condition for userspace_addr is for it to be a legal userspace address, but the mapping is not required to be valid nor populated at memslot creation. If userspace sets userspace_addr to an address that hasn't been mapped, or if userspace_addr belongs to a VMA that isn't backed by the guest_memfd file, or if the VMA doesn't intersect the memslot, memslot creation is successful and KVM ends up with a VM with MTE and guest_memfd-backed memslots. The same happens if the order is reversed: when userspace enables MTE, KVM does not check if memslots backed by guest_memfd are already present. Fix both issues by rejecting guest_memfd-backed memslots when MTE is enabled, and by rejecting MTE when guest_memfd-backed memslots are already present. Fixes: 32e200bd6e44 ("KVM: arm64: Enable support for guest_memfd backed memory") Tested-by: Fuad Tabba Reviewed-by: Fuad Tabba Signed-off-by: Alexandru Elisei Link: https://patch.msgid.link/20260722090354.94245-1-alexandru.elisei@arm.com Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit db1c4a8e9080f7f246673bde64bfa42bb508f3f0 Author: Stanislav Kinsburskii Date: Thu May 7 15:43:59 2026 +0000 mshv: Fix sleeping under spinlock in mshv_portid_alloc [ Upstream commit a9708e550d11a53b22d932cdbfaa10c26346a2d0 ] idr_alloc() is called with GFP_KERNEL inside idr_lock(), which holds a spinlock. GFP_KERNEL allows the allocator to sleep, triggering a sleeping-while-atomic bug. Fix by using idr_preload(GFP_KERNEL) before taking the lock to pre-allocate memory in a sleepable context, then idr_alloc() with GFP_NOWAIT inside the spinlock-protected section. Fixes: 621191d709b1 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs") Signed-off-by: Stanislav Kinsburskii Reviewed-by: Anirudh Rayabharam (Microsoft) Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit a920ead0bc2f13b8493ef95273ee97c3cac33abc Author: Stanislav Kinsburskii Date: Thu May 7 15:43:49 2026 +0000 mshv: Fix duplicate GSI detection for GSI 0 [ Upstream commit 649dd135491945afa544351e3e6d4a727de87020 ] The duplicate routing entry check in mshv_update_routing_table() uses guest_irq_num != 0 to detect whether a GSI slot is already occupied. This fails for GSI 0 because its guest_irq_num is 0 both when the slot is unused (zero-initialized) and when legitimately assigned. As a result, duplicate entries for GSI 0 are silently accepted, with the second entry overwriting the first — corrupting the routing table without any error reported to userspace. While GSI 0 (legacy timer) is unlikely to appear in MSI-based routing in practice, the check is semantically wrong — it conflates "uninitialized" with "GSI number 0." Use girq_entry_valid instead, which is explicitly set to true when an entry is populated and remains zero for unused slots regardless of the GSI number. Fixes: 621191d709b14 ("Drivers: hv: Introduce mshv_root module to expose /dev/mshv to VMMs") Signed-off-by: Stanislav Kinsburskii Reviewed-by: Anirudh Rayabharam (Microsoft) Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit b215cb70e14c7911a30e47742863fb5159e63e4b Author: Sebastian Andrzej Siewior Date: Tue Jul 21 17:32:15 2026 +0200 Drivers: hv: vmbus: Replace lockdep_hardirq_threaded() with lockdep annotation [ Upstream commit 8c7ab779c8850f4dab8473463cca9a7d52fdaecc ] lockdep_hardirq_threaded() is supposed to be used within IRQ core code and not within drivers. It is not obvious from within the driver, that this is the only interrupt service routing and that it is not shared handler. Replace lockdep_hardirq_threaded() with a lockdep annotation limiting threaded context on PREEMPT_RT to __vmbus_isr(). Fixes: f8e6343b7a89c ("Drivers: hv: vmbus: Use kthread for vmbus interrupts on PREEMPT_RT") Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit d397787dbc4bf0c961dfcd0def0c15f70b6d9b41 Author: Roman Kisel Date: Wed Oct 8 16:34:09 2025 -0700 Drivers: hv: Allocate the paravisor SynIC pages when required [ Upstream commit 226494e5ee4eb0bae4fc7b525505828271d5047e ] Confidential VMBus requires interacting with two SynICs -- one provided by the host hypervisor, and one provided by the paravisor. Each SynIC requires its own message and event pages. Refactor and extend the existing code to add allocating and freeing the message and event pages for the paravisor SynIC when it is present. Signed-off-by: Roman Kisel Reviewed-by: Tianyu Lan Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Stable-dep-of: 8c7ab779c885 ("Drivers: hv: vmbus: Replace lockdep_hardirq_threaded() with lockdep annotation") Signed-off-by: Sasha Levin commit 74d20e3cf88e48988c2c8cc47cbaee8ff7ec0594 Author: Roman Kisel Date: Wed Oct 8 16:34:08 2025 -0700 Drivers: hv: Rename fields for SynIC message and event pages [ Upstream commit 163224c189e8b679ce919aa64ccabb7a992ca2d1 ] Confidential VMBus requires interacting with two SynICs -- one provided by the host hypervisor, and one provided by the paravisor. Each SynIC requires its own message and event pages. Rename the existing host-accessible SynIC message and event pages with the "hyp_" prefix to clearly distinguish them from the paravisor ones. The field name is also changed in mshv_root.* for consistency. No functional changes. Signed-off-by: Roman Kisel Reviewed-by: Tianyu Lan Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Stable-dep-of: 8c7ab779c885 ("Drivers: hv: vmbus: Replace lockdep_hardirq_threaded() with lockdep annotation") Signed-off-by: Sasha Levin commit 82cdbb6155a2c49357c859b1baca1393bf4c8701 Author: Roman Kisel Date: Wed Oct 8 16:34:05 2025 -0700 arch/x86: mshyperv: Discover Confidential VMBus availability [ Upstream commit 7c8b6c326d830ca5c6b95f390c703966e14167e6 ] Confidential VMBus requires enabling paravisor SynIC, and the x86_64 guest has to inspect the Virtualization Stack (VS) CPUID leaf to see if Confidential VMBus is available. If it is, the guest shall enable the paravisor SynIC. Read the relevant data from the VS CPUID leaf. Refactor the code to avoid repeating CPUID and add flags to the struct ms_hyperv_info. For ARM64, the flag for Confidential VMBus is not set which provides the desired behaviour for now as it is not available on ARM64 just yet. Once ARM64 CCA guests are supported, this flag will be set unconditionally when running such a guest. Signed-off-by: Roman Kisel Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Stable-dep-of: 8c7ab779c885 ("Drivers: hv: vmbus: Replace lockdep_hardirq_threaded() with lockdep annotation") Signed-off-by: Sasha Levin commit 6e70eba930a24510e540e99a7326887bbebae668 Author: Ruoyu Wang Date: Tue Jul 7 23:05:28 2026 +0800 drm/mediatek: Check CRTC state before freeing [ Upstream commit 233a4d3a39fc1585f5e271b2adab43c6af025ae0 ] mtk_crtc_reset() destroys the current CRTC state only when crtc->state is non-NULL, but it always converts crtc->state to struct mtk_crtc_state and passes the result to kfree(). When reset is called without an existing state, container_of(NULL, ...) does not produce NULL. Keep the mtk state free in the same crtc->state guard as the helper state destruction. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 2d267b81898e ("drm/mtk: Use __drm_atomic_helper_crtc_reset") Signed-off-by: Ruoyu Wang Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260707150528.2270739-1-ruoyuw560@gmail.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit f74554e67ccf04d1fa71069e8c9afa2717e40716 Author: Xiang Mei Date: Sun Jul 12 16:42:01 2026 -0700 netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in sip_help_tcp() [ Upstream commit db3d0e0e5d4bc5ab4fe445b9f413d1b486508ca5 ] sip_help_tcp() stores the size change of each NAT-rewritten SIP message in s16 diff and accumulates it in s16 tdiff, but a single message can grow by more than S16_MAX while the packet stays under the 65535 enlarge_skb() limit: nf_nat_sip() rewrites every matching URI, and a long Contact list expands the message by tens of kilobytes. diff then wraps, and "datalen = datalen + diff - msglen" yields a huge unsigned datalen, so the next iteration's ct_sip_get_header() reads past the linearized skb tail. Widen diff, tdiff and the seq_adjust hook to s32. Both are bounded by the 65535 byte packet limit, and the seqadj core is already s32 (nf_ct_seqadj_set() takes s32), so no previously accepted input is rejected. BUG: KASAN: use-after-free in ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25 ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) sip_help_tcp (net/netfilter/nf_conntrack_sip.c:1694) nf_confirm (net/netfilter/nf_conntrack_proto.c:183) nf_hook_slow (net/netfilter/core.c:619) ip6_output (net/ipv6/ip6_output.c:246) ip6_forward (net/ipv6/ip6_output.c:690) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6212) process_backlog (net/core/dev.c:6676) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ... Fixes: f5b321bd37fb ("netfilter: nf_conntrack_sip: add TCP support") Reported-by: Weiming Shi Link: https://patch.msgid.link/netfilter-devel/20260712234201.3213635-1-xmei5@asu.edu Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit ec81ecd2ac0930e232e5e9e456aa8d965477df95 Author: Radhey Shyam Pandey Date: Mon Jul 20 21:08:31 2026 +0530 phy: zynqmp: fix runtime PM leak on probe allocation failure [ Upstream commit f3506e15cf72e94f62d5f2d173e5b7008f644cde ] Allocate saved_regs before pm_runtime_resume_and_get() so a devm_kmalloc() failure does not leave an unreleased runtime PM usage counter. Fixes: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume") Signed-off-by: Radhey Shyam Pandey Reviewed-by: Michal Simek Link: https://patch.msgid.link/20260720153832.1130006-3-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 86fb88ac8c91583d89a80a9c1cfe47c1ba32d430 Author: Radhey Shyam Pandey Date: Mon Jul 20 21:08:30 2026 +0530 phy: zynqmp: fix clock error handling in xpsgtr_phy_init() [ Upstream commit e4779e2a16d600892aaf743438f6ce8cc4eb3c4c ] Propagate clk_prepare_enable() failures to the caller instead of returning success, and disable the reference clock on initialization error paths to avoid leaking clock references when phy_exit() is not called. Fixes: 25d700833513 ("phy: xilinx: phy-zynqmp: dynamic clock support for power-save") Signed-off-by: Radhey Shyam Pandey Reviewed-by: Michal Simek Link: https://patch.msgid.link/20260720153832.1130006-2-radhey.shyam.pandey@amd.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit dff474e723edea86624d077ea73945f0ecdee48a Author: Qu Wenruo Date: Sun Jul 12 13:12:51 2026 +0930 btrfs: raid56: fix an incorrect csum skip during scrub [ Upstream commit 330dcc553f282e8dc0b88c9495b4c296465364e1 ] Commit 7425a2894019 ("btrfs: introduce btrfs_bio_for_each_block_all() helper") uses the new helper to replace the nested loop inside verify_bio_data_sectors(), which simplifies the code. However that also changed the behavior of "continue" when a block has no data checksum. Previously the "continue" would skip the old for() loop, which would also increase @total_sector_nr. Now the "continue" will skip the new btrfs_bio_for_each_block_all() loop, which doesn't update @total_sector_nr. This means if we hit a block that has no data checksum, we will skip all the remaining blocks no matter if they have data checksum. As @total_sector_nr will never be updated, and that test_bit() will always return false. Fix it by increasing @total_sector_nr before calling "continue". Fixes: 7425a2894019 ("btrfs: introduce btrfs_bio_for_each_block_all() helper") Reviewed-by: Daniel Vacek Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4d4ef6627304acc39b6c8c09325e5dc9167a7ed7 Author: Johannes Thumshirn Date: Fri Jul 3 07:54:45 2026 +0200 btrfs: zoned: reset meta_write_pointer on zone reset [ Upstream commit 5fabb1cf25d723274009d7b759545fd59f230c9d ] btrfs_reset_unused_block_groups() resets a block group's zone and sets alloc_offset back to 0 so the space can be reused, but it leaves meta_write_pointer pointing at the previous end of the zone. Once the block group is reactivated and reused for metadata, newly allocated tree blocks live before that stale write pointer. btrfs_check_meta_write_pointer() then sees them behind the write pointer, so they can never be written out in sequential order: the dirty extent buffers are stranded and pin their btree_inode folios until unmount. Reset meta_write_pointer back to the start of the block group for metadata and system block groups. Fixes: 453a73c3069a ("btrfs: zoned: reclaim unused zone by zone resetting") Reviewed-by: Naohiro Aota Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit deddd28fd83c264ee2ff5cd6b34449a9f1be6112 Author: Johannes Thumshirn Date: Fri Jul 3 07:54:40 2026 +0200 btrfs: zoned: fix deadlock between metadata writeback and transaction commit [ Upstream commit 1ebe51c29fa9755d5b2fea28727c051117907cf8 ] When writing out metadata extent buffers in a zoned filesystem, btree_writepages() holds fs_info->zoned_meta_io_lock across the whole writeback loop, including the call to btrfs_check_meta_write_pointer() -> check_bg_is_active(). For the tree-log block group, check_bg_is_active() may fail to activate the zone and fall back to btrfs_zone_finish_one_bg() to free an active zone. That path waits for the running transaction to commit while still holding zoned_meta_io_lock, but the committer needs that same lock to write out the tree extents, so the two tasks deadlock: Task A (kworker, metadata writeback) Task B (fsstress, transaction commit) ------------------------------------ ------------------------------------- wb_workfn() btrfs_commit_transaction(T) btree_writepages() btrfs_write_and_wait_transaction() btrfs_zoned_meta_io_lock() btrfs_write_marked_extents() btrfs_check_meta_write_pointer() btree_writepages() check_bg_is_active() [treelog_bg] btrfs_zoned_meta_io_lock() btrfs_zone_finish_one_bg() do_zone_finish() btrfs_inc_block_group_ro() btrfs_wait_for_commit() The sibling branch in check_bg_is_active() already drops zoned_meta_io_lock around do_zone_finish() for this exact reason. Do the same in the tree-log branch: release the lock around btrfs_zone_finish_one_bg() and re-acquire it afterwards. The lock only protects fs_info->active_{meta,system}_bg, which this branch does not touch, and ctx->zoned_bg keeps a reference to the block group across the unlock, so nothing is lost while the lock is dropped. This hang occasionally reproduces with fstests generic/475 on a zoned btrfs filesystem. Fixes: 13bb483d32ab ("btrfs: zoned: activate metadata block group on write time") Reviewed-by: Naohiro Aota Signed-off-by: Johannes Thumshirn Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 762561c438599a5eee789fade69802748803a364 Author: Qu Wenruo Date: Sat Jul 4 17:58:56 2026 +0930 btrfs: fix leaking BTRFS_FS_STATE_REMOUNTING flag [ Upstream commit 6881f45d0eb541f2cee8c37c84b3860a23823bb3 ] [BUG] The following script can lead to unexpected qgroup rescan failure: # mkfs.btrfs -f -O quota $dev # mount $dev $mnt # mount -o remount,rescue=ibadroots $mnt ^^^^^ This above command is expected to fail # btrfs quota rescan -w $mnt ^^^^^ The above qgroup rescan is not expected to fail # btrfs qgroup show $mnt WARNING: qgroup data inconsistent, rescan recommended Qgroupid Referenced Exclusive Path -------- ---------- --------- ---- 0/5 16.00KiB 16.00KiB The above short script will be converted to a proper fstests case. [CAUSE] Inside btrfs_reconfigure(), if either btrfs_check_options() or btrfs_check_features() failed, we will always have BTRFS_FS_STATE_REMOUNTING set for the fs until the next successful remount. That BTRFS_FS_STATE_REMOUNTING flag will interrupt several operations, including: - Qgroup rescan - Auto defrag - Space reclaim [FIX] Change the error handling of btrfs_check_options() and btrfs_check_features() to goto restore label. Fixes: eddb1a433f26 ("btrfs: add reconfigure callback for fs_context") Reviewed-by: Johannes Thumshirn Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit cfa7e2734877330d6c10e0f33953905486c4530c Author: Sang-Heon Jeon Date: Sun Jun 14 22:38:06 2026 +0900 of: reserved_mem: prevent OOB when too many dynamic regions are defined [ Upstream commit db3dbdfea1b8f38774419c5c2c14e4b81c48708d ] On boot, fdt_scan_reserved_mem() saves each dynamically-placed /reserved-memory subnode into a local array of size MAX_RESERVED_REGIONS. If the device tree defines more than MAX_RESERVED_REGIONS dynamically-placed regions, fdt_scan_reserved_mem() writes past the end of the local array. Add a bounds check that logs an error and skips the excess regions, restoring the original behavior. Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed") Signed-off-by: Sang-Heon Jeon Link: https://patch.msgid.link/20260614133807.2165124-2-ekffu200098@gmail.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin commit f5edba9bc69d0a93cb39137dbbcbb839caf8cf13 Author: Uday Khare Date: Mon Jul 20 16:12:54 2026 +0530 ASoC: max98090: fix missing IS_ERR() before PTR_ERR() on mclk lookup [ Upstream commit a792ce0fad61a70793ec565743f11d6ca534de59 ] In max98090_probe(), the -EPROBE_DEFER check after devm_clk_get() is broken due to a missing IS_ERR() guard. The code intends to return -EPROBE_DEFER only when the clock lookup fails with that specific error. However, without IS_ERR() the check: if (PTR_ERR(max98090->mclk) == -EPROBE_DEFER) is called unconditionally, including when devm_clk_get() succeeds and returns a valid pointer. Calling PTR_ERR() on a valid pointer reinterprets its address as a signed long; the result is arbitrary and is almost never equal to -EPROBE_DEFER, so the check silently does nothing in the success case. When devm_clk_get() fails with any error other than -EPROBE_DEFER the check is also skipped, leaving max98090->mclk holding an error pointer with no indication to the caller. This means a deferred probe will never actually be triggered for this device, and any non-EPROBE_DEFER clock error is silently swallowed with the error pointer left in the mclk field. Fix this by adding the missing IS_ERR() guard around the PTR_ERR() call, matching the pattern already used in the sibling max98088 and wm8960 drivers. Fixes: b10ab7b838bd ("ASoC: max98090: Add master clock handling") Signed-off-by: Uday Khare Link: https://patch.msgid.link/20260720104254.14948-1-udaykhare77@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3cbfb9b886dc1936f0dd27e0504f7481deaf12de Author: Uday Khare Date: Mon Jul 20 16:09:50 2026 +0530 ASoC: max98095: fix missing IS_ERR() before PTR_ERR() on mclk lookup [ Upstream commit 317e21532e6ffa1de026bdbce5ba98e1b70ca5c6 ] In max98095_probe(), the -EPROBE_DEFER check after devm_clk_get() is broken due to a missing IS_ERR() guard. The code intends to return -EPROBE_DEFER only when the clock lookup fails with that specific error. However, without IS_ERR() the check: if (PTR_ERR(max98095->mclk) == -EPROBE_DEFER) is called unconditionally, including when devm_clk_get() succeeds and returns a valid pointer. Calling PTR_ERR() on a valid pointer reinterprets its address as a signed long; the result is arbitrary and is almost never equal to -EPROBE_DEFER, so the check silently does nothing in the success case. When devm_clk_get() fails with any error other than -EPROBE_DEFER the check is also skipped, leaving max98095->mclk holding an error pointer with no indication to the caller. This means a deferred probe will never actually be triggered for this device, and any non-EPROBE_DEFER clock error is silently swallowed with the error pointer left in the mclk field. Fix this by adding the missing IS_ERR() guard around the PTR_ERR() call, matching the pattern already used in the sibling max98088 and wm8960 drivers. Fixes: e3048c3d2be5 ("ASoC: max98095: Add master clock handling") Signed-off-by: Uday Khare Link: https://patch.msgid.link/20260720103950.14474-1-udaykhare77@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3fd94b9ffe997e5e6a47e667b3d0398e9b4cae07 Author: Krishna Kurapati Date: Sat Jul 18 15:01:31 2026 +0530 phy: qcom: m31-eusb2: Fix return value of init call [ Upstream commit 361f533a2dce2c2841fe4dc0c9d85a67117edf95 ] The init call currently returns success irrespective of any failures during repeater init or clock enablement. Return appropriate error value in the init call failure path. Fixes: 9c8504861cc4 ("phy: qcom: Add M31 based eUSB2 PHY driver") Signed-off-by: Krishna Kurapati Link: https://patch.msgid.link/20260718-m31-eusb2-fix-v1-1-8588a1b94d76@oss.qualcomm.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 9355f526c821fd618549c065fecfbedaf8d37e5c Author: Radhey Shyam Pandey Date: Fri Jul 17 23:55:26 2026 +0530 ata: ahci_ceva: fix error paths in ceva_ahci_platform_enable_resources() [ Upstream commit 4d99a91574c420decab56cc880fad0dc15b8a7a3 ] On phy_init() failure the error path fallsthrough to disable_rsts, which deasserts the controller reset and then enters disable_phys calling phy_power_off() on PHYs that were never powered on. That corrupts the PHY power_count and triggers an extra runtime PM put. Use a separate exit_phys path that unwinds with phy_exit() only and falls through to disable_clks while the controller remains in reset. Reserve phy_power_off() for the phy_power_on() failure path only, and skip masked-out ports in both unwind loops. On phy_power_on() failure re-assert the controller reset before disabling clocks and regulators, matching the teardown order used by ahci_platform_enable_resources() and ahci_platform_disable_resources(). Fixes: 26c8404e162b ("ata: ahci_ceva: fix error handling for Xilinx GT PHY support") Signed-off-by: Radhey Shyam Pandey Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit a0f288ebe6d8ab78527bed2e331033255b9e065f Author: Rosen Penev Date: Sun Jul 12 15:31:37 2026 -0700 ata: sata_mv: accept 1 or 2 resources in platform probe [ Upstream commit ef19a9cf037957fe3a35df8355c76ff0a63a0436 ] Board files in arch/arm/plat-orion, arch/arm/mach-dove, arch/arm/mach-mv78xx0 and arch/arm/mach-orion5x still register the "sata_mv" device with two resources (IORESOURCE_MEM plus IORESOURCE_IRQ). Those devices are rejected with -EINVAL, so SATA no longer probes on legacy Marvell Orion/Kirkwood-style boards. Accept both 1 resource (DT, IRQ fetched via platform_get_irq()) and 2 resources (legacy, IRQ supplied as a second resource) so both probing paths work. Fixes: b3b2bec9646e ("ata: sata_mv: Fixes expected number of resources now IRQs are gone") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 8229a538885401c744b9ffb2b4cdbc0c0d2c5cb7 Author: Kuan-Ying Lee Date: Wed Jul 15 13:35:52 2026 +0800 selftests/seccomp: Fix pointer type mismatch build error [ Upstream commit 3421b9b056a6576d0ebac1030eafb48ad0544092 ] We hit the following build error while running the seccomp selftests in our testing. CC seccomp_bpf seccomp_bpf.c: In function ‘UPROBE_setup’: seccomp_bpf.c:5175:74: error: pointer type mismatch in conditional expression [-Wincompatible-pointer-types] 5175 | offset = get_uprobe_offset(variant->uretprobe ? probed_uretprobe : probed_uprobe); | ^ seccomp_bpf.c:5175:57: note: first expression has type ‘int (*)(void)’ 5175 | offset = get_uprobe_offset(variant->uretprobe ? probed_uretprobe : probed_uprobe); | ^~~~~~~~~~~~~~~~ seccomp_bpf.c:5175:76: note: second expression has type ‘int (__attribute__((nocf_check)) *)(void)’ 5175 | offset = get_uprobe_offset(variant->uretprobe ? probed_uretprobe : probed_uprobe); | ^~~~~~~~~~~~~ get_uprobe_offset() takes a 'const void *' argument, so cast both operands to 'void *'. Fixes: 9ffc7a635c35 ("selftests/seccomp: validate uprobe syscall passes through seccomp") Signed-off-by: Kuan-Ying Lee Acked-by: Jiri Olsa Link: https://patch.msgid.link/20260715053559.28535-1-kuan-ying.lee@canonical.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 99dc2c143dfc03bdf7de2e163ec401fbbe343ae6 Author: Haofeng Li Date: Wed Jul 15 16:02:10 2026 +0800 selftests/lkdtm: rename STACKLEAK_ERASING to KSTACK_ERASE [ Upstream commit b3a7aa9c0020ae549a0d4964867ff66d2bd61709 ] Commit 57fbad15c2ee ("stackleak: Rename STACKLEAK to KSTACK_ERASE") renamed the LKDTM crash type and selftest configuration but missed the entry in tests.txt. As a result, the selftest generates STACKLEAK_ERASING.sh, which run.sh skips because the LKDTM DIRECT trigger only exposes KSTACK_ERASE. Rename the test entry so the generated runner uses the registered crash type. Fixes: 57fbad15c2ee ("stackleak: Rename STACKLEAK to KSTACK_ERASE") Signed-off-by: Haofeng Li Link: https://patch.msgid.link/tencent_CD80B5F746B6AABD68AF3F1097AD02C96F05@qq.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 094145989b31f8926707d3f1ca7c79d71858b67d Author: Abdun Nihaal Date: Wed Jul 15 13:23:08 2026 +0530 gpio: sloppy-logic-analyzer: Fix memory leak in gpio_la_poll_probe() [ Upstream commit 7a7baebd9f23ba4f24796775472b2fd00dcd95d9 ] The memory allocated for priv->blob.data is not freed in the error paths that follow the fops_buf_size_set() call in gpio_la_poll_probe(), as well as in the remove function. Fix that by using device managed action to free the memory on remove. Fixes: 7828b7bbbf20 ("gpio: add sloppy logic analyzer using polling") Signed-off-by: Abdun Nihaal Reviewed-by: Wolfram Sang Link: https://patch.msgid.link/20260715075311.527753-1-nihaal@cse.iitm.ac.in Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 3808bab5d95ae79e333e11f6a73d178e084c645d Author: Nicolin Chen Date: Sun Jul 5 22:36:11 2026 -0700 iommu/arm-smmu-v3-iommufd: Require exactly one Stream ID for a vDEVICE [ Upstream commit c3b8ee84a965058b41275069d4696f37a8b14bf6 ] arm_vsmmu_vsid_to_sid() maps a guest's vSID to a single physical Stream ID taken from master->streams[0], assuming a device has exactly one stream. A device with several streams gets only its first one mapped, so a guest vSID invalidation cannot reach the others' ATC and IOTLB entries; a device with none makes master->streams a ZERO_SIZE_PTR, read out of bounds. Add an arm_vsmmu_vdevice_init() op to reject the vDEVICE with -EOPNOTSUPP when master->num_streams is not one, rather than mapping it silently. Fixes: d68beb276ba26 ("iommu/arm-smmu-v3: Support IOMMU_HWPT_INVALIDATE using a VIOMMU object") Link: https://patch.msgid.link/r/b15f2b73520f389f3f57881da2f040e7bdc18876.1783311134.git.nicolinc@nvidia.com Reviewed-by: Kevin Tian Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Pranjal Shrivastava Signed-off-by: Nicolin Chen Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 0679c0c189d2548f00e1bac95be28e2df5c6c7f7 Author: Yuho Choi Date: Mon May 25 10:15:50 2026 -0400 dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open() [ Upstream commit ee1d7274102285d78a53161fc705a8d8cd40b066 ] The failed_dev_add and failed_dev_name paths drop the file-device reference while wq->wq_lock is still held. If put_device(fdev) drops the last reference, idxd_file_dev_release() runs synchronously and tries to take wq->wq_lock again, deadlocking. Those paths also fall through into the later ctx cleanup labels even though idxd_file_dev_release() owns that cleanup and frees ctx. This can make idxd_xa_pasid_remove(ctx) and kfree(ctx) operate on a freed context. Move idxd_wq_get() before file-device setup can fail, since the release callback always calls idxd_wq_put(). Then unlock wq->wq_lock before put_device(fdev) and return directly from the file-device setup failure path, leaving ctx cleanup to the release callback. Fixes: e6fd6d7e5f0fe ("dmaengine: idxd: add a device to represent the file opened") Signed-off-by: Yuho Choi Reviewed-by: Dave Jiang Acked-by: Vinicius Costa Gomes Link: https://patch.msgid.link/20260525141550.1385581-1-dbgh9129@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 9086b488f2737d5dcee86852b83f2059f1cdfabf Author: Hongling Zeng Date: Wed Jul 1 12:57:33 2026 +0800 dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA [ Upstream commit ab1150115e68a46b687eb38c1ab92782018c9f2c ] When terminating DMA transfers, active descriptors are not properly reclaimed. Only cyclic descriptors were handled, leaving non-cyclic descriptors and their LLI chains to be permanently leaked. Fix by using vchan_terminate_vdesc() which handles both cyclic and non-cyclic descriptors by adding them to desc_terminated queue for proper cleanup. Add pchan->desc != pchan->done check to prevent double-adding completed descriptors, which would corrupt the list. Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller") Signed-off-by: Hongling Zeng Acked-by: Jernej Skrabec Suggested-by: Frank Li Reviewed-by: Frank Li Link: https://patch.msgid.link/20260701045733.33654-1-zenghongling@kylinos.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 2ef9bb422dd6d94097b464ed8265ed6ec1b9346a Author: Konrad Dybcio Date: Fri Jun 26 15:08:05 2026 +0200 pinctrl: qcom: sc8280xp: Add missing wakeup entries for GPIO143/151 [ Upstream commit 437a8d2aa1aa442c4a176fdf4700a9b3bb0c8794 ] Pins 143 and 151 were not included in the PDC wakeup map. They are normally used for PCIe2A and PCIe3a PERST# respectively, so they're unlikely to be excercised in practice, but still add them for the sake of completeness. Fixes: c0e4c71a9e7c ("pinctrl: qcom: Introduce sc8280xp TLMM driver") Signed-off-by: Konrad Dybcio Link: https://patch.msgid.link/20260626-topic-8280_pinctrl_wakeup-v1-1-2ccb267148f5@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 3e55d280954760e4b5127cf7e0bd11cbbf2f496b Author: Sneh Mankad Date: Tue Jun 16 17:24:53 2026 +0530 pinctrl: qcom: Unconditionally mark gpio as wakeup enable [ Upstream commit 859e02a369ab328a77dfcabf59562100e55f9c5c ] GPIO interrupts that are wakeup capable need to be forwarded to wakeup capable parent irqchip. This is done via writing to it's wakeup_enable bit. Currently the bit is set only for PDC irqchip by checking skip_wake_irqs. skip_wake_irqs is set to differentiate between parent irqchips MPM and PDC. It is set when the parent irqchip is PDC to inform pinctrl about skipping the IRQ setting up at TLMM. However, the functionality to forward GPIO interrupts during SoC low power mode is needed regardless of which parent irqchip it is. Without the functionality it is impossible for MPM irqchip to detect the GPIO interrupt during SoC low power mode since for MPM irqchip the skip_wake_irqs is always false. Remove skip_wake_irqs condition when setting wakeup enable bit to allow forwarding GPIO interrupts for SoCs using MPM irqchip too. Fixes: 76b446f5b86e ("pinctrl: qcom: handle intr_target_reg wakeup_present/enable bits") Signed-off-by: Sneh Mankad Reviewed-by: Maulik Shah Reviewed-by: Linus Walleij Reviewed-by: Konrad Dybcio Link: https://patch.msgid.link/20260616-enable_wakeup_capable_gpios-v3-1-fb59647d89cb@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 54a62153c765cd24239cde1f2633f2a2fd005368 Author: Michael Bommarito Date: Wed May 27 07:46:04 2026 -0400 thunderbolt: Prevent XDomain delayed work use-after-free on disconnect [ Upstream commit 2c5d2d3c3f70cde2565d7b279b544893a2035842 ] tb_xdp_handle_request() runs on system_wq and queues xd->state_work via queue_delayed_work() in three request handlers: PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake), and LINK_STATE_CHANGE_REQUEST. Similarly, update_xdomain() queues xd->properties_changed_work when local properties change. Concurrently, tb_xdomain_remove() calls stop_handshake() which does cancel_delayed_work_sync() on both delayed works. Later, tb_xdomain_unregister() calls device_unregister() which eventually frees the xdomain. Since commit 559c1e1e0134 ("thunderbolt: Run tb_xdp_handle_request() in system workqueue") moved the request handler off tb->wq, the handler and the remove path are no longer serialized. If queue_delayed_work() executes after cancel_delayed_work_sync() but before the xdomain is freed, the delayed work fires on a freed object. Add xd->removing that tb_xdomain_remove() sets under xd->lock before calling stop_handshake(). Each external queue site holds the same lock and checks removing before calling queue_delayed_work(). This provides the mutual exclusion needed: either the queue site acquires the lock first and queues work that the subsequent cancel will see, or the remove path acquires the lock first and the queue site observes removing == true and skips the queue. Fixes: 559c1e1e0134 ("thunderbolt: Run tb_xdp_handle_request() in system workqueue") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit d01e88d421a6d07f35235600a43fbd0e551cf292 Author: Harry Yoo (Oracle) Date: Mon Aug 3 07:15:11 2026 +0000 mm/slab: prevent unbounded recursion in free path with new kmalloc type commit d9e6a7623938968e3752b67e37eaff097e559a54 upstream. Commit 280ea9c3154b ("mm/slab: avoid allocating slabobj_ext array from its own slab") avoided recursive allocation of obj_exts from kmalloc caches of the same size, by bumping the obj_exts array's allocation size whenever the array size equals the size of the object being allocated. However, as reported by Danielle Costantino and Shakeel Butt, even slabs from kmalloc caches of different sizes can form a cycle by allocating obj_exts arrays from each other [1]: What happened: a KMALLOC_NORMAL slab's obj_exts array (used by allocation profiling / memcg accounting) is itself kmalloc()'d from a KMALLOC_NORMAL cache, so the "slab holds another slab's obj_exts array" relation can form cycles. With sizeof(struct slabobj_ext) == 16 and the host's geometry: - kmalloc-512 has 64 objects/slab -> array is 64*16 == 1024 bytes, served from kmalloc-1k; - kmalloc-1k has 32 objects/slab -> array is 32*16 == 512 bytes, served from kmalloc-512. A kmalloc-512 slab and a kmalloc-1k slab therefore hold each other's obj_exts array. Discarding one frees the other's array, which empties and discards that slab, which frees the first's array, and so on: __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() -> __free_slab() recurses along the cycle until the stack is exhausted. With memory allocation profiling, this allows unbounded recursion in the free path and led to a stack overflow on a production host in the Meta fleet [1]: BUG: TASK stack guard page was hit Oops: stack guard page RIP: 0010:kfree+0x8/0x5d0 Call Trace: __free_slab+0x66/0xc0 kfree+0x3f0/0x5d0 ... ( ~125x __free_slab <-> kfree ) ... do_syscall_64 It is proposed [1] to resolve this issue by always serving the obj_exts array allocation from kmalloc caches (or large kmalloc) of sizes larger than the object size. However, as pointed out by Vlastimil Babka [2], this can waste an excessive amount of memory as slabs from large kmalloc sizes (e.g. kmalloc-8k) generally need obj_exts arrays much smaller than the object size. Therefore, rather than bumping the size, let us take a different approach; disallow formation of cycles between kmalloc types when allocating obj_exts arrays. Currently, all obj_exts arrays are served from normal kmalloc caches. Cycles cannot be created if obj_exts arrays of normal kmalloc caches are served from a special kmalloc type that can never have obj_exts arrays. To achieve this, create a new kmalloc type called KMALLOC_NO_OBJ_EXT. KMALLOC_NO_OBJ_EXT caches are created with SLAB_NO_OBJ_EXT flag when either 1) memory allocation profiling is not permanently disabled, or 2) kmalloc types with a priority higher than KMALLOC_CGROUP are aliased with KMALLOC_NORMAL. Sheaf bootstrapping for KMALLOC_NO_OBJ_EXT caches now must be deferred because allocation of a barn can trigger obj_exts array allocation of normal kmalloc caches when the KMALLOC_NO_OBJ_EXT cache for that size is not ready yet. For simplicity, perform bootstrapping of sheaves for all kmalloc caches later. Introduce a new slab alloc flag, SLAB_ALLOC_NO_OBJ_EXT, to prevent allocation of obj_exts arrays, and let kmalloc_slab() override the type to KMALLOC_NO_OBJ_EXT when specified. Note that kmalloc_type() remains unchanged because kmalloc_flags() bypasses the kmalloc fastpath. Do not pass SLAB_ALLOC_NO_RECURSE to kmalloc_flags() in alloc_slab_obj_exts() and instead use SLAB_ALLOC_NO_OBJ_EXT only when the objects are allocated from normal kmalloc caches. While this prevents unbounded recursive allocation of obj_exts, it allows KMALLOC_NO_OBJ_EXT caches to have sheaves. Since sheaf allocations specify SLAB_ALLOC_NO_RECURSE that prevents allocation of both sheaves and obj_exts arrays, the recursion depth is bounded. obj_exts arrays for non-kmalloc-normal caches can now have a valid tag. Do not call mark_obj_codetag_empty() when freeing an obj_exts array to avoid false warnings. KMALLOC_NO_OBJ_EXT don't need this as they never allocate those arrays. Reported-by: Danielle Costantino Reported-by: Shakeel Butt Closes: https://lore.kernel.org/linux-mm/20260625230029.703750-1-shakeel.butt@linux.dev [1] Fixes: 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mm/c5c4208d-a6f0-413e-bad9-49be12f12d55@kernel.org [2] Signed-off-by: Harry Yoo (Oracle) Reviewed-by: Suren Baghdasaryan Link: https://patch.msgid.link/20260713-kmalloc-no-objext-v3-4-47c7bd138de7@kernel.org Signed-off-by: Vlastimil Babka (SUSE) [harry@kernel.org: Backport notes: - Fix a minor conflict due to missing partitioned kmalloc caches in 6.18. - Use __GFP_NO_OBJ_EXT instead of SLAB_ALLOC_NO_OBJ_EXT since slab's internal alloc_flags do not exist in 6.18. - Deferring sheaf bootstrapping for kmalloc caches is not applied as they don't have sheaves in 6.18. - Adjust the comment for SLAB_NO_OBJ_EXT, like in the commit 982e31382d9a ("mm/slab: decouple SLAB_NO_SHEAVES from SLAB_NO_OBJ_EXT"). The rest of that commit is a no-op in 6.18 as kmalloc caches don't have sheaves and thus only adjust the comment. - Apply the __GFP_NO_OBJ_EXT flag to the !allow_spin path in alloc_slab_obj_exts(). ] Signed-off-by: Harry Yoo Signed-off-by: Sasha Levin commit 3e957c9b160cf8789637c7bc733148b90872c78c Author: Harry Yoo (Oracle) Date: Mon Aug 3 07:15:10 2026 +0000 lib/alloc_tag: introduce mem_alloc_profiling_permanently_disabled() commit a37b0066a10aabf3c968b4566706fb866eaf9a85 upstream. mem_alloc_profiling_enabled() tells whether memalloc profiling is currently enabled. However, even when this function returns false, it can be enabled later. However, this is not enough. Some optimizations can be applied only when memalloc profiling is permanently disabled. For example, to skip the creation of KMALLOC_NO_OBJ_EXT caches at boot time, mem_profiling must be set to "never", "0" w/ debugging on, or have been shutdown so that it can no longer be enabled. Introduce mem_alloc_profiling_permanently_disabled() for this purpose. Signed-off-by: Harry Yoo (Oracle) Acked-by: Suren Baghdasaryan Link: https://patch.msgid.link/20260713-kmalloc-no-objext-v3-3-47c7bd138de7@kernel.org Signed-off-by: Vlastimil Babka (SUSE) Signed-off-by: Harry Yoo Signed-off-by: Sasha Levin commit 98f57011e6cd1322cd376b1965c44583d343f12c Author: Benjamin Tissoires Date: Fri Apr 10 16:03:07 2026 +0200 HID: logitech-dj: fix wrong detection of bad DJ_SHORT output report [ Upstream commit 8b9a097eb2fc37b486afd81388c693bf3ab44466 ] commit b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write") assumed that all HID devices attached to the logitech-dj driver was having an output report of DJ_SHORT. However, on the receiver itself, we have 2 other HID device we attach here: the mouse emulation and the keyboard emulation. For those devices the value of rep is NULL and we are triggered a segfault here. This is doubly required because logitech-dj also handles non DJ devices that might not have the DJ collection. Fixes: b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write") Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit bc3bba4656ad280267ea78cf845ab6b1d95b9fcd Author: Lee Jones Date: Tue Mar 24 14:36:44 2026 +0000 HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write [ Upstream commit b6a57912854e7ea36f3b270032661140cc4209cd ] logi_dj_recv_send_report() assumes that all incoming REPORT_ID_DJ_SHORT reports are 14 Bytes (DJREPORT_SHORT_LENGTH - 1) long. It uses that assumption to load the associated field's 'value' array with 14 Bytes of data. However, if a malicious user only sends say 1 Byte of data, 'report_count' will be 1 and only 1 Byte of memory will be allocated to the 'value' Byte array. When we come to populate 'value[1-13]' we will experience an OOB write. Signed-off-by: Lee Jones Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit df0f33293c0a3f4b06cf4b362dbeba21489c1a1b Author: Lee Jones Date: Tue Mar 24 14:36:43 2026 +0000 HID: logitech-dj: Standardise hid_report_enum variable nomenclature [ Upstream commit a940aee176437046598dfc786b719bd96db3c74c ] Since we will need to differentiate between the two report_enum types soon, let's unify the naming conventions now to save confusion and/or unnecessary/unrelated changes in upcoming commits. {input,output}_report_enum is used in other places to let's conform. Signed-off-by: Lee Jones Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 302eb87651326f6f9f4e77e09e3cd5a600f049c1 Author: Fabian Lippold Date: Tue May 26 17:41:01 2026 +0200 ALSA: hda/realtek: add quirk for HP Dragonfly Folio G3 2-in-1 [ Upstream commit 0a10faad5ca58332ad70f7663ba82611f4daf736 ] Add PCI quirk for HP Dragonfly Folio G3 (PCI ID 103c:8a06) to select the CS35L41 SPI4 & GPIO LED fixup variant. Signed-off-by: Fabian Lippold Link: https://patch.msgid.link/20260526154418.1850568-3-fabianlippold1184@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e8362523fd1b61712f7d996802f9b5dee545c7e6 Author: Honglei Huang Date: Fri Jul 31 19:17:28 2026 +0800 drm/gpusvm: publish dpagemap early to avoid device mapping leak on error commit 7f708f51e3955bda0d77a0b67ab9bea6c97fea99 upstream. drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages->dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx->allow_mixed is false) and jumped to err_unmap, svm_pages->dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages->dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review. Fixes: f70da6f99d4f ("drm/gpusvm: pull out drm_gpusvm_pages substructure") Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost Signed-off-by: Honglei Huang Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260701062800.409248-4-honghuan@amd.com [ Adjusted for 6.18.y: drop drm_pagemap_get()/drm_pagemap_put() around the svm_pages->dpagemap assignment; that reference counting is not present in 6.18 where the field is not refcounted (unmap path only clears it). ] Signed-off-by: Honglei Huang Signed-off-by: Sasha Levin commit a5cdd2407dd890f741f59b8367e4c6c101cce154 Author: Yehyeong Lee Date: Thu Jul 23 10:08:29 2026 +0900 net: mpls: initialize rtm_tos in mpls_getroute() [ Upstream commit 295dd295e2137e10e9a5b1891d97e0f08de76f03 ] mpls_getroute() builds the RTM_NEWROUTE reply to an RTM_GETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (alloc_skb(NLMSG_GOODSIZE, ...)). It sets every field of the header except rtm_tos: r = nlmsg_data(nlh); r->rtm_family = AF_MPLS; r->rtm_dst_len = 20; r->rtm_src_len = 0; r->rtm_table = RT_TABLE_MAIN; r->rtm_type = RTN_UNICAST; r->rtm_scope = RT_SCOPE_UNIVERSE; r->rtm_protocol = rt->rt_protocol; r->rtm_flags = 0; struct rtmsg has no padding, so the one uninitialised byte rtm_tos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mpls_dump_route(), which fills the very same header and does set rtm_tos = 0. Initialize rtm_tos to 0, matching mpls_dump_route(). Reproduced with KMSAN by adding an MPLS route and issuing a non-RTM_F_FIB_MATCH RTM_GETROUTE for its label: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x36c/0x33f0 _copy_to_iter+0x36c/0x33f0 __skb_datagram_iter+0x196/0x12c0 skb_copy_datagram_iter+0x5b/0x210 netlink_recvmsg+0x37b/0xef0 ... Uninit was created at: __alloc_skb+0x8ca/0x10e0 mpls_getroute+0x1280/0x3a40 rtnetlink_rcv_msg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized (byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtm_tos) Fixes: 397fc9e5cefe ("mpls: route get support") Signed-off-by: Yehyeong Lee Link: https://patch.msgid.link/20260723010830.289917-1-yhlee@isslab.korea.ac.kr Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 85b94a74a0b83306c69e00844ea45c0bd1dba057 Author: Lorenzo Bianconi Date: Thu May 14 16:46:38 2026 +0200 netfilter: br_netfilter: Reallocate headroom if necessary in neigh_hh_bridge() [ Upstream commit b2870fc21601db9133bc70c48c603b487614fa3b ] neigh_hh_bridge() assumes the skb always has sufficient headroom to copy the aligned L2 header. This assumption can trigger the crash reported below using the following netfilter setup: $modprobe br_netfilter $sysctl -w net.bridge.bridge-nf-call-iptables=1 $root@OpenWrt:~# nft list ruleset table ip nat { chain prerouting { type nat hook prerouting priority dstnat; policy accept; ip daddr 192.168.83.123 dnat to 192.168.83.120 } } - iperf3 client (192.168.83.119) --> bridge (192.168.83.118) --> iperf3 server (192.168.83.120) the iperf3 client is sending packet for 192.168.83.123 to the bridge device. [ 1579.036575] Unable to handle kernel write to read-only memory at virtual address ffffff8004d76ffe [ 1579.045482] Mem abort info: [ 1579.048273] ESR = 0x000000009600004f [ 1579.052024] EC = 0x25: DABT (current EL), IL = 32 bits [ 1579.057363] SET = 0, FnV = 0 [ 1579.060417] EA = 0, S1PTW = 0 [ 1579.063550] FSC = 0x0f: level 3 permission fault [ 1579.068345] Data abort info: [ 1579.071224] ISV = 0, ISS = 0x0000004f, ISS2 = 0x00000000 [ 1579.076720] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 [ 1579.081770] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1579.087092] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000080dc4000 [ 1579.093794] [ffffff8004d76ffe] pgd=180000009ffff003, p4d=180000009ffff003, pud=180000009ffff003, pmd=180000009ffe3003, pte=0060000084d76787 [ 1579.106343] Internal error: Oops: 000000009600004f [#1] SMP [ 1579.193824] CPU: 0 UID: 0 PID: 235 Comm: napi/qdma_eth-3 Tainted: G O 6.12.57 #0 [ 1579.202614] Tainted: [O]=OOT_MODULE [ 1579.206102] Hardware name: Airoha AN7581 Evaluation Board (DT) [ 1579.211929] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1579.218889] pc : br_nf_pre_routing_finish_bridge+0x1ac/0xcc8 [br_netfilter] [ 1579.225859] lr : br_nf_pre_routing_finish_bridge+0x18c/0xcc8 [br_netfilter] [ 1579.232822] sp : ffffffc0817cba20 [ 1579.236128] x29: ffffffc0817cba20 x28: 0000000000000000 x27: ffffff8002b89000 [ 1579.243273] x26: ffffff8004d7700e x25: 0000000000000008 x24: 0000000000000000 [ 1579.250416] x23: ffffffc08179d4c0 x22: 0000000000000000 x21: ffffffc08179d4c0 [ 1579.257561] x20: ffffff8004d9b800 x19: ffffff8015010000 x18: 0000000000000014 [ 1579.264704] x17: ffffffbf9e930000 x16: ffffffc0817c8000 x15: 0000000000000070 [ 1579.271848] x14: 0000000000000080 x13: 0000000000000001 x12: 0000000000000000 [ 1579.278993] x11: ffffffc0798caae0 x10: ffffff8014db6fd8 x9 : 0000000000000000 [ 1579.286136] x8 : 0000000000000003 x7 : ffffffc08171f628 x6 : 000000001a3b83d3 [ 1579.293281] x5 : 0000000000000000 x4 : 1beb76f22fee0000 x3 : ffffff8004d7700e [ 1579.300425] x2 : 0000000000000000 x1 : ffffff8004d9b8bc x0 : ffffff80026ed000 [ 1579.307570] Call trace: [ 1579.310018] br_nf_pre_routing_finish_bridge+0x1ac/0xcc8 [br_netfilter] [ 1579.316632] br_nf_hook_thresh+0xd4/0x14bc [br_netfilter] [ 1579.322032] br_nf_hook_thresh+0x250/0x14bc [br_netfilter] [ 1579.327517] br_nf_hook_thresh+0x76c/0x14bc [br_netfilter] [ 1579.333003] br_handle_frame+0x180/0x480 [ 1579.336935] __netif_receive_skb_core.constprop.0+0x540/0xf40 [ 1579.342682] __netif_receive_skb_one_core+0x28/0x50 [ 1579.347561] process_backlog+0x98/0x1e0 [ 1579.351398] __napi_poll+0x34/0x1c4 [ 1579.354887] net_rx_action+0x178/0x330 [ 1579.358638] handle_softirqs+0x108/0x2d4 [ 1579.362560] __do_softirq+0x10/0x18 [ 1579.366051] ____do_softirq+0xc/0x20 [ 1579.369627] call_on_irq_stack+0x30/0x4c [ 1579.373550] do_softirq_own_stack+0x18/0x20 [ 1579.377734] do_softirq+0x4c/0x60 [ 1579.381050] __local_bh_enable_ip+0x88/0x98 [ 1579.385234] napi_threaded_poll_loop+0x188/0x21c [ 1579.389853] napi_threaded_poll+0x70/0x80 [ 1579.393863] kthread+0xd8/0xdc [ 1579.396918] ret_from_fork+0x10/0x20 [ 1579.400499] Code: 88dffc22 3707ffc2 f9406663 f9406684 (f81f0064) [ 1579.406589] ---[ end trace 0000000000000000 ]--- [ 1579.411209] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 1579.418083] SMP: stopping secondary CPUs [ 1579.422012] Kernel Offset: disabled Fix the issue reallocating the skb headroom if necessary in neigh_hh_bridge routine. Fixes: e179e6322ac33 ("netfilter: bridge-netfilter: Fix MAC header handling with IP DNAT") Reviewed-by: Ido Schimmel Signed-off-by: Lorenzo Bianconi Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9bb3714e09986e56bf7294ee9c91e499eb7ea287 Author: David Gow Date: Sat Feb 28 18:07:22 2026 +0800 kunit: tool: Terminate kernel under test on SIGINT [ Upstream commit 8f260b02eeeffbf2263c2b82b6e3e32fd73cde2b ] kunit.py will attempt to catch SIGINT / ^C in order to ensure the TTY isn't messed up, but never actually attempts to terminate the running kernel (be it UML or QEMU). This can lead to a bit of frustration if the kernel has crashed or hung. Terminate the kernel process in the signal handler, if it's running. This requires plumbing through the process handle in a few more places (and having some checks to see if the kernel is still running in places where it may have already been killed). Reported-by: Andy Shevchenko Closes: https://lore.kernel.org/all/aaFmiAmg9S18EANA@smile.fi.intel.com/ Signed-off-by: David Gow Reviewed-by: Andy Shevchenko Tested-by: Andy Shevchenko Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit d36086cd1826e79a92debb9280a800c642d4b8a3 Author: Shuvam Pandey Date: Fri Feb 27 18:16:36 2026 +0545 kunit: tool: skip stty when stdin is not a tty [ Upstream commit e42c349f4cdfa43cb39a68c8f764f8cafc23a9a9 ] run_kernel() cleanup and signal_handler() invoke stty unconditionally. When stdin is not a tty (for example in CI or unit tests), this writes noise to stderr. Call stty only when stdin is a tty. Add regression tests for these paths: - run_kernel() with non-tty stdin - signal_handler() with non-tty stdin - signal_handler() with tty stdin Signed-off-by: Shuvam Pandey Reviewed-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 285641eb82f0e150e639e18bc44ce7c8567ce3b4 Author: Pablo Neira Ayuso Date: Thu May 7 13:00:28 2026 +0200 netfilter: nf_conntrack_expect: restore helper propagation via expectation [ Upstream commit dcb0f9aefdd604d36710fda53c25bd7cf4a3e37a ] A recent series to fix expectations broke helper propagation via expectation, this mechanism is used by the sip and h323 helper. This also propagates the conntrack helper to expected connections. I changed semantics of exp->helper which now tells us the actual helper that created the expectation. Add an explicit assign_helper field to expectations for this purpose and update helpers to use it. Restore this feature for userspace conntrack helper via ctnetlink nfqueue integration so it is again possible to attach a helper to an expectation, where it makes sense. This is not restored via ctnetlink expectation creation as there is no client for such feature. Use the expectation layer 4 protocol number for the helper lookup for consistency. Make sure the expectation using this helper propagation mechanism also go away when the helper is unregistered. Fixes: 9c42bc9db90a ("netfilter: nf_conntrack_expect: honor expectation helper field") Fixes: 917b61fa2042 ("netfilter: ctnetlink: ignore explicit helper on new expectations") Reported-by: Ilya Maximets Tested-by: Ilya Maximets Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7b923c78b50d2ec52690c4353e5aad8302e80599 Author: Greg Kroah-Hartman Date: Thu Aug 6 19:27:09 2026 +0200 Linux 6.18.43 Signed-off-by: Greg Kroah-Hartman commit bfe7f9993467ba431b2731437949ac1e2634e771 Author: Borislav Petkov (AMD) Date: Tue Jun 2 21:26:44 2026 -0700 x86/bugs: Make Safe-RET robust against interrupt injection commit 7e7f81cf6f5ca3311e526308f55d7c54d3ba71f9 upstream. An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by "emulating" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt. Co-developed-by: David Kaplan Signed-off-by: David Kaplan Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Greg Kroah-Hartman commit 054f69ce6232eb73b1d0f4210939027e25f20d08 Author: Alexandre Frade Date: Mon Aug 3 16:39:11 2026 +0000 Linux 6.18.42-xanmod1 Signed-off-by: Alexandre Frade commit 764d67d28fa6e9878845cd5f1b86a8cd497f7ad7 Merge: 929ca27d531b 856a9b51680c Author: Alexandre Frade Date: Mon Aug 3 16:38:02 2026 +0000 Merge tag 'v6.18.42' into 6.18 This is the 6.18.42 stable release commit 856a9b51680cbbed1ace1207b29e424a616cff48 Author: Greg Kroah-Hartman Date: Mon Aug 3 11:22:13 2026 +0200 Linux 6.18.42 Link: https://lore.kernel.org/r/20260730141445.110192266@linuxfoundation.org Tested-by: Miguel Ojeda Tested-by: Wentao Guan Tested-by: Florian Fainelli Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Shuah Khan Tested-by: Pavel Machek (CIP) Tested-by: Mark Brown Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman commit 0f33b1c457c2199ed130b92cc2ff363a3f7b9415 Author: Nikunj A Dadhania Date: Wed Jul 15 06:35:06 2026 +0000 KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug commit 25f744ffa0c8e799e06250ce2e618367b166b0d4 upstream. If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle. Fixes: 774c47f1d78e ("[PATCH] KVM: cpu hotplug support") Reported-by: Chandrakanth Silveru Tested-by: Srikanth Aithal Reviewed-by: K Prateek Nayak Reviewed-by: Tom Lendacky Signed-off-by: Nikunj A Dadhania Message-ID: <20260715063506.672432-1-nikunj@amd.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 846ed916cfa0c57308aabc1c9fec2ce9a883b092 Author: Koen Koning Date: Fri Feb 13 16:20:47 2026 +0100 gpu: Fix uninitialized buddy for built-in drivers commit cc27314c67516c138ee3829197d1c3b998e29fae upstream. Move buddy to the start of the link order, so its __init runs before any other built-in drivers that may depend on it. Otherwise, a built-in driver that tries to use the buddy allocator will run into a kernel NULL pointer dereference because slab_blocks is uninitialized. Specifically, this fixes drm/xe (as built-in) running into a kernel panic during boot, because it uses buddy during device probe. Fixes: ba110db8e1bc ("gpu: Move DRM buddy allocator one level up (part two)") Cc: Joel Fernandes Cc: Dave Airlie Cc: intel-xe@lists.freedesktop.org Reviewed-by: Dave Airlie Tested-by: Peter Senna Tschudin Signed-off-by: Koen Koning Signed-off-by: Dave Airlie Link: https://patch.msgid.link/20260213152047.179628-1-koen.koning@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit bcb29986bbba8e1febbfb0c055478a76bd0be536 Author: Russell King (Oracle) Date: Fri Jan 16 00:49:24 2026 +0000 net: stmmac: fix dwmac4 transmit performance regression commit 5ccde4c81e843ab6b3a324c8e2aa96d9b1270a1a upstream. dwmac4's transmit performance dropped by a factor of four due to an incorrect assumption about which definitions are for what. This highlights the need for sane register macros. Commit 8409495bf6c9 ("net: stmmac: cores: remove many xxx_SHIFT definitions") changed the way the txpbl value is merged into the register: value = readl(ioaddr + DMA_CHAN_TX_CONTROL(dwmac4_addrs, chan)); - value = value | (txpbl << DMA_BUS_MODE_PBL_SHIFT); + value = value | FIELD_PREP(DMA_BUS_MODE_PBL, txpbl); With the following in the header file: #define DMA_BUS_MODE_PBL BIT(16) -#define DMA_BUS_MODE_PBL_SHIFT 16 The assumption here was that DMA_BUS_MODE_PBL was the mask for DMA_BUS_MODE_PBL_SHIFT, but this turns out not to be the case. The field is actually six bits wide, buts 21:16, and is called TXPBL. What's even more confusing is, there turns out to be a PBLX8 single bit in the DMA_CHAN_CONTROL register (0x1100 for channel 0), and DMA_BUS_MODE_PBL seems to be used for that. However, this bit et.al. was listed under a comment "/* DMA SYS Bus Mode bitmap */" which is for register 0x1004. Fix this up by adding an appropriately named field definition under the DMA_CHAN_TX_CONTROL() register address definition. Move the RPBL mask definition under DMA_CHAN_RX_CONTROL(), correctly renaming it as well. Also move the PBL bit definition under DMA_CHAN_CONTROL(), correctly renaming it. This removes confusion over the PBL fields. Fixes: 8409495bf6c9 ("net: stmmac: cores: remove many xxx_SHIFT definitions") Signed-off-by: Russell King (Oracle) Bisected-by: Maxime Chevallier Link: https://lore.kernel.org/51859704-57fd-4913-b09d-9ac58a57f185@bootlin.com Tested-by: Maxime Chevallier Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/E1vgY1k-00000003vOC-0Z1H@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a0d1a11b90a512afc011308da197bfa5157db5d1 Author: Gal Pressman Date: Thu Dec 25 15:27:15 2025 +0200 net/mlx5e: Fix NULL pointer dereference in ioctl module EEPROM query commit 7d36a4a8bf62dc508bc6bb4b59727aec25064ca5 upstream. The mlx5_query_mcia() function unconditionally dereferences the status pointer to store the MCIA register status value. However, mlx5e_get_module_id() passes NULL since it doesn't need the status value. Add a NULL check before dereferencing the status pointer to prevent a NULL pointer dereference. Fixes: 2e4c44b12f4d ("net/mlx5: Refactor EEPROM query error handling to return status separately") Signed-off-by: Gal Pressman Reviewed-by: Tariq Toukan Reviewed-by: Dragos Tatulea Signed-off-by: Mark Bloch Link: https://patch.msgid.link/20251225132717.358820-4-mbloch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f282242906c12fd476b86757afba51f211d4f959 Author: Cen Zhang Date: Sat Jun 27 18:41:53 2026 +0800 usb: gadget: f_tcm: synchronize delayed set_alt with teardown commit 79e2d75725c85607f8a9d87ae9cace62a19f767d upstream. The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT") Cc: stable Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Link: https://patch.msgid.link/20260627104153.3822495-1-zzzccc427@gmail.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aeebcfa8237c314ddcae2c85204bfef842af3a85 Author: Alice Ryhl Date: Thu Jul 16 10:22:43 2026 +0000 rust: device: avoid trailing ; in printing macros commit a19bda861b3a79e25417462539df8b0d77c6b322 upstream. These macros are used like expressions, so they should not emit a semicolon. This is being turned into a hard error in a future release of Rust. error: trailing semicolon in macro used in expression position --> drivers/gpu/nova-core/firmware/fsp.rs:79:34 | 79 | .inspect_err(|_| dev_err!(dev, "FMC firmware missing '{}' section\n", name)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #79813 = note: this error originates in the macro `dev_err` (in Nightly builds, run with -Z macro-backtrace for more info) [ I was doubly surprised since upstream made it a deny-by-default lint a year ago for Rust 1.91.0, and yet we didn't see it; plus I hadn't seen this in my CI even yesterday. It turns out this just landed into today's nightly (nightly-2026-07-16, using upstream commit d0babd8b6): Link: https://github.com/rust-lang/rust/pull/159222 which says: "The `semicolon_in_expressions_from_macros` lint previously suppressed warnings about non-local macros. This masks a lint that will subsequently become a hard error." So that explains it. And this is the PR that will make it a hard error at some point in the future: Link: https://github.com/rust-lang/rust/pull/159218 Thus starting with Rust 1.99.0 (expected 2026-10-01), we will be seeing the deny-by-default lint above, so clean it up already. - Miguel ] Cc: stable@vger.kernel.org # Needed in 6.18.y and later. Link: https://github.com/rust-lang/rust/issues/79813 Signed-off-by: Alice Ryhl Reviewed-by: Gary Guo Acked-by: Danilo Krummrich Link: https://github.com/rust-lang/rust/pull/159218 Link: https://github.com/rust-lang/rust/pull/159222 Link: https://patch.msgid.link/20260716-device-trail-semicolon-v1-1-f48e9dcfae15@google.com [ Fixed typo. ] Signed-off-by: Miguel Ojeda [ Resolved conflict on `dev_printk` by not performing a similar cleanup since it is not strictly needed. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit e94e820df37d487a92ca08e77bc8d2319267152b Author: Miguel Ojeda Date: Mon Jun 15 16:32:25 2026 +0200 rust: allow `suspicious_runtime_symbol_definitions` lint for Rust >= 1.98 commit 608045a91d9176d66b2114d0006bc8b57dff2ca9 upstream. Starting with Rust 1.98.0 (expected 2026-08-20), Rust is introducing a couple new lints, `invalid_runtime_symbol_definitions` (deny-by-default) and `suspicious_runtime_symbol_definitions` (warn-by-default), which check the signature of items whose symbol name is a runtime symbol expected by `core`. Our build hits the second one, i.e. the warning: error: suspicious definition of the runtime `strlen` symbol used by the standard library --> rust/bindings/bindings_generated.rs:20018:5 | 20018 | pub fn strlen(s: *const ffi::c_char) -> usize; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: expected `unsafe extern "C" fn(*const i8) -> usize` found `unsafe extern "C" fn(*const u8) -> usize` = help: either fix the signature or remove any attributes like `#[unsafe(no_mangle)]`, `#[unsafe(export_name = "strlen")]`, or `#[link_name = "strlen"]` = help: allow this lint if the signature is compatible = note: `-D suspicious-runtime-symbol-definitions` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(suspicious_runtime_symbol_definitions)]` error: suspicious definition of the runtime `strlen` symbol used by the standard library --> rust/uapi/uapi_generated.rs:14236:5 | 14236 | pub fn strlen(s: *const ffi::c_char) -> usize; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: expected `unsafe extern "C" fn(*const i8) -> usize` found `unsafe extern "C" fn(*const u8) -> usize` = help: either fix the signature or remove any attributes like `#[unsafe(no_mangle)]`, `#[unsafe(export_name = "strlen")]`, or `#[link_name = "strlen"]` = help: allow this lint if the signature is compatible = note: `-D suspicious-runtime-symbol-definitions` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(suspicious_runtime_symbol_definitions)]` Thus `allow` the lint in `bindings` and `uapi`. A more targeted alternative to avoid `allow`ing it would be to pass `--blocklist-function strlen` to `bindgen`, but we would perhaps need to adjust if other C headers end up adding more (or Rust checking more). Since it is just the less critical one that we hit, and since eventually this should be properly fixed by getting upstream Rust to provide a flag like GCC/Clang's `-funsigned-char` [2][3], just `allow` it for now. Cc: Urgau Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/155521 [1] Link: https://github.com/rust-lang/rust/issues/138446 [2] Link: https://github.com/Rust-for-Linux/linux/issues/355 [3] Reviewed-by: Gary Guo Reviewed-by: Alice Ryhl Reviewed-by: Tamir Duberstein Link: https://patch.msgid.link/20260615143225.471756-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 6ce0db97fb37ab8cf8596edca0e3de8618ab009a Author: SJ Park Date: Fri Jul 3 09:56:08 2026 -0700 mm/damon/core: disallow overlapping input ranges for damon_set_regions() commit 954157679ec34661c2e87e7eb796104a797c32db upstream. damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f ("mm/damon/sysfs: reuse damon_set_regions() for regions setting") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f ("mm/damon/sysfs: reuse damon_set_regions() for regions setting"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260703165610.92894-1-sj@kernel.org Link: https://lore.kernel.org/20260630041806.151124-1-sj@kernel.org [1] Fixes: 97d482f4592f ("mm/damon/sysfs: reuse damon_set_regions() for regions setting") Signed-off-by: SJ Park Cc: # 5.19.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit 4b6f1d6d5d07855bd1bb9e64922b049062138bfa Author: SJ Park Date: Mon Jun 29 20:52:19 2026 -0700 mm/damon/core: validate ranges in damon_set_regions() commit 1292c0ecb1caefb8ca064a3639d5673991e8810c upstream. DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function. Link: https://lore.kernel.org/20260630035221.146458-1-sj@kernel.org Fixes: 43b0536cb471 ("mm/damon: introduce DAMON-based Reclamation (DAMON_RECLAIM)") Signed-off-by: SJ Park Cc: Yang yingliang Cc: # 5.16.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman commit deead12d2e650b4c1f97c50d4a5a2dc1117e8805 Author: Adrian Hunter Date: Wed Jul 29 17:23:51 2026 -0400 i3c: mipi-i3c-hci: Fix handling of shared IRQs during early initialization [ Upstream commit c6396b835a5e599c4df656112140f065bb544a24 ] Shared interrupts may fire unexpectedly, including during periods when the controller is not yet fully initialized. Commit b9a15012a1452 ("i3c: mipi-i3c-hci: Add optional Runtime PM support") addressed this issue for the runtime-suspended state, but the same problem can also occur before the bus is enabled for the first time. Ensure the IRQ handler ignores interrupts until initialization is complete by making consistent use of the existing irq_inactive flag. The flag is now set to false immediately before enabling the bus. To guarantee correct ordering with respect to the IRQ handler, protect all transitions of irq_inactive with the same spinlock used inside the handler. Fixes: b8460480f62e1 ("i3c: mipi-i3c-hci: Allow for Multi-Bus Instances") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260306072451.11131-14-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 811b581fae651f6824a68e9108c9107eed809a8a Author: Adrian Hunter Date: Wed Jul 29 17:23:50 2026 -0400 i3c: mipi-i3c-hci: Fix Hot-Join NACK [ Upstream commit fa9586bd77ada1e3861c7bef65f6bb9dcf8d9481 ] The MIPI I3C HCI host controller driver does not implement Hot-Join handling, yet Hot-Join response control defaults to allowing devices to Hot-Join the bus. Configure HC_CONTROL_HOT_JOIN_CTRL to NACK all Hot-Join attempts. Fixes: 9ad9a52cce282 ("i3c/master: introduce the mipi-i3c-hci driver") Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter Reviewed-by: Frank Li Link: https://patch.msgid.link/20260306072451.11131-3-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni Stable-dep-of: c6396b835a5e ("i3c: mipi-i3c-hci: Fix handling of shared IRQs during early initialization") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4fd5b33faf092ef2d09f730a7d9e49f9e976ac67 Author: Guoniu Zhou Date: Wed Jul 29 14:02:08 2026 -0400 pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI [ Upstream commit 99611233f8cda833169fa6487d5dacdf189e5cb0 ] The MIPI DSI and CSI domains share control bits for clock and reset, which can lead to incorrect behavior if one domain disables the shared resource while the other is still active. To fix the issue, introduce a shared MIPI PHY power domain to own the common resources and make DSI and CSI its subdomains. This ensures the shared bits are properly managed and not disabled while still in use. Fixes: e9aa77d413c9 ("soc: imx: add i.MX93 media blk ctrl driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Reviewed-by: Frank Li Reviewed-by: Peng Fan Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c389893bb40371143aaef6e12eb850448faa4f61 Author: Marco Felsch Date: Wed Jul 29 14:02:07 2026 -0400 pmdomain: imx93-blk-ctrl: convert to devm_* only [ Upstream commit 52becc142280eeef828d19f9cd01fd653b588786 ] Convert the driver to devm_ APIs only by making use of devm_add_action_or_reset() and devm_pm_runtime_enable() to simplify the probe error path and to drop the .remove() callback. This also ensures that the device release order equals the device probe error path order. Furthermore drop the dev_set_drvdata() usage since the only user was the .remove() callback which is removed by this commit. Reviewed-by: Frank Li Signed-off-by: Marco Felsch Signed-off-by: Ulf Hansson Stable-dep-of: 99611233f8cd ("pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dc8347f263b21a5d2f32ca50f2c5fd3fce75a512 Author: Haoxiang Li Date: Tue Jul 28 22:30:25 2026 -0400 net: ipa: fix SMEM state handle leaks in SMP2P init [ Upstream commit 96ca1e658ae459276292bd6d971ab5d8c7e0379a ] ipa_smp2p_init() acquires two Qualcomm SMEM state handles with qcom_smem_state_get(). However, neither the init error paths nor ipa_smp2p_exit() release them. Release both handles with qcom_smem_state_put() in the init error paths and in ipa_smp2p_exit(). Fixes: 530f9216a953 ("soc: qcom: ipa: AP/modem communications") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Larysa Zaremba Reviewed-by: Alex Elder Link: https://patch.msgid.link/20260624065955.2822765-1-haoxiang_li2024@163.com Signed-off-by: Jakub Kicinski [ kzalloc_obj() context line kept as kzalloc(sizeof(*smp2p), GFP_KERNEL) since ipa_smp2p.c was not yet converted in this tree ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4c1e8ccd8655ee8cf1bcb1b7dfee72c9fa941fd4 Author: Bryam Vargas Date: Tue Jul 28 20:30:49 2026 -0400 ata: libata-core: Reject an invalid concurrent positioning ranges count [ Upstream commit 533a0b940f901c15e5cbbd4b5d66e871c209e8ce ] ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there. Suggested-by: Damien Le Moal Fixes: fe22e1c2f705 ("libata: support concurrent positioning ranges log") Fixes: c745dfc541e7 ("libata: fix reading concurrent positioning ranges log") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Reviewed-by: Niklas Cassel Signed-off-by: Damien Le Moal [ adapted `kzalloc_flex()` allocation to `kzalloc(struct_size(...), GFP_KERNEL)` and adjusted context offsets. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9466dc5e377f009f1dc2d42d01a049a29bb029f5 Author: Breno Leitao Date: Tue Jul 28 12:29:46 2026 -0400 bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline() [ Upstream commit dec4d8118c179b3d12bca7e609054c6011c4f2ce ] xbc_snprint_cmdline() is meant to be called twice: first with buf=NULL, size=0 to probe the rendered length, then with a real buffer to fill it (the standard snprintf() two-pass pattern). The probe call makes the function compute "buf + size" (NULL + 0) and, on every iteration, advance "buf += ret" from that NULL base and pass the result back into snprintf(). Pointer arithmetic on a NULL pointer is undefined behavior. It is harmless in the in-kernel callers today, but the follow-up patches run this same code in the userspace tools/bootconfig parser at kernel build time, where host UBSan / FORTIFY_SOURCE abort the build. Track a running written length (size_t) instead of mutating @buf, and only form "buf + len" when @buf is non-NULL. snprintf(NULL, 0, ...) is itself well defined and returns the would-be length, so the two-pass "probe then fill" usage returns identical byte counts. Link: https://lore.kernel.org/all/20260626-bootconfig_using_tools-v7-1-24ab72139c29@debian.org/ Fixes: 51887d03aca1 ("bootconfig: init: Allow admin to use bootconfig for kernel command line") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a88c2a70ea0ad9739f06448fa1d974b09ead939e Author: Breno Leitao Date: Tue Jul 28 12:29:45 2026 -0400 bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c [ Upstream commit 5a643e4623238e14b03d75ca0d4eda0645720cee ] Move xbc_snprint_cmdline() from init/main.c to lib/bootconfig.c so the function (and its xbc_namebuf scratch buffer) becomes part of the shared parser library. tools/bootconfig already compiles lib/bootconfig.c directly, which lets a follow-up patch reuse the same renderer in the userspace tool to convert a bootconfig file into a flat cmdline string at build time. No functional change. Link: https://lore.kernel.org/all/20260508-bootconfig_using_tools-v1-1-1132219aa773@debian.org/ Signed-off-by: Breno Leitao Signed-off-by: Masami Hiramatsu (Google) Stable-dep-of: dec4d8118c17 ("bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c73b8795b45f4ad5a95120d2e9b435ea4616e08e Author: Junrui Luo Date: Tue Jul 28 09:30:37 2026 -0400 octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF [ Upstream commit 8cdcf3d2caacdee7ddd363705fb4d93b0c1a0915 ] rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block. Fixes: 893ae97214c3 ("octeontx2-af: cn10k: Support configurable LMTST regions") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB78811656934E713B77DA6CEDAFE62@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4467fa514482bbce82f73788943c815f3d126ab3 Author: Michael Bommarito Date: Tue Jul 28 09:30:36 2026 -0400 octeontx2-af: validate body pcifunc in rvu_mbox_handler_rep_event_notify [ Upstream commit 2156a29aecfffa2eb7c558255690084efbe9f3b0 ] rvu_mbox_handler_rep_event_notify() in drivers/net/ethernet/marvell/ octeontx2/af/rvu_rep.c queues a sender-controlled REP_EVENT_NOTIFY request body verbatim, and rvu_rep_up_notify() then forwards event->pcifunc (the nested body field, distinct from the AF-normalised header pcifunc) into rvu_get_pfvf(), rvu_get_pf() and the AF->PF mailbox device index without any bounds check. A VF attached to a PF that has been put into switchdev representor mode reaches this path: the VF mailbox handler otx2_pfvf_mbox_handler() forwards every message id including MBOX_MSG_REP_EVENT_NOTIFY to AF without an allowlist, and the AF dispatcher rewrites only msg->pcifunc, leaving struct rep_event::pcifunc attacker-controlled. The sibling rvu_mbox_handler_esw_cfg() refuses requests whose header pcifunc is not rvu->rep_pcifunc; this handler has no equivalent gate. An out-of-range body pcifunc selects an &rvu->pf[]/&rvu->hwvf[] element past the allocated array and, for RVU_EVENT_MAC_ADDR_CHANGE, turns into a six-byte attacker-chosen OOB ether_addr_copy() target inside the queued worker; KASAN reports a slab-out-of-bounds write in rvu_rep_wq_handler. Reject malformed requests at the handler entry by gating on is_pf_func_valid(), which is already the canonical PF/VF range check in this driver; expose it via rvu.h so callers in rvu_rep.c can use it instead of open-coding the same range arithmetic. Fixes: b8fea84a0468 ("octeontx2-pf: Add support to sync link state between representor and VFs") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/20260520154157.1439319-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Stable-dep-of: 8cdcf3d2caac ("octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ae5ae3d5bfaa698cf689b86d593eb68b5d3e4342 Author: Shradha Gupta Date: Mon Jul 27 23:57:14 2026 -0400 net: mana: Optimize irq affinity for low vcpu configs [ Upstream commit 5316394b1752f6cf3f9901e7fefdec1cd1d97fd3 ] Before the commit 755391121038 ("net: mana: Allocate MSI-X vectors dynamically"), all the MANA IRQs were assigned statically and together during early driver load. After this commit, the IRQ allocation for MANA was done in two phases. HWC IRQ allocated earlier and then, queue IRQs dynamically added at a later point. By this time, the IRQ weights on vCPUs can become imbalanced and if IRQ count is greater than the vCPU count the topology aware IRQ distribution logic in MANA can cause multiple MANA IRQs to land on the same vCPUs, while other sibling vCPUs have none (case 1). On SMP enabled, low-vCPU systems, this becomes a bigger problem as the softIRQ handling overhead of two IRQs on the same vCPUs becomes much more than their overheads if they were spread across sibling vCPUs. In such cases when many parallel TCP connections are tested, the throughput drops significantly. Fix the affinity assignment logic, in cases where the IRQ count is greater than the vCPU count and when IRQs are added dynamically, by utilizing all the vCPUs irrespective of their NUMA/core bindings (case 2). The results of setting the affinity and hint to NULL were also studied, and we observed that, with this logic if there are pre-existing IRQs allocated on the VM (apart from MANA), during MANA IRQs allocation, it leads to clustering of the MANA queue IRQs again (case 3). ======================================================= Case 1: without this patch ======================================================= 4 vcpu(2 cores), 5 MANA IRQs (1 HWC + 4 Queue) TYPE effective vCPU aff ======================================================= IRQ0: HWC 0 IRQ1: mana_q1 0 IRQ2: mana_q2 2 IRQ3: mana_q3 0 IRQ4: mana_q4 3 %soft on each vCPU(mpstat -P ALL 1) on receiver vCPU 0 1 2 3 ======================================================= pass 1: 38.85 0.03 24.89 24.65 pass 2: 39.15 0.03 24.57 25.28 pass 3: 40.36 0.03 23.20 23.17 ======================================================= Case 2: with this patch ======================================================= 4 vcpu(2 cores), 5 MANA IRQs (1 HWC + 4 Queue) TYPE effective vCPU aff ======================================================= IRQ0: HWC 0 IRQ1: mana_q1 0 IRQ2: mana_q2 1 IRQ3: mana_q3 2 IRQ4: mana_q4 3 %soft on each vCPU(mpstat -P ALL 1) on receiver vCPU 0 1 2 3 ======================================================= pass 1: 15.42 15.85 14.99 14.51 pass 2: 15.53 15.94 15.81 15.93 pass 3: 16.41 16.35 16.40 16.36 ======================================================= Case 3: with affinity set to NULL ======================================================= 4 vCPU(2 cores), 5 MANA IRQs (1 HWC + 4 Queue) TYPE effective vCPU aff ======================================================= IRQ0: HWC 0 IRQ1: mana_q1 2 IRQ2: mana_q2 3 IRQ3: mana_q3 2 IRQ4: mana_q4 3 ======================================================= Throughput Impact(in Gbps, same env) ======================================================= TCP conn with patch w/o patch aff NULL 20480 15.65 7.73 5.25 10240 15.63 8.93 5.77 8192 15.64 9.69 7.16 6144 15.64 13.16 9.33 4096 15.69 15.75 13.50 2048 15.69 15.83 13.61 1024 15.71 15.28 13.60 Fixes: 755391121038 ("net: mana: Allocate MSI-X vectors dynamically") Cc: stable@vger.kernel.org Co-developed-by: Erni Sri Satya Vennela Signed-off-by: Erni Sri Satya Vennela Signed-off-by: Shradha Gupta Reviewed-by: Haiyang Zhang Reviewed-by: Simon Horman Reviewed-by: Yury Norov Link: https://patch.msgid.link/20260624072138.1632849-1-shradhagupta@linux.microsoft.com Signed-off-by: Jakub Kicinski [ Kept 7.1's `int *irqs, irq, err, i;` declaration (minus the deleted `skip_first_cpu`) instead of upstream's `msi` variant, as this tree lacks the `mana_gd_get_gic()` refactor. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6d13eaa13341a8f80aaf86f78591e1b1d393711d Author: Dexuan Cui Date: Mon Jul 27 22:46:45 2026 -0400 net: mana: Validate the packet length reported by the NIC [ Upstream commit 2e2a83b4998af4384e677d3b2ac08565274279bf ] Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted. Cc: stable@vger.kernel.org Reviewed-by: Haiyang Zhang Signed-off-by: Dexuan Cui Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Link: https://patch.msgid.link/20260702041237.617719-2-decui@microsoft.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7b7bb07efe41bb646a93c4624aa2bb35df190342 Author: Tony Luck Date: Mon Jul 27 19:34:20 2026 -0400 fs/resctrl: Fix use-after-free during unmount [ Upstream commit 52fce648607e0d6a76eeb443d78708c49df1c554 ] During unmount or failure teardown all mon_data structures that contain monitoring event file private data are freed after which kernfs nodes are removed. However, the RDT_DELETED flag is never set for the statically allocated default resource group. A concurrent reader of an event file associated with the default resource group may, after dropping kernfs active protection, block on rdtgroup_mutex while unmount proceeds to free the file private data and destroy the kernfs node without waiting for the reader. When the mutex is released, the reader wakes up, observes that RDT_DELETED is not set for the default group, and dereferences the already-freed file private data. The scenario can be depicted as follows: CPU0 CPU1 /* * Default resource group's * monitoring data accessible via * kernfs file with kernfs_node::priv * pointing to a struct mon_data. * User opens the file for reading. */ rdtgroup_mondata_show() /* arch encounters fatal error */ rdtgroup_kn_lock_live() resctrl_exit() atomic_inc(&rdtgroup_default.waitcount) cpus_read_lock() kernfs_break_active_protection(kn) mutex_lock(&rdtgroup_mutex) cpus_read_lock() resctrl_fs_teardown() mutex_lock(&rdtgroup_mutex) rmdir_all_sub() mon_put_kn_priv() /* Delete all mon_data structures */ rdtgroup_destroy_root() kernfs_destroy_root() rdtgroup_default.kn = NULL mutex_unlock(&rdtgroup_mutex) /* * rdtgroup_default.flags is empty so * rdtgroup_kn_lock_live() returns * &rdtgroup_default */ md = of->kn->priv; /* md points to freed mon_data */ Set RDT_DELETED for the default group unconditionally since the flag does not lead to the freeing of this statically allocated group. Do not allow a new resctrl mount if there are any waiters on default group of previous mount. A new mount will re-initialize the default group that would appear to waiters from previous mount as though the default group is accessible causing them to access the mon_data structures from the previous mount that have been removed. Fixes: 2a6566038544 ("x86/resctrl: Expand the width of domid by replacing mon_data_bits") Closes: https://sashiko.dev/#/patchset/20260508182143.14592-1-tony.luck%40intel.com?part=2 [1] Reported-by: Sashiko Signed-off-by: Tony Luck Signed-off-by: Reinette Chatre Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Chen Yu Cc: Link: https://patch.msgid.link/49a2ca3ca688f27e1a646cf90e1dc69287021127.1783377598.git.reinette.chatre@intel.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d48cf914c739e902ab2db228f6cd86e08fc5b869 Author: Tony Luck Date: Mon Jul 27 19:34:19 2026 -0400 fs/resctrl: Move RMID initialization to first mount [ Upstream commit d0891647fbc6e931f27517364cbc4ee1811d76db ] L3 monitor features are enumerated during resctrl initialization and rmid_ptrs[] that tracks all RMIDs and depends on the number of supported RMIDs is allocated during this time. Telemetry monitor features are enumerated during first resctrl mount and may support a different number of RMIDs compared to L3 monitor features. Delay allocation and initialization of rmid_ptrs[] until first mount. Since the number of RMIDs cannot change on later mounts, keep the same set of rmid_ptrs[] until resctrl_exit(). This is required because the limbo handler keeps running after resctrl is unmounted and needs to access rmid_ptrs[] as it keeps tracking busy RMIDs after unmount. Rename routines to match what they now do: dom_data_init() -> setup_rmid_lru_list() dom_data_exit() -> free_rmid_lru_list() Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Reinette Chatre Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com Stable-dep-of: 52fce648607e ("fs/resctrl: Fix use-after-free during unmount") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 682d3c2cd20e023bf90d2eb3cf216047e5f0d53e Author: Tony Luck Date: Mon Jul 27 19:34:18 2026 -0400 fs/resctrl: Move allocation/free of closid_num_dirty_rmid[] [ Upstream commit ee7f6af79f0916b6c49e15edd4cba020b3e4c4ac ] closid_num_dirty_rmid[] and rmid_ptrs[] are allocated together during resctrl initialization and freed together during resctrl exit. Telemetry events are enumerated on resctrl mount so only at resctrl mount will the number of RMID supported by all monitoring resources and needed as size for rmid_ptrs[] be known. Separate closid_num_dirty_rmid[] and rmid_ptrs[] allocation and free in preparation for rmid_ptrs[] to be allocated on resctrl mount. Keep the rdtgroup_mutex protection around the allocation and free of closid_num_dirty_rmid[] as ARM needs this to guarantee memory ordering. Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Reinette Chatre Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com Stable-dep-of: 52fce648607e ("fs/resctrl: Fix use-after-free during unmount") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8c5925f0fa128aae727da67416997911be39d834 Author: Tony Luck Date: Mon Jul 27 19:34:17 2026 -0400 x86,fs/resctrl: Rename some L3 specific functions [ Upstream commit 9c214d10c50990c7a61b95887493df9ae713eec5 ] With the arrival of monitor events tied to new domains associated with a different resource it would be clearer if the L3 resource specific functions are more accurately named. Rename three groups of functions: Functions that allocate/free architecture per-RMID MBM state information: arch_domain_mbm_alloc() -> l3_mon_domain_mbm_alloc() mon_domain_free() -> l3_mon_domain_free() Functions that allocate/free filesystem per-RMID MBM state information: domain_setup_mon_state() -> domain_setup_l3_mon_state() domain_destroy_mon_state() -> domain_destroy_l3_mon_state() Initialization/exit: rdt_get_mon_l3_config() -> rdt_get_l3_mon_config() resctrl_mon_resource_init() -> resctrl_l3_mon_resource_init() resctrl_mon_resource_exit() -> resctrl_l3_mon_resource_exit() Ensure kernel-doc descriptions of these functions' return values are present and correctly formatted. Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Reinette Chatre Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com Stable-dep-of: 52fce648607e ("fs/resctrl: Fix use-after-free during unmount") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 696c34a1964f42ee211a39936fc5cfa428e3fd2f Author: Tony Luck Date: Mon Jul 27 19:34:16 2026 -0400 x86,fs/resctrl: Rename struct rdt_mon_domain and rdt_hw_mon_domain [ Upstream commit 4bc3ef46ff41d5e7ba557e56e9cd2031527cd7f8 ] The upcoming telemetry event monitoring is not tied to the L3 resource and will have a new domain structure. Rename the L3 resource specific domain data structures to include "l3_" in their names to avoid confusion between the different resource specific domain structures: rdt_mon_domain -> rdt_l3_mon_domain rdt_hw_mon_domain -> rdt_hw_l3_mon_domain No functional change. Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Reinette Chatre Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com Stable-dep-of: 52fce648607e ("fs/resctrl: Fix use-after-free during unmount") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ad4ea2a169a4850857b774ab2fe4a0e07bf05ad6 Author: Tony Luck Date: Mon Jul 27 19:34:15 2026 -0400 fs/resctrl: Split L3 dependent parts out of __mon_event_count() [ Upstream commit ad5c2ff75e0c53d2588dfc10eb87458e759b6bbe ] Carve out the L3 resource specific event reading code into a separate helper to support reading event data from a new monitoring resource. Suggested-by: Reinette Chatre Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Reinette Chatre Link: https://lore.kernel.org/20251217172121.12030-1-tony.luck@intel.com Stable-dep-of: 52fce648607e ("fs/resctrl: Fix use-after-free during unmount") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5b82af744e06cd741938c3da54fdbe564a7e52d9 Author: Guangshuo Li Date: Mon Jul 27 18:20:45 2026 -0400 mmc: vub300: fix use-after-free on probe failure [ Upstream commit a3b5f242997a3be7404112fd48784881560aea57 ] The vub300 driver lifetime-manages its controller state using vub300->kref, with vub300_delete() freeing the mmc host when the last reference is dropped. The probe error path after the inactivity timer has been armed still bypasses that lifetime rule, however, and falls through to mmc_free_host() directly if mmc_add_host() fails. The race window is between arming the inactivity timer and reaching the probe error unwind after mmc_add_host() fails: probe thread timer/workqueue ------------ --------------- kref_init(&vub300->kref) ref = 1 kref_get(&vub300->kref) ref = 2, timer ref add_timer(inactivity_timer) fires after one second | | race window |<----------------------------------------------------> | mmc_add_host(mmc) inactivity timer fires vub300_queue_dead_work() kref_get() ref = 3 queue_work(deadwork) mmc_add_host() fails timer_delete_sync() mmc_free_host(mmc) frees vub300 deadwork runs use-after-free The inactivity timeout is one second, so this would require mmc_add_host() to both fail and take more than one second to do so. This is unlikely to happen in practice, but the error path is still wrong. timer_delete_sync() only waits for the timer callback itself. It does not flush deadwork that the callback may already have queued. As a result, queued deadwork can still hold a kref while the probe error path directly frees the backing mmc host, including the vub300 storage. Fix this by using the same lifetime mechanism as disconnect. Clear vub300->interface so that the timer callback and any queued deadwork return early and drop their references, then drop the initial probe reference and return without falling through to err_free_host. Fixes: 0613ad2401f8 ("mmc: vub300: fix return value check of mmc_add_host()") Signed-off-by: Guangshuo Li Reviewed-by: Johan Hovold Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 73d397ab54f2a013eebbda9d44a5fb40894bedc3 Author: Johan Hovold Date: Mon Jul 27 18:20:44 2026 -0400 mmc: vub300: rename probe error labels [ Upstream commit 5b8b35d6f4fa758dd5e8ae18526ea1c73f6787e0 ] Error labels should be named after what they do. Rename the probe error labels. Signed-off-by: Johan Hovold Signed-off-by: Ulf Hansson Stable-dep-of: a3b5f242997a ("mmc: vub300: fix use-after-free on probe failure") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8ced1d242c34e342defcccdb00663354f212aae6 Author: Ingo Blechschmidt Date: Mon Jul 27 16:59:58 2026 -0400 dm: avoid leaking the caller's thread keyring via the table device file [ Upstream commit 981ccd97f7153d310dfa92a534525bbaf46752c2 ] The refactoring in commit a28d893eb327 ("md: port block device access to file") accidentally causes the caller's thread keyring to be kept alive long beyond the caller's lifetime. As a result, "cryptsetup luksSuspend" silently fails to wipe the LUKS volume key from memory. In detail: "cryptsetup luksOpen" uses its supposedly ephemeral thread keyring to pass the volume key to the kernel. dm-crypt's crypt_set_keyring_key() copies the key material into its own crypt_config structure and then drops its own reference to the key in the keyring with key_put(). With this fix, restoring pre-v6.9 behavior, the copy in the thread keyring is then promptly garbage collected, such that exactly one copy of the volume key remains. This single copy is correctly wiped from memory on "cryptsetup luksSuspend". Without this fix, the thread keyring and the volume key in it remains. This second copy is only freed on "luksClose". "luksSuspend" neither knows about this copy nor has any way to remove it, so the key remains recoverable from RAM after a suspend that is documented to have wiped it. This fix should not introduce new security problems, as the code is anyway gated by CAP_SYS_ADMIN. The device-mapper core, not the calling task, is the legitimate owner of this long-lived file. Fixes: a28d893eb327 ("md: port block device access to file") Closes: https://gitlab.com/cryptsetup/cryptsetup/-/work_items/993 Link: https://www.speicherleck.de/iblech/cryptsetup-luksSuspend-issue-reproduction/ Signed-off-by: Ingo Blechschmidt Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Tested-by: Ondrej Kozina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dd73cc92a55d7b04051cd6202665cd1ae477b899 Author: Christian Brauner Date: Mon Jul 27 16:59:56 2026 -0400 cred: add kernel_cred() helper [ Upstream commit 4c7ceeb62d3330b6fb2b549ae833a92c0f481f3e ] Access kernel creds based off of init_task. This will let us avoid any direct access to init_cred. Link: https://patch.msgid.link/20251103-work-creds-init_cred-v1-2-cb3ec8711a6a@kernel.org Reviewed-by: Jens Axboe Signed-off-by: Christian Brauner Stable-dep-of: 981ccd97f715 ("dm: avoid leaking the caller's thread keyring via the table device file") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit af7a4c2caa7a191d6e7ed33903b69f9901874cd0 Author: Doruk Tan Ozturk Date: Mon Jul 27 15:50:59 2026 -0400 accel/amdxdna: reject command submission on devices without a submit op [ Upstream commit 38953513d7313992676d4136cd425cdb70c6278e ] amdxdna_cmd_submit() calls xdna->dev_info->ops->cmd_submit() unconditionally, but only aie2_dev_ops defines that callback. aie4_vf_ops (the AIE4 SR-IOV virtual function) does not, so a user AMDXDNA_EXEC_CMD ioctl on an AIE4 device reaches a NULL function-pointer call and oopses the kernel. AIE4 submits work through a mapped user queue and doorbell, not this ioctl path. Reject the submission early with -EOPNOTSUPP when the device provides no cmd_submit op, so the shared EXEC ioctl is a clean no-op on such devices. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Cc: stable@vger.kernel.org Found by 0sec automated security-research tooling (https://0sec.ai). Assisted-by: 0sec:claude-opus-4-8 Signed-off-by: Doruk Tan Ozturk Reviewed-by: Lizhi Hou Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260713173030.87541-3-doruk@0sec.ai Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 62dae36be7a62348fa0ac191f248317c2dd885a0 Author: Souvik Banerjee Date: Mon Jul 27 09:31:39 2026 -0400 ovl: use linked upper dentry in copy-up tmpfile [ Upstream commit e348eecd4d8fa8d18a5157ff59f7be1dc59c5928 ] ovl_copy_up_tmpfile() stores the disconnected O_TMPFILE dentry as the overlay's upper dentry reference via ovl_inode_update(). vfs_tmpfile() allocated this dentry via d_alloc(parentpath->dentry, &slash_name), so d_name is "/" and d_parent is c->workdir. Local upper filesystems (ext4, btrfs, xfs, ...) immediately rename it to "#" via d_mark_tmpfile() inside their ->tmpfile() op; FUSE and virtiofs do not, so both fields stay that way. Neither identifies the destination directory and filename where ovl_do_link() actually linked the file. When the upper filesystem implements ->d_revalidate() (e.g. FUSE or virtiofs), ovl_revalidate_real() calls it with the dentry's parent inode and a snapshot of d_name. The server tries to look up "/" inside c->workdir, fails, and overlayfs reports -ESTALE. This causes persistent ESTALE errors for any file that was copied up via the tmpfile path, breaking dpkg, apt, and other tools that do rename-over-existing on overlayfs with a FUSE/virtiofs upper. Before commit 6b52243f633e ("ovl: fold copy-up helpers into callers"), the tmpfile copy-up path used a dedicated helper ovl_link_tmpfile() that captured the linked destination dentry returned by ovl_do_link(): err = ovl_do_link(temp, udir, upper); ... if (!err) *newdentry = dget(upper); and published it via ovl_inode_update(d_inode(c->dentry), newdentry). The fold inlined ovl_do_link() into ovl_copy_up_tmpfile() but dropped the dget(upper) capture, and rewrote the publish line as ovl_inode_update(d_inode(c->dentry), dget(temp)) — where temp is the disconnected O_TMPFILE dentry. Fix by keeping a reference to the linked destination dentry after ovl_do_link() succeeds, and publishing that dentry at the existing ovl_inode_update() call site. The non-tmpfile/workdir path continues to publish the renamed temporary dentry. Reproducer: - Mount overlayfs with virtiofs (or a FUSE fs whose server advertises FUSE_TMPFILE) as upper - Run: dpkg -i - Observe: "error installing new file '...': Stale file handle" Fixes: 6b52243f633e ("ovl: fold copy-up helpers into callers") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Souvik Banerjee Link: https://patch.msgid.link/20260501232735.2610824-1-souvik@amlalabs.com Reviewed-by: Amir Goldstein Reviewed-by: Miklos Szeredi Signed-off-by: Christian Brauner (Amutable) [ adapted scoped credential and creation helpers to explicit credential, locking, lookup, and cleanup handling ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 043acb00e4edd4b9ffb9dd0e357482dcd9086486 Author: Koichiro Den Date: Sun Jul 26 08:47:41 2026 -0400 dmaengine: dw-edma-pcie: Reject devices without driver data [ Upstream commit 11d7cfe0c119691b2dafbb699bbca90258c678aa ] dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device. Fixes: 41aaff2a2ac0 ("dmaengine: Add Synopsys eDMA IP PCIe glue-logic") Cc: stable@vger.kernel.org Signed-off-by: Koichiro Den Reviewed-by: Frank Li Link: https://patch.msgid.link/20260521142153.2957432-3-den@valinux.co.jp Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 277a035cda47dd11cf6d0079e2276796923a81bd Author: Krzysztof Kozlowski Date: Sun Jul 26 08:47:40 2026 -0400 dmaengine: dw-edma: Fix confusing cleanup.h syntax [ Upstream commit f9ef8dedee34e2d7828d5a6a0643cd969aaa8437 ] Initializing automatic __free variables to NULL without need (e.g. branches with different allocations), followed by actual allocation is in contrary to explicit coding rules guiding cleanup.h: "Given that the "__free(...) = NULL" pattern for variables defined at the top of the function poses this potential interdependency problem the recommendation is to always define and assign variables in one statement and not group variable definitions at the top of the function when __free() is used." Code does not have a bug, but is less readable and uses discouraged coding practice, so fix that by moving declaration to the place of assignment. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251208020729.4654-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Vinod Koul Stable-dep-of: 11d7cfe0c119 ("dmaengine: dw-edma-pcie: Reject devices without driver data") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 19360c25135fccb6bbafbee49a5f66baf9a311af Author: Florian Fuchs Date: Sat Jul 25 06:54:40 2026 -0400 mtd: maps: vmu-flash: fix fault in unaligned fixup [ Upstream commit 79d1661502c6e4b6f626185cef72cf2fa78116e1 ] Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info. Fixes: 47a72688fae7 ("mtd: flash mapping support for Dreamcast VMU.") Cc: stable@vger.kernel.org Signed-off-by: Florian Fuchs Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b8271be34bce151597da5b5179e0648c281322a4 Author: Pratyush Yadav (Google) Date: Sat Jul 25 06:54:33 2026 -0400 kho: make sure scratch size is always aligned by CMA_MIN_ALIGNMENT_BYTES [ Upstream commit 0e39380a7316122e1b00012b3f3cd3e318b3e7d3 ] When using scratch_scale, the scratch sizes are rounded up to CMA_MIN_ALIGNMENT_BYTES since they will be released as MIGRATE_CMA. This is not done when using fixed scratch sizes via command line. This can result in user specifying a size which is not aligned, and thus kernel releasing a pageblock that is only partially scratch. Do the rounding up for both cases in scratch_size_update(). Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers") Cc: stable@kernel.org Signed-off-by: Pratyush Yadav (Google) Link: https://patch.msgid.link/20260519160554.2713361-1-pratyush@kernel.org Signed-off-by: Pasha Tatashin Signed-off-by: Mike Rapoport (Microsoft) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3d561f46fa78491bc2398db025c7292100668a48 Author: Muchun Song Date: Fri Jul 24 06:49:37 2026 -0400 mm/sparse-vmemmap: fix vmemmap accounting underflow [ Upstream commit c373f7f98e6ad591c85d40548cf8b6443be69311 ] Patch series "mm: Fix vmemmap optimization accounting and initialization", v8. The series fixes several bugs in vmemmap optimization, mainly around incorrect page accounting and memmap initialization in DAX and memory hotplug paths. It also fixes pageblock migratetype initialization and struct page initialization for ZONE_DEVICE compound pages. Patches 1-4 fix vmemmap accounting issues. Patch 1 fixes an accounting underflow in the section activation failure path by moving vmemmap page accounting into the lower-level allocation and freeing helpers. Patch 2 fixes incorrect altmap passing in the memory hotplug error path. Patch 3 passes pgmap through memory deactivation paths so the teardown side can determine whether vmemmap optimization was in effect. Patch 4 uses that information to account the optimized DAX vmemmap size correctly. Patches 5-6 fix initialization issues in mm/mm_init. One makes sure all pageblocks in ZONE_DEVICE compound pages get their migratetype initialized. The other fixes a case where DAX memory hotplug reuses an unoptimized early-section memmap while compound_nr_pages() still assumes vmemmap optimization, leaving tail struct pages uninitialized. This patch (of 6): In section_activate(), if populate_section_memmap() fails, the error handling path calls section_deactivate() to roll back the state. This causes a vmemmap accounting imbalance. Since commit c3576889d87b ("mm: fix accounting of memmap pages"), memmap pages are accounted for only after populate_section_memmap() succeeds. However, the failure path unconditionally calls section_deactivate(), which decreases the vmemmap count. Consequently, a failure in populate_section_memmap() leads to an accounting underflow, incorrectly reducing the system's tracked vmemmap usage. Fix this more thoroughly by moving all accounting calls into the lower level functions that actually perform the vmemmap allocation and freeing: - populate_section_memmap() accounts for newly allocated vmemmap pages - depopulate_section_memmap() unaccounts when vmemmap is freed This ensures proper accounting in all code paths, including error handling and early section cases. Link: https://lore.kernel.org/20260428081855.1249045-1-songmuchun@bytedance.com Link: https://lore.kernel.org/20260428081855.1249045-2-songmuchun@bytedance.com Fixes: c3576889d87b ("mm: fix accounting of memmap pages") Signed-off-by: Muchun Song Acked-by: Mike Rapoport (Microsoft) Acked-by: Oscar Salvador Acked-by: David Hildenbrand (Arm) Acked-by: Liam R. Howlett Cc: "Aneesh Kumar K.V" Cc: Joao Martins Cc: Lorenzo Stoakes Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Michal Hocko Cc: Nicholas Piggin Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8af652cd994606328bb807a085c518636e39302c Author: Tanmay Shah Date: Thu Jul 23 15:58:58 2026 -0400 remoteproc: xlnx: Check remote core state [ Upstream commit a48df51d23138388900995add2854cda4aa68e55 ] The remote state is set to RPROC_DETACHED if the resource table is found in the memory. However, this can be wrong if the remote is not started, but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call to the firmware to request the state of the RPU node. If the RPU is actually out of reset and running, only then move the remote state to RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE. Signed-off-by: Tanmay Shah Fixes: bca4b02ef92e ("remoteproc: xlnx: Add attach detach support") Reviewed-by: Beleswar Padhi Acked-by: Michal Simek Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260428221855.313752-1-tanmay.shah@amd.com Signed-off-by: Mathieu Poirier [ replaced the unavailable zynqmp_pm_get_node_status() helper with a direct zynqmp_pm_invoke_fn() call and exported it for modular builds. ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6fc1919a6f2ed541484dd1f6cd93374044f8fd3d Author: Terry Bowman Date: Thu Jul 23 14:28:06 2026 -0400 cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size [ Upstream commit c268f949e219f9e179558e836f457f6c5fbec416 ] The CXL r4.0 8.2.4.17.7 RAS Capability Structure has total length 0x58 bytes (CXL_RAS_CAPABILITY_LENGTH); the Header Log occupies the trailing 64 bytes at offset 0x18. CXL_HEADERLOG_SIZE was defined as SZ_512, eight times the actual on-device size. header_log_copy() reads CXL_HEADERLOG_SIZE_U32 (128) dwords from the RAS capability iomap, overrunning the 88-byte mapping by 448 bytes. The cxl_aer_uncorrectable_error trace event memcpy()s CXL_HEADERLOG_SIZE (512) bytes from its source. For the CPER caller the source is struct cxl_ras_capability_regs::header_log[16] (64 bytes) embedded in a stack-local cxl_cper_prot_err_work_data, so the memcpy reads 448 bytes of kernel stack into the trace event ring buffer where userspace can read it via tracefs. Set CXL_HEADERLOG_SIZE to 64 and derive CXL_HEADERLOG_SIZE_U32 from it, bringing all iomap readers into agreement on 16 dwords. Userspace tools such as rasdaemon have grown a dependency on the buggy 512-byte (128 u32) header_log layout in the cxl_aer_uncorrectable_error trace event. Add CXL_HEADERLOG_TRACE_SIZE_U32 = 128 and use it for the trace event __array and its memcpy to preserve that ABI. Both callers now pass a zero-filled u32[CXL_HEADERLOG_TRACE_SIZE_U32] staging buffer with only the first CXL_HEADERLOG_SIZE_U32 (16) entries populated from hardware; the remaining 112 u32s are zero-padded, keeping the 512-byte trace ring buffer layout intact. [ dj: Replaced 64 with SZ_64 per RichardC ] Fixes: 36f257e3b0ba ("acpi/ghes, cxl/pci: Process CXL CPER Protocol Errors") Fixes: 2905cb5236cb ("cxl/pci: Add (hopeful) error handling support") Cc: stable@vger.kernel.org Reported-by: Sashiko Signed-off-by: Terry Bowman Reviewed-by: Alison Schofield Reviewed-by: Dave Jiang Reviewed-by: Ben Cheatham Reviewed-by: Richard Cheng Link: https://patch.msgid.link/20260605180610.2249458-1-terry.bowman@amd.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 89b2ae039d1885781610a814df18c0264c339bbb Author: Dave Jiang Date: Thu Jul 23 14:28:05 2026 -0400 cxl/pci: Remove CXL VH handling in CONFIG_PCIEAER_CXL conditional blocks from core/pci.c [ Upstream commit 7ff8b1d60881c5f97b5ae426e14d2822917d3b69 ] Create new config CONFIG_CXL_RAS and put all CXL RAS items behind the config. The config will depend on CPER and PCIE AER to build. Move the related VH RAS code from core/pci.c to core/ras.c. Restricted CXL host (RCH) RAS functions will be moved in a future patch. Cc: Robert Richter Reviewed-by: Joshua Hahn Reviewed-by: Jonathan Cameron Signed-off-by: Dave Jiang Reviewed-by: Alison Schofield Co-developed-by: Terry Bowman Signed-off-by: Terry Bowman Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260114182055.46029-8-terry.bowman@amd.com Signed-off-by: Dan Williams Signed-off-by: Dave Jiang Stable-dep-of: c268f949e219 ("cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit eeab775069920a8e0d9d8b28b65ef7b772ccdef0 Author: Terry Bowman Date: Thu Jul 23 14:28:04 2026 -0400 cxl/pci: Remove unnecessary CXL RCH handling helper functions [ Upstream commit eb78ef4d6f0e51243c1ee117f801dbc503e886ab ] cxl_handle_rdport_cor_ras() and cxl_handle_rdport_ras() are specific to Restricted CXL Host (RCH) handling. Improve readability and maintainability by replacing these and instead using the common cxl_handle_cor_ras() and cxl_handle_ras() functions. Signed-off-by: Terry Bowman Reviewed-by: Alejandro Lucero Reviewed-by: Dave Jiang Reviewed-by: Jonathan Cameron Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260114182055.46029-6-terry.bowman@amd.com Signed-off-by: Dan Williams Signed-off-by: Dave Jiang Stable-dep-of: c268f949e219 ("cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a64661dccb2eb349cc4cc70930e560254b2dfa5d Author: Terry Bowman Date: Thu Jul 23 14:28:03 2026 -0400 cxl/pci: Remove unnecessary CXL Endpoint handling helper functions [ Upstream commit ca3d1a53e62093d17436abd447463da9c0f4e56b ] The CXL driver's cxl_handle_endpoint_cor_ras()/cxl_handle_endpoint_ras() are unnecessary helper functions used only for Endpoints. Remove these functions as they are not common for all CXL devices and do not provide value for EP handling. Rename __cxl_handle_ras to cxl_handle_ras() and __cxl_handle_cor_ras() to cxl_handle_cor_ras(). Signed-off-by: Terry Bowman Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Jonathan Cameron Reviewed-by: Dave Jiang Tested-by: Joshua Hahn Reviewed-by: Dan Williams Link: https://patch.msgid.link/20260114182055.46029-5-terry.bowman@amd.com Signed-off-by: Dan Williams Signed-off-by: Dave Jiang Stable-dep-of: c268f949e219 ("cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5d964cb2b7bc852c986d7ad669e86c20ad635d62 Author: Chuck Lever Date: Thu Jul 23 14:19:10 2026 -0400 SUNRPC: Return an error from xdr_buf_to_bvec() on overflow [ Upstream commit 18c1cc69886192e33536498289d26dba6894e3d5 ] xdr_buf_to_bvec() returns a slot count even when the caller's bvec budget is exhausted partway through the xdr_buf. Callers feed that count into iov_iter_bvec() and continue as if the conversion had succeeded, silently sending or writing fewer bytes than the data length declares. For an NFS WRITE the server reports the truncated transfer to the client as full success. The overflow represents an internal invariant violation: a higher layer reserved a bvec budget too small for the xdr_buf it then asked the encoder to convert. That is a server-side fault, not a media I/O failure and not a malformed client argument. Change xdr_buf_to_bvec() to return a signed int and have the overflow label return -ESERVERFAULT. Update the three callers to detect the negative return and fail the request: nfsd_vfs_write() folds the error into host_err, which nfserrno() translates to nfserr_serverfault for the WRITE reply; svc_udp_sendto() and svc_tcp_sendmsg() propagate the error out of the send path. Reported-by: Chris Mason Fixes: 2eb2b9358181 ("SUNRPC: Convert svc_tcp_sendmsg to use bio_vecs directly") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b50b2cb87e7ac723ba01793d7ce1e64594fc5403 Author: Chuck Lever Date: Thu Jul 23 14:19:08 2026 -0400 SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists [ Upstream commit e9be933959b581effd426f93b86654f5fbf0c574 ] The crypto/krb5 library accepts data in scatterlist form, but the GSS-API layer presents RPC payloads as struct xdr_buf. Bridge that gap with a pair of helper functions: xdr_buf_to_sg() - populate a caller-supplied scatterlist array from a byte range xdr_buf_to_sg_alloc() - populate a caller-supplied inline scatterlist, chaining to a heap- allocated overflow for large payloads The inline array (typically stack-allocated at eight entries) covers the common case of small RPCs with no heap allocation on the encrypt/decrypt path. Only buffers spanning many pages incur a kmalloc for the chained extension. The segment-walking logic follows the same head, page array, tail traversal as xdr_process_buf(), but populates a scatterlist directly rather than invoking a per-segment callback. sg_next() traversal makes the walker safe for chained scatterlists. Once subsequent patches reroute all per-message crypto operations through crypto/krb5, xdr_process_buf() loses its last callers and is removed. Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Jeff Layton Acked-by: Anna Schumaker Signed-off-by: Chuck Lever Stable-dep-of: 18c1cc698861 ("SUNRPC: Return an error from xdr_buf_to_bvec() on overflow") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a112b91dd63491ceb2ca0e7af758eb3055cebc96 Author: Jeff Layton Date: Thu Jul 23 14:19:07 2026 -0400 sunrpc: allocate a separate bvec array for socket sends [ Upstream commit 6b3b697d65d46a0f640216a3f6c72856c159c567 ] svc_tcp_sendmsg() calls xdr_buf_to_bvec() with the second slot of rq_bvec as the start, but doesn't reduce the array length by one, which could lead to an array overrun. Also, rq_bvec is always rq_maxpages in length, which can be too short in some cases, since the TCP record marker consumes a slot. Fix both problems by adding a separate bvec array to the svc_sock that is specifically for sending. For TCP, make this array one slot longer than rq_maxpages, to account for the record marker. For UDP, only allocate as large an array as we need since it's limited to 64k of payload. Signed-off-by: Jeff Layton Reviewed-by: NeilBrown Signed-off-by: Chuck Lever Stable-dep-of: 18c1cc698861 ("SUNRPC: Return an error from xdr_buf_to_bvec() on overflow") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3120f21df3fb0460f61c9f2f43545403ec768cc5 Author: Mike Snitzer Date: Thu Jul 23 14:19:06 2026 -0400 NFSD: pass nfsd_file to nfsd_iter_read() [ Upstream commit 803bc849f0039291f546ba0e2237faebeb5c073e ] Prepare for nfsd_iter_read() to use the DIO alignment stored in nfsd_file by passing the nfsd_file to nfsd_iter_read() rather than just the file which is associaed with the nfsd_file. This means nfsd4_encode_readv() now also needs the nfsd_file rather than the file. Instead of changing the file arg to be the nfsd_file, we discard the file arg as the nfsd_file (and indeed the file) is already available via the "read" argument. Signed-off-by: Mike Snitzer Reviewed-by: Jeff Layton Reviewed-by: NeilBrown Reviewed-by: Christoph Hellwig Signed-off-by: Chuck Lever Stable-dep-of: 18c1cc698861 ("SUNRPC: Return an error from xdr_buf_to_bvec() on overflow") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6876f767b04900c3c8552e64509c4c597f63f557 Author: Claudiu Beznea Date: Thu Jul 23 13:03:25 2026 -0400 pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP [ Upstream commit c1492da3939c89372929e062d731f328f7693f1e ] The pinctrl and GPIO core code make exceptions for the -ENOTSUPP error code. One such example is gpio_set_config_with_argument_optional(), which returns success when gpio_set_config_with_argument() returns -ENOTSUPP, but reports failure for all other error codes. Returning -EOPNOTSUPP from the pinctrl driver on the unsupported pinctrl operation may lead to boot failures when pinctrl drivers implements struct gpio_chip::set_config, the system uses GPIO hogs, and the struct gpio_chip::set_config implementation returns -EOPNOTSUPP for the unsupported operations. Return -ENOTSUPP for the unsupported pinctrl operation. Fixes: 560c633d378a ("pinctrl: renesas: rzg2l: Drop oen_read and oen_write callbacks") Fixes: c4c4637eb57f ("pinctrl: renesas: Add RZ/G2L pin and gpio controller driver") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea Reviewed-by: Bartosz Golaszewski Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Link: https://patch.msgid.link/20260515124008.2947838-2-claudiu.beznea@kernel.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7185c5262435b93e5eeffa647008992256b9c51a Author: Arunpravin Paneer Selvam Date: Thu Jul 23 10:19:30 2026 -0400 gpu/buddy: bail out of try_harder when alignment cannot be honoured [ Upstream commit 56bc6384314fb9ae98975fb2af8b143097ede3dc ] The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew). Fixes: 0a1844bf0b53 ("drm/buddy: Improve contiguous memory allocation") Suggested-by: Christian König Cc: Matthew Auld Cc: Christian König Cc: Timur Kristóf Cc: stable@vger.kernel.org Reviewed-by: Matthew Auld Tested-by: John Olender Signed-off-by: Arunpravin Paneer Selvam Link: https://patch.msgid.link/20260709131050.1022759-1-Arunpravin.PaneerSelvam@amd.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9634fd144cdc115786ff92da45ae2108b674d5f7 Author: Dave Airlie Date: Fri Feb 6 11:44:09 2026 +1000 drm: drop lib from header search path. commit ee8bfb15d02dddb554ad4bdd6c44297f19556563 upstream. This was leftover from when I dropped it in 4a9671a03f2b ("gpu: Move DRM buddy allocator one level up (part one)") Signed-off-by: Dave Airlie Cc: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 65677f7a20c48cf9ed02c56db389cc327d2b61b2 Author: Joel Fernandes Date: Thu Jul 23 10:19:29 2026 -0400 gpu: Move DRM buddy allocator one level up (part two) [ Upstream commit ba110db8e1bc206c13fd7d985e79b033f53bfdea ] Move the DRM buddy allocator one level up so that it can be used by GPU drivers (example, nova-core) that have usecases other than DRM (such as VFIO vGPU support). Modify the API, structures and Kconfigs to use "gpu_buddy" terminology. Adapt the drivers and tests to use the new API. The commit cannot be split due to bisectability, however no functional change is intended. Verified by running K-UNIT tests and build tested various configurations. Signed-off-by: Joel Fernandes Reviewed-by: Dave Airlie [airlied: I've split this into two so git can find copies easier. I've also just nuked drm_random library, that stuff needs to be done elsewhere and only the buddy tests seem to be using it]. Signed-off-by: Dave Airlie Stable-dep-of: 56bc6384314f ("gpu/buddy: bail out of try_harder when alignment cannot be honoured") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 09755dc62b026076b1d47f83489eb0547c8135e0 Author: Pablo Neira Ayuso Date: Thu Jul 23 10:18:40 2026 -0400 netfilter: nf_conntrack_sip: validate skb_dst() before accessing it [ Upstream commit e5e24a365a5e024efef63cc49abb345fbd4852c5 ] tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash. Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action") Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct") Cc: stable@vger.kernel.org Reported-by: Ren Wei Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a1a94a00b88448e8832976f5008c50afc83c59b3 Author: Florian Westphal Date: Thu Jul 23 10:18:39 2026 -0400 netfilter: nf_conntrack_sip: remove net variable shadowing [ Upstream commit 7970d6aaf710db166de98c5356a260089896fae5 ] net is already set, derived from nf_conn. I don't see how the device could be living in a different netns than the conntrack entry. Remove the extra variable and re-use existing one. Signed-off-by: Florian Westphal Stable-dep-of: e5e24a365a5e ("netfilter: nf_conntrack_sip: validate skb_dst() before accessing it") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d01c913febead04a01a5f3a6374d1f45504dc523 Author: Theodor Arsenij Larionov-Trichkine Date: Thu Jul 23 10:18:35 2026 -0400 netfilter: nft_fib: reject fib expression on the netdev egress hook [ Upstream commit d07955dd34ecae17d35d8c7d0a273a3fba653a8c ] A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks. Fixes: 42df6e1d221d ("netfilter: Introduce egress hook") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/netfilter-devel/ajxsjcDOnwllMfoR@strlen.de/ Signed-off-by: Theodor Arsenij Larionov-Trichkine Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit beeda5bf78577862e2b0c1d70fe1d6f9be542fc8 Author: Florian Westphal Date: Thu Jul 23 10:18:34 2026 -0400 netfilter: nf_tables: remove register tracking infrastructure [ Upstream commit 6b94d081f81dd524626f7aab2b98a9de335edb72 ] This facility was disabled in commit 9e539c5b6d9c ("netfilter: nf_tables: disable expression reduction infra"), because not all nft_exprs guarantee they will update the destination register: some may set NFT_BREAK instead to cancel evaluation of the rule. This has been dead code ever since. There are no plans to salvage this at this time, so remove this. Signed-off-by: Florian Westphal Link: https://patch.msgid.link/20260224205048.4718-10-fw@strlen.de Signed-off-by: Jakub Kicinski Stable-dep-of: d07955dd34ec ("netfilter: nft_fib: reject fib expression on the netdev egress hook") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1de827e24d0adeff943acdd50e86122040bf3238 Author: Abel Vesa Date: Wed Jul 22 14:00:48 2026 -0400 arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers [ Upstream commit c17e220946675232d383620ed9cff6685735ec48 ] According to internal documentation, the corners specific for each rate from the DP link clock are: - LOWSVS_D1 -> 19.2 MHz - LOWSVS -> 270 MHz - SVS -> 540 MHz (594 MHz in case of DP3) - SVS_L1 -> 594 MHz - NOM -> 810 MHz - NOM_L1 -> 810 MHz - TURBO -> 810 MHz So fix all tables for each of the four controllers according to the documentation, but since DP0 through DP2 have the same entries in their tables, lets drop the DP1 and DP2 and have all of them share the DP0 table instead. However keep a separate table for the DP3 as it is different for the SVS, compared to the rest of the controllers. The 19.2 MHz @ LOWSVS_D1 isn't needed as it's not an actual working frequency and the controller will never select it. So remove it. Cc: stable@vger.kernel.org # v6.9+ Fixes: 1940c25eaa63 ("arm64: dts: qcom: x1e80100: Add display nodes") Suggested-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20260323-hamoa-fix-dp3-opp-table-v3-1-a823776bd1b0@oss.qualcomm.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0d810ff7a6f655fcda3330b8199e940f4ad13211 Author: Dmitry Baryshkov Date: Wed Jul 22 14:00:47 2026 -0400 arm64: dts: qcom: correct RBR opp entry [ Upstream commit a5c21b9bd5f531e50141b0484faabb707b92f1e2 ] DisplayPort Reduced Bit Rate uses link rate of 1.62 Gbps, the main link clock should be 162 MHz. Having the incorrect frequency (160 MHz) in the OPP table will result in selecting wrong link frequency. Correct the entry in the OPP table. Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260304-msm-fix-rbr-v1-1-b9eba986eaef@oss.qualcomm.com Signed-off-by: Bjorn Andersson Stable-dep-of: c17e22094667 ("arm64: dts: qcom: hamoa: Fix OPP tables for all DisplayPort controllers") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 690fb82c4122f8c2656fa4f842275132771b68b9 Author: Jason Wang Date: Wed Jul 22 12:07:31 2026 -0400 VDUSE: avoid leaking information to userspace [ Upstream commit 9c1523803445ee0348f62b77793266dd981596e0 ] The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace. Fixes: 8c773d53fb7b ("vduse: Implement an MMU-based software IOTLB") Cc: stable@vger.kernel.org Signed-off-by: Jason Wang Reviewed-by: Xie Yongji Reviewed-by: Eugenio Pérez Signed-off-by: Michael S. Tsirkin Message-ID: <20260130050750.4050-1-jasowang@redhat.com> Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7764e9c727d58fcdcd2944da43d4cb300d112535 Author: Eugenio Pérez Date: Wed Jul 22 12:07:30 2026 -0400 vduse: take out allocations from vduse_dev_alloc_coherent [ Upstream commit 489d76520612abf9a4ede4344349105406c91a73 ] The function vduse_dev_alloc_coherent will be called under rwlock in next patches. Make it out of the lock to avoid increasing its fail rate. Acked-by: Jason Wang Signed-off-by: Eugenio Pérez Signed-off-by: Michael S. Tsirkin Message-Id: <20260119143306.1818855-10-eperezma@redhat.com> Stable-dep-of: 9c1523803445 ("VDUSE: avoid leaking information to userspace") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit db5c554b36d50ea2eb1cacd18116572e78e8c2bf Author: Eugenio Pérez Date: Wed Jul 22 12:07:29 2026 -0400 vduse: remove unused vaddr parameter of vduse_domain_free_coherent [ Upstream commit 766e1749c0ef6a09651be9b8a8283d508c322b58 ] We will modify the function in next patches so let's clean it first. Signed-off-by: Eugenio Pérez Signed-off-by: Michael S. Tsirkin Message-Id: <20260119143306.1818855-9-eperezma@redhat.com> Stable-dep-of: 9c1523803445 ("VDUSE: avoid leaking information to userspace") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 82e48ad2a13265a4a7d92278ac28edfdc03b95cd Author: Eugenio Pérez Date: Wed Jul 22 12:07:28 2026 -0400 vduse: return internal vq group struct as map token [ Upstream commit 02e3f7ffe2906033da73b7c7ea8180b131d0cdbc ] Return the internal struct that represents the vq group as virtqueue map token, instead of the device. This allows the map functions to access the information per group. At this moment all the virtqueues share the same vq group, that only can point to ASID 0. This change prepares the infrastructure for actual per-group address space handling Acked-by: Jason Wang Signed-off-by: Eugenio Pérez Signed-off-by: Michael S. Tsirkin Message-Id: <20260119143306.1818855-5-eperezma@redhat.com> Stable-dep-of: 9c1523803445 ("VDUSE: avoid leaking information to userspace") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b1f38c3ec620a37007dff25fc6db7db592558a72 Author: Darrick J. Wong Date: Wed Jul 22 07:33:53 2026 -0400 xfs: don't replace the wrong part of the cow fork [ Upstream commit a1caeeadbf57ff86dfc3454398c46de86056a74e ] LOLLM points out that xfs_iext_lookup_extent can return a @got where got->br_startoff < startoff. In this case, xrep_cow_replace_range replaces the entire mapping instead of just the part that had been marked bad in the bitmap, but advances the bitmap cursor in xrep_cow_replace by the amount replaced. As a result, we fail to replace the end of the bad range, and replace part of the good range. Fix this by rewriting the replace method to handle replacing the middle of a cow fork mapping. This we do by returning both the current mapping as @got, and the subset of the mapping that we want to replace as @rep, using @rep to store the results of the new allocation, and comparing @rep to @got to figure out the exact transformations needed. Cc: stable@vger.kernel.org # v6.8 Fixes: dbbdbd0086320a ("xfs: repair problems in CoW forks") Signed-off-by: "Darrick J. Wong" Assisted-by: LOLLM # finding obvious bugs Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3bca70235a706de76fe9a81defd37d987062c686 Author: Joanne Koong Date: Wed Jul 22 07:33:50 2026 -0400 fuse-uring: fix race between registration and connection abortion [ Upstream commit 952b5d36f6a298f57c52a59e72076c69386a8aaf ] This fixes this race: - thread a: io_uring_enter -> register sqe -> fuse_uring_create_ring_ent -> allocate ent but doesn't grab queue_ref yet - thread b: fuse_conn_destroy() -> fuse_chan_abort() -> fuse_uring_abort() is a no-op due to queue ref being 0 - thread a: grabs the queue_ref, queue_ref is now 1, rest of fuse_uring_do_register() logic executes - thread b: fuse_chan_abort() returns, fuse_chan_wait_aborted() now runs and calls "wait_event(ring->stop_waitq, atomic_read(&ring->queue_refs) == 0);" The abort/unmount thread will hang indefinitely in unkillable state as nothing will decrement queue_refs or wake stop_waitq, and the ring, queue, and ent are leaked. Fix this by checking fch->connected under fch->lock after the created ent has grabbed a ref count on the queue. This ensures that in the scenario above, it is guaranteed that we either release the queue ref and wake up stop_waitq (in case fuse_chan_wait_aborted() is already waiting) in fuse_uring_do_register() when we detect !fch->connected, or if the connection is aborted after the check, it is guaranteed that the async teardown worker will be running in the background cleaning up ents and decrementing the ent's ref on the queue, which will unblock the eventual queue and ring teardown. 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 [ changed fch->lock/fch->connected references to fc->lock/fc->connected since struct fuse_chan does not exist in this tree ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 40879c39d6740f3dddfb52b5d6ba7fb8cceb84d8 Author: Ricardo Robaina Date: Tue Jul 21 15:36:13 2026 -0400 audit: fix recursive locking deadlock in audit_dupe_exe() [ Upstream commit 81905b5acbe77284734438df3fbec1158e6429a3 ] A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resolution entirely, safely avoiding the recursive lock. Furthermore, it explicitly allows duplicate fsnotify marks (allow_dups = 1) during the rename update, allowing the new rule's mark to safely coexist with the old rule's mark until the old rule is freed. P.S.: This issue was identified and reproduced during a comprehensive code coverage analysis of the audit subsystem. The full report is available at the link below: https://people.redhat.com/rrobaina/audit-code-coverage-analysis.pdf P.P.S: With the permission of both Ricardo and Nathan, I've squashed a fixup patch from Nathan that addresses a compile time error when CONFIG_AUDITSYSCALL=n. Cc: stable@kernel.org Fixes: 34d99af52ad4 ("audit: implement audit by executable") Acked-by: Waiman Long Acked-by: Richard Guy Briggs Signed-off-by: Nathan Chancellor Signed-off-by: Ricardo Robaina [PM: move link metadata into the msg, apply fix from NC] Signed-off-by: Paul Moore Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 91b64f0be416358febc3f82fe819b8922a1db05e Author: Ricardo Robaina Date: Tue Jul 21 15:36:12 2026 -0400 audit: use 'unsigned int' instead of 'unsigned' [ Upstream commit 8b226771014beab1292081151a99530886ce54b4 ] Address checkpatch.pl warning below, across the audit subsystem: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' Minor cleanup, no functional changes. Signed-off-by: Ricardo Robaina Signed-off-by: Paul Moore Stable-dep-of: 81905b5acbe7 ("audit: fix recursive locking deadlock in audit_dupe_exe()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit eef6914f2b456f76358e07396505f179a8d279d4 Author: Jeff Layton Date: Tue Jul 21 15:36:11 2026 -0400 audit: widen ino fields to u64 [ Upstream commit 125dfa218134df7cc112667e92984de9d8cd0bf6 ] inode->i_ino is being widened from unsigned long to u64. The audit subsystem uses unsigned long ino in struct fields, function parameters, and local variables that store inode numbers from arbitrary filesystems. On 32-bit platforms this truncates inode numbers that exceed 32 bits, which will cause incorrect audit log entries and broken watch/mark comparisons. Widen all audit ino fields, parameters, and locals to u64, and update the inode format string from %lu to %llu to match. Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260304-iino-u64-v3-2-2257ad83d372@kernel.org Acked-by: Paul Moore Signed-off-by: Christian Brauner Stable-dep-of: 81905b5acbe7 ("audit: fix recursive locking deadlock in audit_dupe_exe()") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c5772ced573ea4be02b6a95a0b7d8998ae8a6830 Author: Mickaël Salaün Date: Tue Jul 21 15:36:01 2026 -0400 landlock: Account all audit data allocations to user space [ Upstream commit b232bd12789fa57405b5092f28788be97aae9999 ] Mark the kzalloc_flex() of struct landlock_details with GFP_KERNEL_ACCOUNT so the allocation is charged to the calling task, like the other Landlock per-domain allocations which have used GFP_KERNEL_ACCOUNT forever. Every property of landlock_details is caller-attributable: allocated by landlock_restrict_self(2), owned by the caller's landlock_hierarchy, contents are the caller's pid, uid, comm, and exe_path, lifetime bounded by the caller's domain. While the caller may not know nor control the size of this allocation (i.e. exe_path), this data should still be accounted for it. The deciding factor is whether userspace can trigger the allocation, not whether the size of the data is known nor controlled by the caller. This aligns with the kmemcg accounting policy established by commit 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg"). No new failure modes: the hierarchy and ruleset are allocated before details and are already accounted, so landlock_restrict_self(2) already returns -ENOMEM under memcg pressure. This change widens that existing failure window slightly; it does not introduce a new error code. Cc: Günther Noack Cc: Paul Moore Cc: stable@vger.kernel.org Fixes: 1d636984e088 ("landlock: Add AUDIT_LANDLOCK_DOMAIN and log domain status") Link: https://patch.msgid.link/20260513180309.165840-1-mic@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a95b62759f3b9ea0f076e958fe28e2edabc07cb2 Author: Mickaël Salaün Date: Tue Jul 21 15:36:00 2026 -0400 landlock: Fix formatting [ Upstream commit 405ca72dc589dd746e5ee5378bb9d9ee7f844010 ] Auto-format with clang-format -i security/landlock/*.[ch] Cc: Günther Noack Cc: Kees Cook Fixes: 69050f8d6d07 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types") Reviewed-by: Günther Noack Link: https://lore.kernel.org/r/20260303173632.88040-1-mic@digikod.net Signed-off-by: Mickaël Salaün Stable-dep-of: b232bd12789f ("landlock: Account all audit data allocations to user space") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 682a0066dde052d1841bcc614c3de917ac836be9 Author: Harry Wentland Date: Tue Jul 28 23:33:40 2026 -0700 drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources commit 76a2db58e95e328007043f54ac3c7336ccbee440 upstream. dcn32_update_clocks_update_dtb_dto() and its dcn35 counterpart reprogram the DTB DTO of every timing generator in the context whenever the DTBCLK reference changes, passing a zeroed pixel rate and never setting is_hdmi. Both dccg set_dtbclk_dto() implementations treat a zero pixel rate as a disable request. On dcn32 that branch drives PIPE_DTO_SRC_SEL to the DP DTO source, so a timing generator actively scanning out an HDMI stream has its pixel rate source re-muxed out from under the live raster and the OTG stops on the spot. On dcn35 it clears DTBCLK_DTO_ENABLE and restores DTBCLK_Pn clock gating, which does the same to a live 128b/132b stream. Two displays where only one runs a 128b/132b link hit this reliably. is_dtbclk_required() holds the DTBCLK reference high while both are active, and the moment the 128b/132b stream is torn down (compositor switch, display disable, hot-unplug) the next safe_to_lower pass drops the reference to the lowest DPM level and the DTO walk freezes the surviving screen. On Navi31 the DAL mailbox then goes deaf on the DISPCLK hard-min that follows the walk in dcn32_update_clocks(), stranding both SMU mailboxes until reboot. Set is_hdmi for HDMI and DVI signals so the disable path leaves the pixel rate source selection on the HDMI path, and pass the real pixel rate for 128b/132b streams so a reference change rescales their DTO instead of disabling it. Fixes: 128c1ca0303f ("drm/amd/display: Update DTBCLK for DCN32") Fixes: 8774029f76b9 ("drm/amd/display: Add DCN35 CLK_MGR") Signed-off-by: Harry Wentland Reviewed-by: Fangzhi Zuo Tested-by: Dan Wheeler Signed-off-by: Alex Deucher [ mschwartz: dcn32 and dcn35 clk_mgr hunks only. The rest is HDMI FRL enablement, absent before 7.2, so the FRL conditions and the req_audio_dtbclk_khz assignment they guard are dropped and the FRL-centric changelog is rewritten. Added the pipe_ctx->stream check the new dereferences need. ] Signed-off-by: Matthew Schwartz Signed-off-by: Sasha Levin commit 81ea8e8221853950c47dac7164f27c63a96f8f86 Author: Eric Biggers Date: Wed Jul 29 08:19:05 2026 -0700 fscrypt: Avoid dynamic allocation in fscrypt_get_devices() commit 6fe4e4b8259e1330945b5f3c9476e08473b8e0e8 upstream. When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.) Fixes: 22e9947a4b2b ("fscrypt: stop holding extra request_queue references") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260713023708.9245-1-ebiggers%40kernel.org Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260719055602.78828-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit 337022d9dfac441c3b35e4455a51aa981996e02e Author: Namjae Jeon Date: Thu Jul 30 03:00:29 2026 +0800 ksmbd: validate ACE size against SID sub-authorities commit 5152c6d49e3fd4e9f2e857c57527aead752f1f87 upstream. set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths. Reported-by: LocalHost Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Wentao Guan Signed-off-by: Sasha Levin commit f1eba60db813ec28732bf18b5f0a67ebac9c3100 Author: Namjae Jeon Date: Thu Jul 30 03:00:26 2026 +0800 ksmbd: bound DACL dedup walk to copied ACEs commit 58d97fcd0bf1aee694e244cc28635b9df95b543b upstream. set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original "input DACL had NT ACEs" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL. Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Wentao Guan Signed-off-by: Sasha Levin commit 847ecd4eb3c117c3d2f13f1e7ab506543aad8183 Author: Wentao Guan Date: Thu Jul 30 03:00:24 2026 +0800 ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL commit bbf0a8e931204ecdab494a88d43b0a24a04285c5 upstream. check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c). Fixes: 299f962c0b02 ("ksmbd: use check_add_overflow() to prevent u16 DACL size overflow") Assisted-by: atomcode:glm-5.2 Assisted-by: Codex:gpt-5.5 Cc: stable@vger.kernel.org Signed-off-by: Wentao Guan Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b6d3cc6a524416dfdb2b47e4bba2e7e20011d056 Author: Haofeng Li Date: Thu Jul 30 03:00:22 2026 +0800 ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl commit 47f0b34f6bc98ed85bfdc293e8f3e432ec24958d upstream. set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl(). Signed-off-by: Haofeng Li Reviewed-by: ChenXiaoSong Suggested-by: Namjae Jeon Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Wentao Guan Signed-off-by: Sasha Levin commit 17e6b8c4319fafda04fc5bfcdcea4c0dda5b59df Author: Youssef Samir Date: Wed Jul 29 17:02:11 2026 +0200 net: qrtr: ns: Raise node count limit to 512 commit ff194cffd586cbd4cc49eccb002c65f2a902a277 upstream. The current node limit of 64 breaks the functionality for a number of AI200 deployments that have up to 384 nodes. Raise the limit to 512. Fixes: 27d5e84e810b ("net: qrtr: ns: Limit the total number of nodes") Cc: stable@vger.kernel.org Signed-off-by: Youssef Samir Link: https://patch.msgid.link/20260713145901.212396-1-youssef.abdulrahman@oss.qualcomm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7dd26adf7e7d482af524e3a0cca4a81ef7c159d0 Author: Ming Lei Date: Wed Jul 29 09:48:06 2026 -0500 ublk: wait on ublk_dev_ready() instead of ub->completion commit 432a9b2780c0a01caf547bd1fc2fcf28aeb8d173 upstream. ub->completion is only re-armed by a successful START_USER_RECOVERY. If the ublk server sends END_USER_RECOVERY without one - e.g. its START failed with -EBUSY and the error was ignored - the wait is satisfied by the stale completion of the previous recovery cycle, and the device is marked LIVE and the requeue list kicked while the FETCH stream is still running and ubq->canceling is still set. The kick redispatches a previously requeued request, __ublk_queue_rq_common() sees ->canceling and parks it again via __ublk_abort_rq(), and after the last FETCH clears ->canceling nothing ever kicks the requeue list again: the request is stranded there while holding its tag. If it is the flush machinery's flush_rq, every subsequent fsync piles up in uninterruptible sleep and teardown hangs on tag draining. This matches a report of a lost PREFLUSH with ext4 on top of ublk after daemon crash recovery. ub->completion is an edge-triggered latch used as a proxy for the level condition "every queue has fetched all I/O commands", which can regress (F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop it and wait on the real condition instead: the new helper ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then re-checks it under ub->mutex, waiting again on regression, and returns with the mutex held and readiness guaranteed. Readiness becomes true in the same ub->mutex critical section that clears the last queue's ->canceling, so END_USER_RECOVERY marks the device LIVE and kicks the requeue list strictly after ->canceling clears. The wait stays interruptible, so a server whose daemon died can still be signalled out. For ublk_ctrl_start_dev() this replaces the fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting until the device is ready again. Reported-by: George Salisbury Fixes: 728cbac5fe21 ("ublk: move device reset into ublk_ch_release()") Cc: stable@vger.kernel.org Signed-off-by: Ming Lei Link: https://patch.msgid.link/20260719134540.120269-1-tom.leiming@gmail.com Signed-off-by: Jens Axboe [ 6.18.y tracks readiness per fetched I/O command in ->nr_io_ready rather than per queue in ->nr_queue_ready, so wait and wake on that counter; ->canceling is cleared by ublk_reset_io_flags(), which stays in ublk_mark_io_ready(). UBLK_F_BATCH_IO does not exist here, so ublk_ctrl_start_dev() has no F_BATCH readiness re-check to replace, and readiness can only regress via ublk_reset_ch_dev() on daemon death. ] Signed-off-by: Sasha Levin commit 5a15eaa50f92b2e33f20e1aa7f1155f7be70e11a Author: Jia Yao Date: Wed Jul 29 14:37:59 2026 +0000 drm/xe/uapi: Reject coh_none PAT index for CPU_ADDR_MIRROR commit 4d58d7535e826a3175527b6174502f0db319d7f6 upstream. Add validation in xe_vm_bind_ioctl() to reject PAT indices with XE_COH_NONE coherency mode when used with DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR. CPU address mirror mappings use system memory that is CPU cached, which makes them incompatible with COH_NONE PAT indices. Allowing COH_NONE with CPU cached buffers is a security risk, as the GPU may bypass CPU caches and read stale sensitive data from DRAM. Although CPU_ADDR_MIRROR does not create an immediate mapping, the backing system memory is still CPU cached. Apply the same PAT coherency restrictions as DRM_XE_VM_BIND_OP_MAP_USERPTR. v2: - Correct fix tag v6: - No change v7: - Correct fix tag v8: - Rebase v9: - Limit the restrictions to iGPU v10: - Just add the iGPU logic but keep dGPU logic Fixes: b43e864af0d4 ("drm/xe/uapi: Add DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR") Cc: # v6.15+ Cc: Shuicheng Lin Cc: Mathew Alwin Cc: Michal Mrozek Cc: Matthew Brost Cc: Matthew Auld Signed-off-by: Jia Yao Reviewed-by: Matthew Auld Acked-by: Michal Mrozek Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260417055917.2027459-3-jia.yao@intel.com Signed-off-by: Sasha Levin commit 5488d3a69d205e28f74f18857b853aa12e778e66 Author: Mikulas Patocka Date: Tue Jul 28 22:19:09 2026 -0700 dm-verity: fix buffer overflow in FEC calculation commit 31d6e6c0ba8d5a7bd59660035a089307100c5e8e upstream. There's a buffer overflow in dm-verity-fec: if (neras && *neras <= v->fec->roots) fio->erasures[(*neras)++] = i; This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer. Signed-off-by: Mikulas Patocka Assisted-by: Claude:claude-opus-4-6 Cc: stable@vger.kernel.org Fixes: a739ff3f543a ("dm verity: add support for forward error correction") Reviewed-by: Sami Tolvanen Signed-off-by: Mikulas Patocka Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit 3f31bde63f9aeecccf843fbc87e581cbbecfe6dc Author: Eric Biggers Date: Tue Jul 28 22:19:08 2026 -0700 dm-verity-fec: replace {MAX,MIN}_RSN with {MIN,MAX}_ROOTS commit 82fbd6a3e29a329d439690cd7ccc4162c9cd8db6 upstream. Every time DM_VERITY_FEC_{MAX,MIN}_RSN are used, they are subtracted from DM_VERITY_FEC_RSM to get the bounds on the number of roots. Therefore, replace these with {MIN,MAX}_ROOTS constants which are more directly useful. (Note the inversion, where MAX_RSN maps to MIN_ROOTS and MIN_RSN maps to MAX_ROOTS.) No functional change. Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit d47281b9a4472cfd73122393e79fbe76b651e46a Author: Eric Biggers Date: Tue Jul 28 22:19:07 2026 -0700 dm-verity-fec: fix reading parity bytes split across blocks (take 3) commit 430a05cb926f6bdf53e81460a2c3a553257f3f61 upstream. fec_decode_bufs() assumes that the parity bytes of the first RS codeword it decodes are never split across parity blocks. This assumption is false. Consider v->fec->block_size == 4096 && v->fec->roots == 17 && fio->nbufs == 1, for example. In that case, each call to fec_decode_bufs() consumes v->fec->roots * (fio->nbufs << DM_VERITY_FEC_BUF_RS_BITS) = 272 parity bytes. Considering that the parity data for each message block starts on a block boundary, the byte alignment in the parity data will iterate through 272*i mod 4096 until the 3 parity blocks have been consumed. On the 16th call (i=15), the alignment will be 4080 bytes into the first block. Only 16 bytes remain in that block, but 17 parity bytes will be needed. The code reads out-of-bounds from the parity block buffer. Fortunately this doesn't normally happen, since it can occur only for certain non-default values of fec_roots *and* when the maximum number of buffers couldn't be allocated due to low memory. For example with block_size=4096 only the following cases are affected: fec_roots=17: nbufs in [1, 3, 5, 15] fec_roots=19: nbufs in [1, 229] fec_roots=21: nbufs in [1, 3, 5, 13, 15, 39, 65, 195] fec_roots=23: nbufs in [1, 89] Regardless, fix it by refactoring how the parity blocks are read. Fixes: 6df90c02bae4 ("dm-verity FEC: Fix RS FEC repair for roots unaligned to block size (take 2)") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit a556189c067569c3e849e05ca59d2a2a721271a2 Author: Eric Biggers Date: Tue Jul 28 22:19:06 2026 -0700 dm-verity-fec: fix the size of dm_verity_fec_io::erasures commit a7fca324d7d90f7b139d4d32747c83a629fdb446 upstream. At most 25 entries in dm_verity_fec_io::erasures are used: the maximum number of FEC roots plus one. Therefore, set the array size accordingly. This reduces the size of dm_verity_fec_io by 912 bytes. Note: a later commit introduces a constant DM_VERITY_FEC_MAX_ROOTS, which allows the size to be more clearly expressed as DM_VERITY_FEC_MAX_ROOTS + 1. This commit just fixes the size first. Fixes: a739ff3f543a ("dm verity: add support for forward error correction") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 22400725de070b787cd6d806c5795370ab46d269 Author: Jiayuan Chen Date: Tue Jul 28 20:26:58 2026 +0000 bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops [ Upstream commit 10f86a2a5c91fc4c4d001960f1c21abe52545ef6 ] When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp. Fixes: fd09af010788 ("bpf: sock_ops ctx access may stomp registers in corner case") Fixes: 84f44df664e9 ("bpf: sock_ops sk access may stomp registers when dst_reg = src_reg") Reported-by: Quan Sun <2022090917019@std.uestc.edu.cn> Reported-by: Yinhao Hu Reported-by: Kaiyan Mei Reported-by: Dongliang Mu Reviewed-by: Emil Tsalapatis Closes: https://lore.kernel.org/bpf/6fe1243e-149b-4d3b-99c7-fcc9e2f75787@std.uestc.edu.cn/T/#u Signed-off-by: Jiayuan Chen Acked-by: Martin KaFai Lau Link: https://patch.msgid.link/20260407022720.162151-2-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Jay Wang Signed-off-by: Sasha Levin commit 15a7cb71a5748a718453f3b01e1da3b52349c043 Author: Christian König Date: Wed Jun 24 16:00:41 2026 +0200 drm/amdgpu: fix check in amdgpu_hmm_invalidate_gfx commit 52f650963d8825e97a0ccdd2b616f8a01d9d3d38 upstream. For a short moment during alloc/free the userptr BO is not part of his VM, so bo->vm_bo can be NULL. Keep a reference to the VM root PD as parent of the userptr BO so that we can always use that to wait for all submissions of the VM instead of only the one involving the userptr BO. Signed-off-by: Christian König Fixes: 91250893cbaa ("drm/amdgpu: fix waiting for all submissions for userptrs") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5399 Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 631849ff5d603841e74f19f4a5e30fe1f7d7cf30) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ab7b40c638e0d65c7ed5062d9440a326f3d5a3ba Author: Yang Wang Date: Wed Jul 1 09:11:15 2026 +0800 drm/amd/pm: fix smu13 power limit range calculation commit 220f22e1d66c1cfb63387eb1c4210f92a357c2d9 upstream. SMU13 reports SocketPowerLimitAc/Dc as the default power limit, but MsgLimits.Power may carry a different firmware bound for the same PPT throttler. Using only the socket limit for both min and max can therefore expose an incorrect power range. Keep the socket limit as the default, but derive the range from both values: use the lower value for the min base and the higher value for the max base before applying OD percentages. Keep the current limit query independent from the cap calculation. Fixes: 1eaf26db9590 ("drm/amd/pm: fix smu13 power limit default/cap calculation") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5419 Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit f45bbf0f62f266ed8422d84f347d75d5fca846a7) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6405c4e75b3bcf0e72bd7a0ff5f1ed0c475e23aa Author: Asad Kamal Date: Sun Jun 14 12:50:28 2026 +0800 drm/amdgpu: fix aperture mapping leak commit ea772a440d56b285f4d491affac50ecd41f6b402 upstream. amdgpu_pci_remove() calls drm_dev_unplug() before invoking the driver fini routines. This causes drm_dev_enter() in amdgpu_ttm_fini() to always return false, so iounmap(aper_base_kaddr) never runs on normal driver unload, leaving an orphaned entry in the x86 PAT interval tree. On connected_to_cpu hardware, the aperture is mapped write-back (WB) via ioremap_cache(). On reload, IP discovery calls memremap(..., MEMREMAP_WC) over the same range. The WC vs WB conflict causes: ioremap error for 0x..., requested 0x1, got 0x0 amdgpu: discovery failed: -2 Fix by switching to devres-managed mappings so cleanup is guaranteed regardless of drm_dev_enter() state: - connected_to_cpu path: devm_memremap(MEMREMAP_WB). For IORESOURCE_SYSTEM_RAM ranges this takes the try_ram_remap() shortcut, returning __va(offset) from the existing kernel direct map. No new ioremap VA or PAT entry is created, so there is nothing to orphan. - dGPU path: devm_ioremap_wc() registers iounmap() as a devres action, guaranteeing cleanup at device_del() time. Also remove iounmap(aper_base_kaddr) from amdgpu_device_unmap_mmio() since the mapping is now devres-owned. v2: Remove redundant x86_64 guard (Lijo) Fixes: 9d0af8b4def0 ("drm/amdgpu: pre-map device buffer as cached for A+A config") Signed-off-by: Asad Kamal Reviewed-by: Christian König Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher (cherry picked from commit d871e99879cb5fd1fa798b006b4888887e63a17a) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 08fee493e0261f9e4120a5c8e7e42e8a723574e8 Author: Ce Sun Date: Mon Jun 22 22:58:16 2026 +0800 drm/amdgpu: invoke pm_genpd_remove() before freeing genpd commit 28c9b3c5dc35cc790d11e26ca3fc6e068be63998 upstream. Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. Signed-off-by: Ce Sun Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 68eab5a64ddbc0bb34f6241f7983fc03eb4aeaf2 Author: Ce Sun Date: Mon Jun 22 23:05:09 2026 +0800 drm/amdgpu: fix resource leak on ACP reset timeout commit 020da7c5aac5b86bad8a1571f6eda6b8cff9331d upstream. When ACP soft reset poll times out, original code returns early without cleanup, leaking MFD child devices, genpd links and all ACP heap allocations. Replace direct early return with goto out to force run all cleanup logic regardless of reset success, preserve timeout error code for caller. Signed-off-by: Ce Sun Reviewed-by: Tao Zhou Signed-off-by: Alex Deucher (cherry picked from commit 98073e4328d7a8d75d03696ab27f6de70ef1aeda) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ffb33d466a68cea3e8a3dbed04d79037a3cbabd1 Author: Boyuan Zhang Date: Tue May 12 10:29:36 2026 -0400 drm/amdgpu: fix division by zero with invalid uvd dimensions commit 0c01c811be47e6b146552dd59bfedbea8f09b8f4 upstream. When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. Signed-off-by: Boyuan Zhang Reviewed-by: Leo Liu Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8c6d84a54823cd839e6ce22af559925f1320c310 Author: Luca Coelho Date: Mon Jun 22 17:03:58 2026 +0300 drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() commit 613059875958e7b217b250ed14c3b189f9488421 upstream. A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost. Fixes: dbaeef363ea5 ("drm/dp_mst: Add a helper to queue a topology probe") Cc: Imre Deak Cc: Lyude Paul Cc: stable@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Jonas Emilsson Signed-off-by: Luca Coelho Link: https://lore.kernel.org/all/20260503034533.1023686-1-jonas.emilsson@gmail.com Acked-by: Imre Deak Link: https://patch.msgid.link/20260622140532.526722-1-luciano.coelho@intel.com Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit bd868c077f67589ed2a714307ceaade5f246e302 Author: Boyuan Zhang Date: Thu May 21 09:59:37 2026 -0400 drm/amdgpu/vcn4: avoid rereading IB param length commit 3b4082fabc67c9780b06eb959e59dd92fa79c0f0 upstream. Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. Signed-off-by: Boyuan Zhang Reviewed-by: David Rosca Signed-off-by: Alex Deucher (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7eebef042c12dfe0568593ee6a8926d16505925e Author: Boyuan Zhang Date: Mon May 25 11:34:27 2026 -0400 drm/amdgpu/vce: fix integer overflow in image size commit 186bfdc4e26d019b2e7570cb121964a1d89b2e5b upstream. Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 Signed-off-by: Boyuan Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f7e9eeaccca54d1ee848bff4fb4374de8d0b0611 Author: Jakob Linke Date: Wed Jun 17 08:24:15 2026 +0200 drm/amdgpu/soc24: reset dGPU if suspend got aborted commit aff079bdce65f6d085e4b0091fdf87fffa95b0d9 upstream. For SOC24 ASICs (RDNA4 / Navi 4x dGPUs) re-enabling PM features fails if an S3 suspend got aborted, the same issue already handled for SOC21 and SOC15: commit df3c7dc5c58b ("drm/amdgpu: Reset dGPU if suspend got aborted") commit 38e8ca3e4b6d ("amdgpu/soc15: enable asic reset for dGPU in case of suspend abort") The aborted resume fails with: amdgpu: SMU: No response msg_reg: 6 resp_reg: 0 amdgpu: Failed to enable requested dpm features! amdgpu: resume of IP block failed -62 Apply the same workaround for soc24: detect the aborted-suspend state at resume via the sign-of-life register and reset the device before re-init. This is a workaround till a proper solution is finalized. Fixes: 98b912c50e44 ("drm/amdgpu: Add soc24 common ip block (v2)") Signed-off-by: Jakob Linke Signed-off-by: Alex Deucher (cherry picked from commit fed5bdbfe1d4a19a26c70f7fc58017dc88be1c18) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit dc3f5da1ba8e280d31676ce15b937e4302235b03 Author: Alex Deucher Date: Mon Jun 15 18:44:11 2026 -0400 drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() commit 40cdbe9fa424cc6264a7aed93a04bd7d69109d9e upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak Signed-off-by: Alex Deucher (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 76c977d396f12a460a9cd71e3b55c0952a070eb4 Author: Boyuan Zhang Date: Wed Jun 24 09:50:01 2026 -0400 drm/amdgpu/jpeg: fix jpeg_v5_0_1_is_idle detection commit efcedeececcf995fcf717b21e39aa7c446fa3bf7 upstream. jpeg_v5_0_1_is_idle() initializes ret to false and then accumulates ring idle status using &=. Since false & condition always remains false, the function can never report the JPEG block as idle. Initialize ret to true so the function returns true only when all JPEG rings report RB_JOB_DONE. Signed-off-by: Boyuan Zhang Reviewed-by: David (Ming Qiang) Wu Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 680adf5faeeabb4585f7aeb53681719e2d6c2f41) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 058373af59551b5b55d075b1baec1546f342b26e Author: Boyuan Zhang Date: Fri Jun 26 10:39:26 2026 -0400 drm/amdgpu/jpeg: fix jpeg_v4_0_3_is_idle detection commit c44af3810fc8b3adf6910a332038aa566560c8fa upstream. jpeg_v4_0_3_is_idle() initializes ret to false and then accumulates ring idle status using &=. Since false & condition always remains false, the function can never report the JPEG block as idle. Initialize ret to true so the function returns true only when all JPEG rings report RB_JOB_DONE. Signed-off-by: Boyuan Zhang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit e9df8e9d04e0593d17ddb069f3b7958991cd18c9) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 042c047e8bc9c9ada7574028a8e4592102e2e1fd Author: Alex Deucher Date: Mon Jun 15 18:14:59 2026 -0400 drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() commit 6302be10b521f5106ce01eb5a724b9e7945a5061 upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak Signed-off-by: Alex Deucher (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 05aea3344c422fe95299bb1b21a04de30c7ea198 Author: Alex Deucher Date: Mon Jun 15 18:42:35 2026 -0400 drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() commit 00f4050f7c367d7bdce347ca279ce467c434cf15 upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak Signed-off-by: Alex Deucher (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f70bd5235d9efc2ee2f70293eea51888c5f2a54d Author: Alex Deucher Date: Mon Jun 15 18:17:59 2026 -0400 drm/amdgpu/gfx8: drop unecessary BUG_ON() commit 84a1a8a952ab4b8c23c5dd1f2eea4049cb4914f5 upstream. There's no need to crash the kernel for this case. Reviewed-by: Vitaly Prosyak Signed-off-by: Alex Deucher (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 987bedd3ea89d747d1c5ab708ce3293e2f033b6c Author: Alex Deucher Date: Mon Jun 15 18:21:58 2026 -0400 drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON() commit cd3b3efa1ced05528d9128755338baa62a6b562d upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak Signed-off-by: Alex Deucher (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit dfd9bf09fd8fe81f113a5c7e88bfd99f2499542f Author: Alex Deucher Date: Mon Jun 15 18:20:55 2026 -0400 drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() commit 0eebcab1ea2a77f086a04108f386f82ee3496022 upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak Signed-off-by: Alex Deucher (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7e22de67e545d0f72595514d3a66675e9d074adc Author: Alex Deucher Date: Mon Jun 15 18:19:52 2026 -0400 drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() commit d06c4173a7c38c7a39e98859f839ce714c7af2c9 upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak Signed-off-by: Alex Deucher (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e75f71143b68bda01b641ad4e45d090fe4745618 Author: Yang Wang Date: Fri Jun 12 10:55:09 2026 +0800 drm/amd/pm: make pp_features read-only when scpm is enabled commit 53c78ab388bfc1a4d72e756815d0db0a842c812e upstream. SCPM owns power feature control when enabled. Make pp_features read-only during sysfs setup by clearing its write bits and store callback. Signed-off-by: Yang Wang Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher (cherry picked from commit 6a5786e191fdce36c5db170e5209cf609e8f0087) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ada47af5c215efbf5b6f13b3830f14f559320684 Author: Yang Wang Date: Thu Jun 18 12:54:14 2026 +0800 drm/amd/pm: fix amdgpu_pm_info power display units commit 238baca26a6279e688d1a156bd031390b82eb578 upstream. amdgpu_pm_info displayed power sensor readings with the wrong fractional unit. It treated the low byte of the raw sensor value as the decimal part of watts, while that field represents milliwatts in the decoded value. As a result, debugfs could report misleading SoC power when the remainder was not already a two-digit centiwatt value. Example with query = 0x00000354: raw field value --------------------- query >> 8 3 W query & 0xff 84 mW decoded power 3084 mW output value --------------------- before 3.84 W after 3.08 W Fixes: f0b8f65b4825 ("drm/amd/amdgpu: fix the GPU power print error in pm info") Signed-off-by: Yang Wang Reviewed-by: Asad Kamal Signed-off-by: Alex Deucher (cherry picked from commit 01992b121fb652c753d37e0c1427a2d1a557d2b1) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7b263cf1dd4c0a034bc6bee2e276e1631635c595 Author: Ethan Nelson-Moore Date: Mon May 4 19:44:09 2026 -0700 watchdog: s32g_wdt: remove incorrect options in watchdog_info struct commit 2b37415618bfc6a83d4aceb00fd8d6491096f2ed upstream. The s32g_wdt driver uses two incorrect constants in the options field of its watchdog_info struct. This bit mask should contain WDIOF_* constants, but the driver uses two WDIOC_* ioctl constants (in addition to correct WDIOF_* constants). This causes many incorrect bits to be set in the bit mask. The functionality indicated by these ioctl constants is supported by all drivers using the watchdog framework, so this patch simply removes them. Fixes: bd3f54ec559b ("watchdog: Add the Watchdog Timer for the NXP S32 platform") Cc: stable@vger.kernel.org # 6.18+ Signed-off-by: Ethan Nelson-Moore Acked-by: Daniel Lezcano Link: https://lore.kernel.org/r/20260505024409.60301-1-enelsonmoore@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 79370b573e92e8f190eb5f9a511fa5398340d8b2 Author: James Raphael Tiovalen Date: Tue Jul 21 00:04:24 2026 +0800 vxlan: mdb: Fix source list corruption on a failed replace commit dcd9b465965422b9654f6026e8a2fa8984f74c3c upstream. When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails. Fixes: a3a48de5eade ("vxlan: mdb: Add MDB control path support") Cc: stable@vger.kernel.org Signed-off-by: James Raphael Tiovalen Reviewed-by: Ido Schimmel Reviewed-by: Antoine Tenart Reviewed-by: Nikolay Aleksandrov Link: https://patch.msgid.link/20260720160428.249356-1-jamestiotio@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f60bac115d8dcac50a05df993eaf1dd758f98ed1 Author: Stefano Garzarella Date: Wed Jul 8 12:29:03 2026 +0200 vsock/virtio: collapse receive queue under memory pressure commit 2a12c05aef213ff304ecc9e2f351de20731946b8 upstream. When many small packets accumulate in the receive queue, the skb overhead can exceed buf_alloc even while the payload is within bounds. This causes virtio_transport_inc_rx_pkt() to reject packets, leading to connection resets during large transfers under backpressure. The issue was reported by Brien, who has a reproducer, but it is also easily reproducible with iperf-vsock [1] using a small packet size: iperf3 --vsock -c $CID -l 129 which fails immediately without this patch but with commit 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue"). Inspired by TCP's tcp_collapse() which solves a similar problem, add virtio_transport_collapse_rx_queue() that walks the receive queue and re-copies data into compact linear skbs to reduce the overhead. The collapse is triggered proactively from when the number of skb queued is close to exceeding the overhead budget. A pre-scan counts the eligible bytes to size each allocation precisely, avoiding waste for isolated small packets. Partially consumed skbs are kept as-is to preserve buf_used/fwd_cnt accounting, EOM-marked skbs to maintain SEQPACKET message boundaries, and skbs already larger than the collapse target because they already have a good data-to-overhead ratio. Walking a large queue may take a significant amount of time and cache misses, causing traffic burstiness. To limit this, the collapse stops once enough room is freed for this packet and the next one, but may opportunistically free more to fill each collapsed skb to capacity. [1] https://github.com/stefano-garzarella/iperf-vsock Fixes: 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue") Cc: stable@vger.kernel.org Reported-by: Brien Oberstein Closes: https://lore.kernel.org/netdev/618701dd023e$063de350$12b9a9f0$@gmail.com/ Tested-by: Brien Oberstein Signed-off-by: Stefano Garzarella Acked-by: Michael S. Tsirkin Reviewed-by: Bobby Eshleman Link: https://patch.msgid.link/20260708102904.50732-2-sgarzare@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 5f5a41a48dbf9eda57b67ce23e548602cf7195a6 Author: Daehyeon Ko <4ncienth@gmail.com> Date: Tue Jul 14 22:19:39 2026 +0900 tipc: clear sock->sk on the failed-insert path in tipc_sk_create() commit ba0533fc163f905fe817cfabdf8ed4058da44800 upstream. When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: if (tipc_sk_insert(tsk)) { sk_free(sk); pr_warn("Socket create failed; port number exhausted\n"); return -EINVAL; } This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact "failed accept() releases a pre-allocated child" case with "if (sk == NULL) return 0;", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Fixes: 00aff3590fc0 ("net: tipc: fix possible refcount leak in tipc_sk_create()") Cc: stable@vger.kernel.org Reviewed-by: Tung Nguyen Reviewed-by: Breno Leitao Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260714131939.1255974-1-4ncienth@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 234f9ffbd9b2c1b24ec67200ea3cff07401bec48 Author: Yuxiang Yang Date: Fri Jul 17 08:14:42 2026 +0000 tcp: challenge ACK for non-exact RST in SYN-RECEIVED commit a28c4fcbf774e23b4779cae468e3497a5ad1f4a1 upstream. The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response. Reported-by: Yuxiang Yang Reported-by: Yizhou Zhao Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Fixes: 282f23c6ee34 ("tcp: implement RFC 5961 3.2") Cc: stable@vger.kernel.org Signed-off-by: Yuxiang Yang Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260717081443.809393-2-yangyx22@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fadaff3f66e124c3a62237f9c881819a8ac90309 Author: Yizhou Zhao Date: Mon Jul 13 18:56:30 2026 +0800 tcp: initialize standalone TCP-AO response padding commit e1a9d3cc11829c5414a75eb39c704f461936eb24 upstream. tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header. Fixes: decde2586b34 ("net/tcp: Add TCP-AO sign to twsk") Fixes: da7dfaa6d6f7 ("net/tcp: Consistently align TCP-AO option in the header") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Suggested-by: Eric Dumazet Signed-off-by: Yizhou Zhao Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260713105631.8616-1-zhaoyz24@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4a4f3aa6af205bee539b5670afa2cd4e4953750e Author: Justin Lai Date: Thu Jul 9 18:34:56 2026 +0800 rtase: Workaround for TX hang caused by hardware packet parsing commit 1c50efa1faf3a1a96e100b07ec7a2f3164d90bee upstream. The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission. Fixes: d6e882b89fdf ("rtase: Implement .ndo_start_xmit function") Cc: stable@vger.kernel.org Signed-off-by: Justin Lai Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260709103456.83789-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6866abf59976d273164a6624234d96a967280223 Author: Asim Viladi Oglu Manizada Date: Wed Jul 22 09:38:43 2026 +0000 pppoe: reload header pointer after dev_hard_header() commit e9c238f6fe42fb1b4dba3a578277de32cb487937 upstream. pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Asim Viladi Oglu Manizada Reviewed-by: Vadim Fedorenko Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260722093814.3017176-1-manizada@pm.me Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 460b9f0609d263dd4b3b36482b6f9ef2d8f55067 Author: Shuvam Pandey Date: Sat May 23 20:38:27 2026 +0545 ovpn: hold peer before scheduling keepalive work commit a4710ae2e7e322fdaefb4be8604228279cfaf48c upstream. ovpn_peer_keepalive_send() passes its peer reference to ovpn_xmit_special(), which ultimately drops it. The keepalive scheduler currently queues the work first and takes the reference only after schedule_work() reports that the work was queued. Once schedule_work() queues the item, another CPU may run the worker before the caller gets to ovpn_peer_hold(). In that case the worker can consume a reference that was not acquired for it, corrupting the peer lifetime accounting. Take the peer reference before queueing the work and drop it again when the work was already pending. Fixes: 3ecfd9349f40 ("ovpn: implement keepalive mechanism") Cc: stable@vger.kernel.org Signed-off-by: Shuvam Pandey Reviewed-by: Sabrina Dubroca Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit b08526bf0bbf84ceebd29033783e8e0c9f451286 Author: Pavitra Jha Date: Sat May 23 05:02:43 2026 -0400 ovpn: fix peer refcount leak in TCP error paths commit 63bbe18fc03062f483c627838a566a707b62da79 upstream. When either the TCP RX or TX error path calls ovpn_peer_hold() followed by schedule_work(&peer->tcp.defer_del_work), and the work item is already pending from the other path, schedule_work() returns false and the work runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put() exactly once, the extra reference taken by the losing path is never dropped, leaking the peer object. The race window: CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error): ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2 schedule_work() <- queued schedule_work() <- NO-OP (work already pending) ovpn_tcp_peer_del_work runs: ovpn_peer_del() ovpn_peer_put() <- refcnt+1 <- peer never freed Fix by checking the return value of schedule_work() in both paths and calling ovpn_peer_put() to drop the extra reference if the work was already pending. ovpn_peer_hold() is kept unconditional in the TX path as it cannot fail at that point. Fixes: a6a5e87b3ee4 ("ovpn: avoid sleep in atomic context in TCP RX error path") Cc: stable@vger.kernel.org Signed-off-by: Pavitra Jha Reviewed-by: Sabrina Dubroca Signed-off-by: Antonio Quartulli Signed-off-by: Greg Kroah-Hartman commit 100a23b1613e9218e0af654ef102352c713f0263 Author: Kyle Zeng Date: Tue Jul 7 15:16:35 2026 -0700 openvswitch: fix GSO userspace truncation underflow commit 4032f8ed10fcb84d41c508dfb04be96589f78dfe upstream. OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it. Fixes: f2a4d086ed4c ("openvswitch: Add packet truncation support.") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5.5 Signed-off-by: Kyle Zeng Reviewed-by: Ilya Maximets Reviewed-by: Aaron Conole Link: https://patch.msgid.link/20260707221635.27489-1-kylebot@openai.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit f80ba170d7b3a44e3d244a2c8e06031d61bf3b23 Author: Doruk Tan Ozturk Date: Wed Jul 15 10:20:21 2026 +0200 mctp: serial: handle zero-length frames to prevent rx buffer overflow commit 793b9b729f1e8de57be8c8daf1a9838be96cabed upstream. The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: if (c > MCTP_SERIAL_FRAME_MTU) { dev->rxstate = STATE_ERR; } else { dev->rxlen = c; dev->rxpos = 0; dev->rxstate = STATE_DATA; ... } A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is tested: dev->rxbuf[dev->rxpos] = c; dev->rxpos++; dev->rxstate = STATE_DATA; if (dev->rxpos == dev->rxlen) { dev->rxpos = 0; dev->rxstate = STATE_TRAILER; } With rxlen == 0 the "rxpos == rxlen" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: a0c2ccd9b5ad ("mctp: Add MCTP-over-serial transport binding") Cc: stable@vger.kernel.org Suggested-by: Jeremy Kerr Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260715082021.46315-1-doruk@0sec.ai Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit f20dedce0429b293d4bad604e0d3f65d8ac96c83 Author: Doruk Tan Ozturk Date: Thu Jul 16 21:34:23 2026 +0200 mac802154: llsec: reject frames shorter than the authentication tag commit fd3a3f28ed60c6af4b2a39933b151d6b27842c3b upstream. llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as assoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed. Fixes: 4c14a2fb5d14 ("mac802154: add llsec decryption method") Cc: stable@vger.kernel.org Reviewed-by: Simon Horman Signed-off-by: Doruk Tan Ozturk Link: https://patch.msgid.link/20260716193423.32498-1-doruk@0sec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 59c1d5463b7bc5a2cdaae27108d1dfd67edc7d1b Author: Ibrahim Hashimov Date: Tue Jul 21 23:12:28 2026 +0200 mac802154: hold an interface reference across the scan worker commit 234e5e898b713bc0b3a631b6f002897f43d046c8 upstream. mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit. Fixes: 57588c71177f ("mac802154: Handle passive scanning") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Link: https://patch.msgid.link/20260721211228.34578-1-security@auditcode.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 472aba2603ca74c4f7722cb0c0296942b0776b8d Author: Michael Bommarito Date: Tue Jul 14 07:49:03 2026 -0400 ila: reload IPv6 header after pskb_may_pull in checksum adjust commit 92d3817649df2b0b6a008a686c8275c88d7ef594 upstream. ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers. Fixes: 33f11d16142b ("ila: Create net/ipv6/ila directory") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Simon Horman Reviewed-by: Antoine Tenart Link: https://patch.msgid.link/20260714114903.3763420-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 919d0accf2600b5e5f4c44aa5733b318b5324588 Author: Sergey Temerkhanov Date: Fri Jul 17 11:53:30 2026 -0700 ice: use READ_ONCE() to access cached PHC time commit 2915681b89f817677ab9f1166d95b595bc144f5f upstream. ptp.cached_phc_time is a 64-bit value updated by a periodic work item on one CPU and read locklessly on another. On 32-bit or non-atomic architectures this can result in a torn read. Use READ_ONCE() to enforce a single atomic load. Fixes: 77a781155a65 ("ice: enable receive hardware timestamping") Cc: stable@vger.kernel.org Signed-off-by: Sergey Temerkhanov Signed-off-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260717185340.3595286-9-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5e496f2b615cec4b45537cfb5b54f36a51dc8753 Author: Aleksandr Loktionov Date: Fri Jul 17 11:53:33 2026 -0700 ice: reject out-of-range ptype in ice_parser_profile_init commit 59abb87159c53605c063f6e2ceb215b5eba43ee6 upstream. set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range. Fixes: e312b3a1e209 ("ice: add API for parser profile initialization") Cc: stable@vger.kernel.org Signed-off-by: Aleksandr Loktionov Reviewed-by: Marcin Szycik Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260717185340.3595286-12-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 91e0249f3ef62b75fe8c9c9372eaba32876e4b3a Author: Eddie Phillips Date: Thu Jul 9 21:19:06 2026 +0000 gve: fix Rx queue stall on alloc failure commit b65352a1bac64442ad95e64f385b40ccb9f1b0db upstream. When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet. Cc: stable@vger.kernel.org Fixes: 9b8dd5e5ea48 ("gve: DQO: Add RX path") Reviewed-by: Jordan Rhee Signed-off-by: Eddie Phillips Signed-off-by: Harshitha Ramamurthy Reviewed-by: Przemek Kitszel Link: https://patch.msgid.link/20260709211906.3322883-1-hramamurthy@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 18705cace0619fd2123737dcd028147774f38181 Author: James Montgomery Date: Fri Jul 3 15:26:41 2026 -0400 ksmbd: defer destroy_previous_session() until after NTLM authentication commit c74801ee524f477c174a1899782b6c3b6918d407 upstream. In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-cifs/20260702155449.3639773-1-james_montgomery@disroot.org/ Signed-off-by: James Montgomery Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 6098b55f6a0cfb7e574d8f3eea1a72ba49aca0b5 Author: Carl Johnson Date: Tue Jul 21 13:27:55 2026 -0400 smb: client: handle STATUS_STOPPED_ON_SYMLINK responses without a symlink target commit 2eb74eef4b7eda8df593d22fb48e94ef959ec8a5 upstream. The macOS built-in SMB server returns STATUS_STOPPED_ON_SYMLINK for a CREATE on a path whose final component is a symlink, but it does not include a Symbolic Link Error Response in the error data: both ErrorContextCount and ByteCount are zero, so the symlink target is not present in the response at all. Per [MS-SMB2] section 2.2.2 such a response should carry a valid Symbolic Link Error Response, so this is a server bug, but the target can still be retrieved with FSCTL_GET_REPARSE_POINT. Frame from a capture against macOS 26.5.2 (build 25F84): SMB2 hdr : Status=0x8000002d STATUS_STOPPED_ON_SYMLINK, Cmd=Create Error Rsp: StructureSize=0x0009 Error Context Count: 0 Byte Count: 0 Error Data: 00 symlink_data() cannot find a struct smb2_symlink_err_rsp in such a response and returns -EINVAL, which parse_create_response() propagates, so smb2_query_path_info() bails out at if (rc || !data->reparse_point) goto out; before it can retry with SMB2_OP_GET_REPARSE. stat(), readlink() and ls of any server-side symlink then fail with -EINVAL: $ ls -la Config l????????? ? ? ? ? ? Config.json $ stat Config/Config.json stat: cannot statx 'Config/Config.json': Invalid argument A 5.10 client resolves these symlinks correctly against the same server and share, so this is a regression for Apple SMB servers. Handle it in several places: - symlink_data() detects the empty response (ErrorContextCount and ByteCount both zero) and returns a distinct -ENODATA, so that "server did not send the target" can be told apart from a genuinely malformed response and only this case is worked around. - parse_create_response() treats -ENODATA like STATUS_IO_REPARSE_TAG_NOT_HANDLED, which does not carry the target either: leave the reparse tag unset and clear rc, so the existing SMB2_OP_GET_REPARSE path retrieves the target. - smb2_query_path_info() only fixes up the symlink target type when the target is already known. SMB2_OP_GET_REPARSE sets data->reparse.tag but does not parse the target out of the reparse buffer; that happens later, in reparse_info_to_fattr(). Without this check smb2_fix_symlink_target_type() is called with a NULL target and returns -EIO. This could not happen with servers that send the target inline and therefore skip SMB2_OP_GET_REPARSE. - smb2_open_file() maps -ENODATA to -EIO, matching STATUS_IO_REPARSE_TAG_NOT_HANDLED, so its callers retrieve the target with SMB2_OP_GET_REPARSE as well. Tested on Debian 13, kernel 6.18.38 (armv7), against macOS 26.5.2: symlinks now resolve, including relative, parent-traversing and directory symlinks, and reads through symlinks succeed. Cc: stable@vger.kernel.org Co-developed-by: Pali Rohár Signed-off-by: Pali Rohár Signed-off-by: Carl Johnson Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 34f2a2f32af570dfcc532ad70c080629ee1c32b0 Author: Raphael Zimmer Date: Thu Jul 9 13:26:20 2026 +0200 rbd: Reset positive result codes to zero in object map update path commit a6c4250b81bd30beae94e1b7a4b26fa1193ad2e4 upstream. In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case. Cc: stable@vger.kernel.org Fixes: 22e8bd51bb04 ("rbd: support for object-map and fast-diff") Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 63d78b546eefc38ad9898dc839bfc94811ede547 Author: Christian Brauner Date: Thu Jul 23 11:37:05 2026 +0200 super: fix emergency thaw deadlock on frozen block devices commit 749d7aa0377aae32af8c0a4ad43371e7bf830ab5 upstream. do_thaw_all_callback() calls bdev_thaw() while holding sb->s_umount exclusively. If the block device was frozen via bdev_freeze() dropping the last block layer freeze reference calls fs_bdev_thaw() which reacquires s_umount: do_thaw_all_callback(sb) super_lock_excl(sb) # holds sb->s_umount bdev_thaw(sb->s_bdev) mutex_lock(&bdev->bd_fsfreeze_mutex) # bd_fsfreeze_count drops 1 -> 0 bd_holder_ops->thaw == fs_bdev_thaw get_bdev_super(bdev) bdev_super_lock(bdev, true) super_lock(sb, true) down_write(&sb->s_umount) # same task: deadlock The emergency thaw worker deadlocks against itself holding both s_umount and bd_fsfreeze_mutex. That fscks any subsequent unmount, freeze, or thaw of that filesystem and block device. [ 81.878470] sysrq: Show Blocked State [ 81.880140] task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208060 flags:0x00080000 [ 81.884876] Workqueue: events do_thaw_all [ 81.886656] Call Trace: [ 81.887759] [ 81.888763] __schedule+0x579/0x1420 [ 81.890372] schedule+0x3a/0x100 [ 81.891794] schedule_preempt_disabled+0x15/0x30 [ 81.893848] rwsem_down_write_slowpath+0x1ea/0x900 [ 81.895191] ? __pfx_do_thaw_all_callback+0x10/0x10 [ 81.896528] down_write+0xbd/0xc0 [ 81.897505] super_lock+0x91/0x180 [ 81.898457] ? __mutex_lock+0xa99/0x1140 [ 81.900748] ? __mutex_unlock_slowpath+0x1f/0x400 [ 81.902069] bdev_super_lock+0x5b/0x150 [ 81.903132] get_bdev_super+0x10/0x60 [ 81.904042] fs_bdev_thaw+0x23/0xf0 [ 81.904755] bdev_thaw+0x82/0x100 [ 81.905484] do_thaw_all_callback+0x2c/0x50 [ 81.906298] __iterate_supers+0x5d/0x130 [ 81.907067] do_thaw_all+0x20/0x40 [ 81.907739] process_one_work+0x206/0x5e0 [ 81.908545] worker_thread+0x1e2/0x3c0 [ 81.909339] ? __pfx_worker_thread+0x10/0x10 [ 81.910171] kthread+0xf4/0x130 [ 81.910799] ? __pfx_kthread+0x10/0x10 [ 81.911528] ret_from_fork+0x2e2/0x3b0 [ 81.912259] ? __pfx_kthread+0x10/0x10 [ 81.913010] ret_from_fork_asm+0x1a/0x30 [ 81.913806] bdev_super_lock() even documents the violated requirement with lockdep_assert_not_held(&sb->s_umount). Acquiring bd_fsfreeze_mutex under s_umount also inverts the bd_fsfreeze_mutex vs. s_umount ordering established by bdev_{freeze,thaw}() and can thus ABBA against a concurrent block-layer freeze even when the recursive path isn't hit. Fix this by not holding s_umount around the bdev_thaw() loop at all. Pin the superblock with an active reference instead as filesystems_freeze_callback() does. The active reference keeps the superblock from being shut down and so ->s_bdev stays valid without holding s_umount. The block-layer-held freeze is dropped by fs_bdev_thaw() with FREEZE_MAY_NEST | FREEZE_HOLDER_USERSPACE exactly as a regular unfreeze would and thaw_super_locked() handles filesystem-level freezes as before. The emergency thaw path has deadlocked like this in one form or another for a long long time but the current exclusively-held shape dates back to commit [1] where thaw_bdev() already ended in thaw_super() with s_umount held by do_thaw_all_callback(). Fixes: 08fdc8a0138a ("buffer.c: call thaw_super during emergency thaw") [1] Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260723-work-super-emergency_thaw-v1-1-7c315c600245@kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit e4406cbdd915f702d2ed9ee8b30683a16b06c6ac Author: Paul Greenwalt Date: Fri Jul 17 11:53:31 2026 -0700 ice: fix PTP Call Trace during PTP release commit f6a7e00b81e35ef1325234925f2fe1e53b466f92 upstream. If a PF reset occurs when the PTP state is ICE_PTP_UNINIT, then ice_ptp_rebuild() will update the state to ICE_PTP_ERROR. This will result in the following PTP release call trace during driver unload: kernel BUG at lib/list_debug.c:52! ice_ptp_release+0x332/0x3c0 [ice] ice_deinit_features.part.0+0x10e/0x120 [ice] ice_remove+0x100/0x220 [ice] This was observed when passing PF1 through to a VM. ice_ptp_init() fails because ctrl_pf is NULL and sets the state to ICE_PTP_UNINIT. Fix by detecting the ICE_PTP_UNINIT state in ice_ptp_rebuild() and returning without error, preventing the invalid state transition to ICE_PTP_ERROR. The only valid path to ICE_PTP_ERROR is from ICE_PTP_RESETTING after a failed rebuild. Fixes: 8293e4cb2ff5 ("ice: introduce PTP state machine") Cc: stable@vger.kernel.org Signed-off-by: Paul Greenwalt Signed-off-by: Aleksandr Loktionov Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260717185340.3595286-10-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b3efb4744abf493c9782eae713b861a80d9bbeca Author: Sven Schnelle Date: Tue Jul 14 15:03:42 2026 +0200 ptp: ptp_s390: Add missing facility check commit e78f1ac37afcb16cb6fef8a2c92591eab6558956 upstream. Only register the physical clock when facility 28 is installed and PTFF QAF returns that PTFF QPT is available. Fixes: 2d7de7a3010d ("s390/time: Add PtP driver") Signed-off-by: Sven Schnelle Cc: stable@kernel.org Reviewed-by: Heiko Carstens Link: https://patch.msgid.link/20260714130342.1971700-3-svens@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 9a8a247f0f17b68b90615c694f151f9724940f76 Author: Sven Schnelle Date: Tue Jul 14 15:03:41 2026 +0200 s390/ptff: Export ptff_function_mask[] commit 9de445d8296a7f2b011ebb5834fdc94dcda5c778 upstream. Export the ptff_function_mask to make ptff_query() usable in modules. Signed-off-by: Sven Schnelle Acked-by: Heiko Carstens Link: https://patch.msgid.link/20260714130342.1971700-2-svens@linux.ibm.com Signed-off-by: Jakub Kicinski Cc: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit 4afc58ea75b966c3b8a94225b9f9b335958d0482 Author: Jann Horn Date: Mon Jul 6 20:22:42 2026 +0200 proc: Fix broken error paths for namespace links commit 425224c2d700391729be7fe6929a88ef4e2d7a4e upstream. Don't return the return value of down_read_killable() (0) when a ptrace access check fails, return -EACCES as intended. Reported-by: Magnus Lindholm Closes: https://lore.kernel.org/r/20260706170735.2941493-1-linmag7@gmail.com Fixes: 6650527444da ("proc: protect ptrace_may_access() with exec_update_lock (part 1)") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn Link: https://patch.msgid.link/20260706-procfs-ns-eacces-fix-v1-1-a69ab14c02e6@google.com Tested-by: Magnus Lindholm Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 4056cc19071a3268c2b1ad89fef990f4ca0aab69 Author: Coia Prant Date: Fri Jul 17 15:43:25 2026 +0800 net: pcs: xpcs: fix SGMII state reading commit def9a4745e105145133e442dd8a1c126caf0f553 upstream. Commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode") added a path in xpcs_get_state_c37_sgmii() that reads speed/duplex from BMCR after AN completes. However, BMCR does not reflect the negotiated result on the hardware where this has been tested: - On RK3568 (MAC side SGMII), BMCR returns a fixed hardware reset value - Wangxun engineer Jiawen Wu confirmed that on their side, "BMCR looks like it only wants to be return as 0" [0] The correct information is available in CL37_ANSGM_STS, which contains the actual link status and negotiated speed/duplex. This bug was previously masked by phylink core, which overrides the PCS link state with the PHY state when a PHY is present: /* If we have a phy, the "up" state is the union of both the * PHY and the MAC */ if (phy) link_state.link &= pl->phy_state.link; Thus, when the link is down, the PHY's link_down state is applied on top of whatever the PCS reports, hiding the broken PCS state reading path. Modify xpcs_get_state_c37_sgmii() to: 1. Read link state from CL37_ANSGM_STS 2. If link is up, report speed/duplex from CL37_ANSGM_STS 3. Remove the broken BMCR reading path entirely Also properly set state->an_complete to reflect the AN completion status, and clear CL37_ANCMPLT_INTR when link is down to avoid stale state. [0] https://lore.kernel.org/all/000c01dd1593$2ac0b0f0$804212d0$@trustnetic.com/ Fixes: 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode") Cc: stable@vger.kernel.org Tested-by: Jiawen Wu Signed-off-by: Coia Prant Tested-by: Maxime Chevallier Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260717074324.3250043-2-coiaprant@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 80d977f280b4eccd4ac5369871d0ecb2b9c9a49d Author: Fan Wu Date: Sun Jul 12 14:27:29 2026 +0000 net: hip04: fix RX buffer leak on build_skb failure commit 14fa65d10f5696b063a7d8d26e8291ea84a2c6ed upstream. When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool. Fixes: 701a0fd52318 ("hip04_eth: fix missing error handle for build_skb failed") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260712142729.2057636-1-fanwu01@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a4dfd46cc8f08a29c6183794790547d0945f3d45 Author: Shiming Cheng Date: Thu Jul 9 09:46:39 2026 +0800 net: gro: fix double aggregation of flush-marked skbs commit e751256486d0ded20f5a9f9863467f1dce65142f upstream. Commit 0ab03f353d36 ("net-gro: Fix GRO flush when receiving a GSO packet.") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive(). Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.") Cc: stable@vger.kernel.org Signed-off-by: Shiming Cheng Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260709014704.3625-1-shiming.cheng@mediatek.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ec6d91a1bf2ebd767d3d43f6d249ee0ed3f4558a Author: David Lee Date: Mon Jul 13 10:47:50 2026 +0000 net/x25: fix use-after-free in x25_kill_by_neigh() commit 5499e0602d2faafd42c580d25f615903c3fbe11b upstream. x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh(). Fixes: 7781607938c8 ("net/x25: Fix null-ptr-deref caused by x25_disconnect") Cc: stable@vger.kernel.org Signed-off-by: David Lee Assisted-by: Codex:gpt-5.5 Acked-by: Martin Schiller Link: https://patch.msgid.link/20260713104752.241175-1-david.lee@trailofbits.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 40f9a124ebbe0d60fe165fb3f87515c35b2d72f5 Author: Manjunath Patil Date: Tue Jul 7 16:39:11 2026 -0700 net/mlx5e: Use sender devcom for MPV master-up commit e32649b4bad90a6216d8e93cd7dd050af8ac9740 upstream. After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery. Fixes: bf11485f8419 ("net/mlx5: Register mlx5e priv to devcom in MPV mode") Assisted-by: Codex:gpt-5 Signed-off-by: Manjunath Patil Cc: stable@vger.kernel.org # 6.7+ Reviewed-by: Tariq Toukan Link: https://patch.msgid.link/20260707233911.3651139-1-manjunath.b.patil@oracle.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 900cd6d8119b7f3ae5c4bf82f922ff5957df43db Author: Bryam Vargas Date: Tue Jul 7 02:00:54 2026 -0500 net/iucv: fix use-after-free of a severed iucv_path commit be7cc4656eb1f54029610e82d1f0fdd3f9b5ec0a upstream. af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued. Fixes: f0703c80e515 ("[AF_IUCV]: postpone receival of iucv-packets") Closes: https://sashiko.dev/#/patchset/20260705-b4-disp-fc79c0dc-v1-1-d2cdcb57afa9@proton.me?part=1 Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260707-b4-disp-783fedbb-v1-1-463b9dbda2ea@proton.me Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 33736ff5e7c97d3348ce812e8bd2e125d840743c Author: Hidayath Khan Date: Thu Jul 9 21:17:32 2026 +0200 net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() commit 47a5116e56a6b6fe1e909f244e39cd0fc26ceee4 upstream. afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated. Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport") Cc: stable@vger.kernel.org Reviewed-by: Alexandra Winter Signed-off-by: Hidayath Khan Link: https://patch.msgid.link/20260709191732.124092-1-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f8c498585d2a08aa623748353c3e61467b7e9fd2 Author: Doruk Tan Ozturk Date: Thu Jul 16 22:35:00 2026 +0200 geneve: require CAP_NET_ADMIN in the device netns for changelink commit 8efb8f8bbb353b8f2fdf4f37534c6d96c9f69e01 upstream. A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 5b861f6baa3a ("geneve: add rtnl changelink support") Cc: stable@vger.kernel.org Signed-off-by: Doruk Tan Ozturk Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260716203500.70573-3-doruk@0sec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5d07b178bef511d69558cfc89fe1129258dc39f8 Author: Sungmin Kang <726ksm@gmail.com> Date: Sat Jul 18 16:36:30 2026 +0900 net: slip: serialize receive against buffer reallocation commit ee7f9bb9320add61f7b367d7e6cd55e3a3a4d65d upstream. sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Sungmin Kang <726ksm@gmail.com> Link: https://patch.msgid.link/20260718073631.1674-1-726ksm@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 730c7e5fea7f06e0cdf21c547222ec93234fd1d6 Author: Doruk Tan Ozturk Date: Thu Jul 16 22:34:59 2026 +0200 vxlan: require CAP_NET_ADMIN in the device netns for changelink commit 3a61bd9637f3d929aa846e4eb3d98b48c26fcb0e upstream. A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 8bcdc4f3a20b ("vxlan: add changelink support") Cc: stable@vger.kernel.org Signed-off-by: Doruk Tan Ozturk Reviewed-by: Fernando Fernandez Mancera Link: https://patch.msgid.link/20260716203500.70573-2-doruk@0sec.ai Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a48a889b60f73edb0399a8b08284a2ab0bd0295f Author: Breno Leitao Date: Tue Jul 21 01:58:45 2026 -0700 phonet: pep: fix use-after-free in pep_get_sb() commit 0f71f852a96af9685858ce59fda34ecbf85c283d upstream. pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one. Fixes: 9641458d3ec4 ("Phonet: Pipe End Point for Phonet Pipes protocol") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Link: https://patch.msgid.link/20260721-phonet_get_sb_uaf-v1-1-95fd7881cc4e@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 03157872da5ed83c048f7ff686396adb277e257c Author: Markus Breitenberger Date: Mon Jul 13 19:16:19 2026 +0200 net: stmmac: intel: skip SerDes reconfig when rate is unchanged commit 0ab78ead2481adb52f9eb5b403865c529f6f2348 upstream. intel_mac_finish() is registered as the phylink mac_finish() callback for the Elkhart Lake SGMII ports. phylink calls it at the end of every major link reconfiguration, including the initial one during probe. The callback selects the PMC ModPHY LCPLL programming for the requested MAC-side interface and then power-cycles the SerDes. On Elkhart Lake that ModPHY is also used by the on-die AHCI SATA PHY. Reapplying the programming during the initial boot-time link-up disturbs the shared analog block while it is still driving SATA, so the SATA link fails to train: ata1: SATA link down (SStatus 1 SControl 300) The disk carrying the root filesystem is never detected and the system hangs at rootwait. Ethernet itself comes up normally, which makes the failure look unrelated to the network driver. Before mac_finish() runs, the legacy SerDes power-up path has already programmed SERDES_GCR0 for the current interface. The 1G and 2.5G ModPHY tables selected by mac_finish() correspond to the SerDes lane rate, so read that rate back from SERDES_GCR0 and skip the PMC reprogramming and SerDes power-cycle when it already matches the selected interface. This keeps the disruptive reprogramming out of the boot path when the SerDes is configured correctly, while preserving the previous behavior when a real SGMII/1000BASE-X to 2500BASE-X rate change is needed. If the register read fails, reconfigure as before. Fixes: a42f6b3f1cc1 ("net: stmmac: configure SerDes according to the interface mode") Cc: stable@vger.kernel.org Signed-off-by: Markus Breitenberger Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260713171619.192452-1-bre@breiti.cc Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1b44a5f584bffa7cde0d531920ecf981342a2906 Author: Lu Baolu Date: Thu Jul 16 13:35:53 2026 +0800 iommu/vt-d: Disallow SVA if page walk is not coherent commit 780dfed688622ea01be3c9c2c55eec2207f05e04 upstream. Hardware implementations report Scalable-Mode Page-walk Coherency Support via the SMPWCS field in the extended capability register. If the hardware does not support page-walk coherency, a clflush is required every time the page table entries (which are walked by the IOMMU hardware) are updated. In the SVA case, page tables are managed by the CPU mm core, not by the IOMMU driver. Because the IOMMU driver has no way of knowing whether the CPU page table management code has ensured coherency via clflush, the driver must deny SVA if the hardware does not support coherent paging. Fixes: ff3dc6521f78 ("iommu/vt-d: Fix CPU and IOMMU SVM feature matching checks") Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Reviewed-by: Samiullah Khawaja Reviewed-by: Jason Gunthorpe Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 7037e7bdcd26f46c080b8ce307dee5cb471c4b7c Author: Zhang Yi Date: Tue Jul 14 16:23:24 2026 +0800 iomap: fix out-of-bounds bitmap_set() with zero-length range commit 9c7d8f7c8994c790fca501dc45ce66e7356cbe05 upstream. ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op. Fixes: 4ce02c679722 ("iomap: Add per-block dirty state tracking to improve performance") Cc: stable@vger.kernel.org # v6.6 Signed-off-by: Zhang Yi Link: https://patch.msgid.link/20260714082325.325163-5-yi.zhang@huaweicloud.com Reviewed-by: Joanne Koong Reviewed-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit f139498c5ebdd50a2148d4989125846330e2f257 Author: Yitang Yang Date: Wed Jul 22 20:45:51 2026 +0800 io_uring/rw: fix missing ERESTARTSYS conversion in read paths commit ab05caca123c6d0b41850b7c05b246e4dca4a770 upstream. Both read and write may receive internal restart error codes from the filesystem layer and should be converted to -EINTR. However, when multishot read support was added, the error code normalization was lost for both io_read() and io_read_mshot(). Extract the conversion into io_fixup_restart_res() and apply it in all three locations: io_rw_done(), io_read(), and io_read_mshot(). Fixes: a08d195b586a ("io_uring/rw: split io_read() into a helper") Cc: stable@vger.kernel.org Signed-off-by: Yitang Yang Link: https://patch.msgid.link/20260722124551.130563-1-yi1tang.yang@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 65bf73bee1a4f3722208ae46afc0fa5de76b9a0a Author: Tengda Wu Date: Sat Jul 25 02:47:21 2026 +0000 ftrace: Add global mutex to serialize trace_parser access commit 7720b63bcef3f54c7fe288774b720a227d54a306 upstream. In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state. Fixes: e704eff3ff51 ("ftrace: Have set_graph_function handle multiple functions in one write") Fixes: 689fd8b65d66 ("tracing: trace parser support for function and graph") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260725024721.1983675-1-wutengda@huaweicloud.com Signed-off-by: Tengda Wu Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 95376fe9c145be35566991df99c53134943d992f Author: Eric Biggers Date: Sat Jul 18 20:31:20 2026 -0700 fscrypt: Add missing superblock check in find_or_insert_direct_key() commit b5fa40226e71c17847b9ff2816c6ca4133d0d994 upstream. The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent ("per-mode keys"), since the data structures there are per super_block. Fixes: 22e9947a4b2b ("fscrypt: stop holding extra request_queue references") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260717044303.425265-1-ebiggers%40kernel.org Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260719033120.122120-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit a019b074903b3ad0a9726087efd0e8291452023b Author: Amir Goldstein Date: Tue Jul 14 00:09:31 2026 +0200 fs: preserve ACL_DONT_CACHE state in forget_cached_acl() commit 4b9a5458d02e214ef2b384124ca626e3e381d778 upstream. The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 ("fuse: fixes after adapting to new posix acl api") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE. Fixes: facd61053cff1 ("fuse: fixes after adapting to new posix acl api") Cc: stable@vger.kernel.org Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/20260713220932.413004-2-amir73il@gmail.com Reviewed-by: Luis Henriques Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit c78e38745ff1b0457c4551e7f75ea15842df1169 Author: Chen Changcheng Date: Tue Jul 21 14:41:40 2026 +0800 fs/super: fix emergency thaw double-unlock of s_umount commit 503d67fbaec6fdeaba391cb497675071db9d16ea upstream. do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback(). Fixes: 2992476528ae ("super: use a common iterator (Part 1)") Cc: stable@vger.kernel.org Signed-off-by: Chen Changcheng Link: https://patch.msgid.link/20260721064140.152305-1-chenchangcheng@kylinos.cn Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 89b9121c3b0162655fc2f190b714ae64f1aa8cae Author: Christian Brauner Date: Tue Jul 21 13:20:45 2026 +0200 binfmt_elf_fdpic: only honour the first PT_INTERP commit 3349ef6a366a61d631f6a263d12cea240957719d upstream. The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 ("[PATCH] FRV: Add FDPIC ELF binary format driver"). Link: https://patch.msgid.link/20260721-gezittert-medium-kreide-b41fc1f0277e@brauner Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: Jori Koolstra Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit d309f8b52b34ca481600e83359d3fac570b7183a Author: Chancel Liu Date: Fri Jul 10 16:08:35 2026 +0900 ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP commit d091132889c1378dd0944a72f86eae3e4da1e4fa upstream. When the BCLK divider ratio is 1:1, fsl_sai_set_bclk() enables bypass mode by setting BYP, but never clears the bit. The BYP=1 value remains in the regcache, and is restored by regcache_sync() on the next runtime resume. Since BYP=1 combined with BCD=1 immediately outputs the ungated MCLK as BCLK without waiting for BCE/TE/RE to be enabled, the clock is driven prematurely before the stream is fully configured, causing noise on some codecs. Fix this by clearing BYP and BCI in fsl_sai_hw_free() taking into account sync mode and the opposite stream's state, so that the regcache holds BYP=0 before runtime suspend and regcache_sync() on resume will not restore bypass mode prematurely. Fixes: a50b7926d015 ("ASoC: fsl_sai: implement 1:1 bclk:mclk ratio support") Cc: stable@vger.kernel.org Signed-off-by: Chancel Liu Reviewed-by: Shengjiu Wang Link: https://patch.msgid.link/20260710070835.3749817-1-chancel.liu@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c4d77740eca2198dd2c9651db7c6e1dcd3e572eb Author: Chancel Liu Date: Fri Jul 10 12:13:33 2026 +0900 ASoC: fsl: imx-card: Skip sysclk reset for active DAIs in shutdown commit 9f86aea992568c2b4db78c80ff9508af9e050ff7 upstream. In a full-duplex setup, when one direction (playback or capture) is closed while the other is still running, imx_aif_shutdown() was unconditionally calling snd_soc_dai_set_sysclk() with rate=0 for all cpu/codec DAIs, which would disable the clock still needed by the active stream. Add snd_soc_dai_active() checks before clearing sysclk so that only truly inactive DAIs have their clocks reset. Fixes: 2260bc6ea8bd ("ASoC: imx-card: Add WM8524 support") Cc: stable@vger.kernel.org Signed-off-by: Chancel Liu Link: https://patch.msgid.link/20260710031333.3491445-1-chancel.liu@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1a644db2cf59f164cdf3c75995bab5aadc097528 Author: Shihuang Liu Date: Wed Jul 22 19:39:19 2026 +0800 amt: fix use-after-free in AMT delayed works commit ea20c44935d6142daecfa9b39d635033a7553e1b upstream. When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption. amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released. The following is a simple race scenario: CPU0 CPU1 amt_dev_stop() cancel_delayed_work_sync() amt_event_work() mod_delayed_work(req_wq) free netdev req_wq accesses freed amt_dev Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete. The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device. Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface") Cc: stable@vger.kernel.org Signed-off-by: Shihuang Liu Reviewed-by: Simon Horman Reviewed-by: Taehee Yoo Link: https://patch.msgid.link/20260722113919.7723-1-shlomojune6@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8f5a3abc54ba24dbceb14cc3a719908c4f688091 Author: Douya Le Date: Mon Jun 15 14:31:06 2026 +0800 libceph: remove debugfs files before client teardown commit e4c804726c4afce3ba648b982d564f6af2cfa328 upstream. ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown. Cc: stable@vger.kernel.org Fixes: 76aa844d5b2f ("ceph: debugfs") Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Douya Le Signed-off-by: Ren Wei Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 3b2f1937f5fce8b7dd5432e7693e3cc8b5eece56 Author: Douya Le Date: Fri May 29 16:11:44 2026 +0800 libceph: reject zero bucket types in crush_decode commit 05f90284223381005d6bcddab3fda4a97f9c3401 upstream. CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper. Cc: stable@vger.kernel.org Fixes: f24e9980eb86 ("ceph: OSD client") Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Douya Le Signed-off-by: Ren Wei Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit e67e8b694872c9bc66996040f9de9242f6236ed9 Author: Raphael Zimmer Date: Fri May 29 09:42:57 2026 +0200 libceph: Reject monmaps advertising zero monitors commit 40480eee361ed9676b3f844d532ac28b47251634 upstream. A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the "BUG_ON(monc->monmap->num_mon < 1)" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop "log output for unusual values of num_mon" part ] Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 0060ec912292a550198d8d18ac95b433c92a7091 Author: Shuangpeng Bai Date: Mon Jun 29 13:14:22 2026 -0400 libceph: refresh auth->authorizer_buf{,_len} after authorizer update commit 937d61f86d377a3aa578adae7a3dfcecdddf9d89 upstream. ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer. Cc: stable@vger.kernel.org Fixes: 0bed9b5c523d ("libceph: add update_authorizer auth method") Closes: https://lore.kernel.org/all/E378850E-106C-427B-A241-970EB2D054D7@gmail.com/ Signed-off-by: Shuangpeng Bai Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 4716a64b7cc2797741f7be4e283ace78a9dff37d Author: Zhao Zhang Date: Fri Jun 19 15:40:03 2026 +0800 libceph: guard missing CRUSH type name lookup commit bbeae12fda3384a90fbebc8a19ba9d33f85b5361 upstream. Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to "not local". [ idryomov: add WARN_ON_ONCE ] Cc: stable@vger.kernel.org Fixes: 117d96a04f00 ("libceph: support for balanced and localized reads") Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Zhao Zhang Signed-off-by: Ren Wei Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 1732d89dfcd74f6fde9ce70900d316c4a151c153 Author: Raphael Zimmer Date: Wed May 27 16:06:17 2026 +0200 libceph: Fix multiplication overflow in decode_new_up_state_weight() commit 98917a499ec7064c14fc56d180a4fd636fc2784c upstream. If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ] Cc: stable@vger.kernel.org Fixes: 930c53286977 ("libceph: apply new_state before new_up_client on incrementals") Signed-off-by: Raphael Zimmer Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 4e7ebfaa0d14cf50e44041bfde38070d6dbc019f Author: Douya Le Date: Sun Jun 7 17:35:49 2026 +0800 libceph: bound get_version reply decode to front len commit d3c32939fa0e3ee9b883b9a0fd1972c5c444e3d0 upstream. handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire. Cc: stable@vger.kernel.org Fixes: 513a8243d67f ("libceph: mon_get_version request infrastructure") Reported-by: Yuan Tan Reported-by: Zhengchuan Liang Reported-by: Xin Liu Assisted-by: Codex:GPT-5.4 Signed-off-by: Douya Le Signed-off-by: Ren Wei Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 7d03e08b763fd67cf796da3026b2597ce0035bba Author: Wentao Liang Date: Thu Jun 4 02:19:51 2026 +0000 ceph: fix writeback_count leak in write_folio_nounlock() commit cbf59617cd715219e84c50d106a3d0e1e8ba054e upstream. write_folio_nounlock() increments fsc->writeback_count to track in-flight writeback operations. On several error paths where the function returns early (folio lookup failure, snapshot context allocation failure, and writepages submission failure), the function returns without calling atomic_long_dec_return() to decrement the counter. Each leaked increment keeps the counter above zero, which can prevent the filesystem from cleanly unmounting or suspending writes. Add atomic_long_dec_return() calls on all error paths that currently return without decrementing the counter. Cc: stable@vger.kernel.org Fixes: d55207717ded ("ceph: add encryption support to writepage and writepages") Signed-off-by: Wentao Liang Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit a7c2dfa610a12ac725d51290b550133a89a0c466 Author: WenTao Liang Date: Thu Jun 11 22:40:07 2026 +0800 ceph: fix refcount leak in ceph_readdir() commit c3e64079d8b9663e3998d0caac9aba915b6b93ae upstream. The ceph_readdir() function allocates a ceph_mds_request via ceph_mdsc_create_request() and stores it in dfi->last_readdir. In the directory entry processing loop, if the entry's offset is less than ctx->pos or if the inode pointer is unexpectedly NULL, the function returns -EIO without releasing the reference held by dfi->last_readdir, causing a refcount leak. Fix this by adding ceph_mdsc_put_request(dfi->last_readdir) before returning on these error paths. Also set dfi->last_readdir to NULL for safety, matching the cleanup done at the normal exit. Cc: stable@vger.kernel.org Fixes: af9ffa6df7e3 ("ceph: add support to readdir for encrypted names") Signed-off-by: WenTao Liang Reviewed-by: Viacheslav Dubeyko Reviewed-by: Alex Markuze Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit a4228b93706fb74a484e6ffb271c1cc2af3a2ddb Author: Bryam Vargas Date: Fri May 29 00:37:24 2026 +0000 ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() commit 4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02 upstream. ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path. Cc: stable@vger.kernel.org Fixes: a8599bd821d0 ("ceph: capability management") Signed-off-by: Bryam Vargas Reviewed-by: Viacheslav Dubeyko Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 3bf0e349cbb4f975f35eb22753acc346b89c66a0 Author: Zhiling Zou Date: Wed Jul 15 09:50:11 2026 +0800 sctp: close UDP tunnel sockets during netns teardown commit ffb2bd7ade36ec4da32c46a6eddbf4515316d08c upstream. proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed. Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/b9f1f02b0780ad6a719e2413f5f0bb8eb7702d94.1782585631.git.roxy520tt%40gmail.com Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Acked-by: Xin Long Link: https://patch.msgid.link/6dab75f22855cb219e2e30a5497cab03b970ab91.1784033357.git.roxy520tt@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit be6aae9d1b91c603adb35872d37d40e83daf8758 Author: Zhiling Zou Date: Wed Jul 15 09:50:10 2026 +0800 sctp: avoid auth_enable sysctl UAF during netns teardown commit f8d5e7846025f4ab15a461235f8ebae9094a361a upstream. proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper. Fixes: 15649fd5415e ("sctp: sysctl: auth_enable: avoid using current->nsproxy") Cc: stable@vger.kernel.org Reported-by: Yuan Tan Reported-by: Yifan Wu Reported-by: Juefei Pu Reported-by: Xin Liu Co-developed-by: Qi Tang Signed-off-by: Qi Tang Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Acked-by: Xin Long Link: https://patch.msgid.link/390cd5e91ed60eea27b0b64d0468301a9e73b808.1784033357.git.roxy520tt@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 85aca407c560aba81b5ce9d3d6cf94c74077d19b Author: Jun Yang Date: Tue Jul 21 21:14:05 2026 +0800 sctp: don't free the ASCONF's own transport in DEL-IP processing commit 9b2854f86f0b56e9027d68e7a3fc909d1a9b566f upstream. sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport. Fixes: 42e30bf3463c ("[SCTP]: Handle the wildcard ADD-IP Address parameter") Cc: stable@kernel.org Signed-off-by: Jun Yang Acked-by: Xin Long Link: https://patch.msgid.link/tencent_73762ED1DF08CC9D5F5F61954B01350CFE0A@qq.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3db217a4c2bdc87642b314a527e06f12e67608f6 Author: Rik van Riel Date: Wed Jul 1 13:42:34 2026 -0400 mm/huge_memory: set PG_has_hwpoisoned only after new folio head is established commit e1cd30eceb6908fc13bebce41283b885d71ee8d6 upstream. __split_folio_to_order() copies the hwpoison state onto each new sub-folio while splitting a folio to a non-zero order. It does so via if (handle_hwpoison && page_range_has_hwpoisoned(new_head, new_nr_pages)) folio_set_has_hwpoisoned(new_folio); *before* clear_compound_head(new_head)/prep_compound_page(new_head, ...) turns @new_head from a tail page into a proper folio head. PG_has_hwpoisoned is a FOLIO_SECOND_PAGE flag, so folio_set_has_hwpoisoned() resolves to folio_flags(folio, 1). With the new compound_info-based page-flags layout, folio_flags() asserts the page is not a tail: VM_BUG_ON_PGFLAGS(page->compound_info & 1, page); VM_BUG_ON_PGFLAGS(n > 0 && !test_bit(PG_head, &page->flags.f), page); At the current call site @new_head still has the tail marker (compound_info bit 0 set, PG_head clear), so on CONFIG_DEBUG_VM kernels this hits: kernel BUG at include/linux/page-flags.h:354 folio_flags+0x82 folio_set_has_hwpoisoned __split_folio_to_order __split_unmapped_folio __folio_split truncate_inode_partial_folio (shmem hole-punch / MADV_REMOVE) Reproduced by syzkaller: hwpoison-inject a few subpages of a large shmem folio, then MADV_REMOVE (fallocate punch hole) on the same range, which splits the partial folio to a non-zero order. memory_failure() tries to split the poisoned folio to order 0 first, but that split is best-effort; when it fails the folio is left large with PG_has_hwpoisoned set, the case fa5a06170036 added this hwpoison copying for. Move the folio_set_has_hwpoisoned() call to after clear_compound_head()/prep_compound_page(), where @new_folio is a real order-new_order head folio (handle_hwpoison implies new_order != 0, so a second page always exists). The flag still lands on the same struct page (page[1] of the new folio); only the ordering relative to compound-head setup changes, satisfying the FOLIO_SECOND_PAGE precondition. Link: https://lore.kernel.org/20260701174235.3173401-1-riel@surriel.com Fixes: fa5a06170036 ("mm/huge_memory: preserve PG_has_hwpoisoned if a folio is split to >0 order") Signed-off-by: Rik van Riel Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Zi Yan Acked-by: David Hildenbrand (Arm) Tested-by: Lance Yang Reviewed-by: Lorenzo Stoakes Reviewed-by: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Nico Pache Cc: Ryan Roberts Cc: Yang Shi Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ac7a6f61f56fe99ca9a53ef0754403a9e46622e4 Author: Breno Leitao Date: Fri Jul 3 09:17:24 2026 -0700 mm/kmemleak: fix checksum computation for per-cpu objects commit 79c37ae3733e93d9d8ea12ecb44f717e61439024 upstream. The per-cpu object checksum folds each CPU's CRC together with XOR and seeds every CRC with 0. Both choices make update_checksum() miss content changes: - XOR is self-cancelling, so equal contents on two CPUs cancel out and simultaneous identical changes leave the checksum unchanged. - crc32(0, ...) over all-zero content is 0, so a freshly allocated, zeroed per-cpu area checksums to 0, matching the initial value, and the object is never seen to change. See discussions at [0]. When update_checksum() wrongly reports an actively modified object as unchanged, kmemleak stops greying it for an extra scan and can report a live per-cpu object as a leak. Fold the per-cpu CRC as a single rolling checksum across all CPUs and initialise the object checksum to ~0 so the first computed value always registers as a change, even for content that hashes to 0. reset_checksum() is seeded the same way. Link: https://lore.kernel.org/all/akfYImSNDh3OjIfR@gmail.com [0] Link: https://lore.kernel.org/20260703-kmemleak_checksum-v1-1-5e0ab7d6966f@debian.org Fixes: 6c99d4eb7c5e ("kmemleak: enable tracking for percpu pointers") Signed-off-by: Breno Leitao Co-developed-by: Catalin Marinas Signed-off-by: Catalin Marinas Reviewed-by: Pavel Tikhomirov Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f2b293359924117736218701ebd8b40618d73e6f Author: David Howells Date: Mon Jul 13 16:22:55 2026 +0100 afs: Fix afs_edit_dir_remove() to get, not find, block 0 commit 62d9853aa4ce6e9797b6949804891be14b219752 upstream. Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather than afs_dir_find_block() as the latter caches the found block in the afs_dir_iter and may[*] switch out the page it's on if another afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does. [*] There's more than one block per page. Fixes: a5b5beebcf96 ("afs: Use the contained hashtable to search a directory") Closes: https://sashiko.dev/#/patchset/20260706153408.1231650-1-dhowells%40redhat.com Signed-off-by: David Howells Link: https://patch.msgid.link/2380759.1783956175@warthog.procyon.org.uk cc: Marc Dionne cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit d64f6c02495f3fad674038cfa7ec049671b59e7b Author: Geliang Tang Date: Wed Jul 22 00:14:39 2026 +0200 mptcp: pm: userspace: fix use-after-free in get_local_id commit 9bc6d5e4ca9f3cbb41d43400b3a31cb0403796c9 upstream. In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a "not found" sentinel. Fixes: f012d796a6de ("mptcp: check addrs list in userspace_pm_get_local_id") Cc: stable@vger.kernel.org Signed-off-by: Geliang Tang Tested-by: Xuanqiang Luo Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-2-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6cd3c3d631555efee8831b7e0f95ea5a67f99fbe Author: Michael Bommarito Date: Thu Jul 9 15:19:25 2026 -0400 mptcp: only set DATA_FIN when a mapping is present commit b2ff91b752b0d85e8815e7f44fd85205c4268094 upstream. mptcp_get_options() clears only the status group of struct mptcp_options_received; data_seq, subflow_seq and data_len are filled in by mptcp_parse_option() exclusively inside the DSS mapping block, which runs only when the DSS M (mapping present) bit is set. A peer can send a DSS option with the DATA_FIN flag set but the mapping bit clear. The parser then records mp_opt->data_fin while leaving data_len and data_seq uninitialized. For a zero-length segment mptcp_incoming_options() evaluates if (mp_opt.data_fin && mp_opt.data_len == 1 && mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64)) which reads the uninitialized data_len and data_seq; KMSAN reports an uninit-value in mptcp_incoming_options(). The stale data_seq can also be fed into the receive-side DATA_FIN sequence tracking. Record the DATA_FIN flag only when the DSS option carries a mapping, so data_fin is never set without data_seq and data_len also being present. data_fin is part of the status group that mptcp_get_options() clears up front, so on the no-map path it stays zero and the zero-length DATA_FIN branch is simply skipped. A DATA_FIN is always transmitted together with a mapping (mptcp_write_data_fin() sets use_map along with data_seq and data_len), so legitimate DATA_FIN handling is unaffected. Move the pr_debug() that logs the parsed DSS flags below the mapping block, so it reports the final data_fin value instead of the stale one it would otherwise print before the assignment. Fixes: 43b54c6ee382 ("mptcp: Use full MPTCP-level disconnect state machine") Suggested-by: Paolo Abeni Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito Reviewed-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260709191925.2811195-1-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6c936b5ad557e55cdae9869a2c7bd9e1324ac38b Author: Chenguang Zhao Date: Wed Jul 22 00:14:38 2026 +0200 mptcp: decrement subflows counter on failed passive join commit f3ca0ee2cc308e33896536789cbc5f3a12ca7b30 upstream. mptcp_pm_allow_new_subflow() increments extra_subflows before __mptcp_finish_join() on the passive MP_JOIN path. In case of race conditions, the subflow is dropped without calling mptcp_close_ssk(), so the counter is not rolled back. Call mptcp_pm_close_subflow() when the join completion fails to decrement the subflows counter. Fixes: 10f6d46c943d ("mptcp: fix race between MP_JOIN and close") Cc: stable@vger.kernel.org Signed-off-by: Chenguang Zhao Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-1-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 35c4b274d4cc4e3c953c5a58e4a3b66951d0a1ce Author: Will Deacon Date: Fri Jul 17 17:25:58 2026 +0100 Revert "arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates" commit 26b483d52417253d88a3a01262ac85914a7aec8e upstream. This reverts commit e057b94772328221405b067c3a85fe479b915dc8. Sashiko points out that updating 'orig_x0' after secure_computing() has returned is too late to handle the case where a seccomp filter is re-evaluated after initially returning SECCOMP_RET_TRACE. This means that a tracer can manipulate the first argument of the syscall behind seccomp's back. For now, revert the initial fix and we'll have another crack at it soon. Since the incorrect fix was cc'd to stable, do the same here with an appropriate fixes tag. Cc: stable@vger.kernel.org Fixes: e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates") Link: https://sashiko.dev/#/patchset/20260716120640.6590-1-will@kernel.org Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 64ab0964c7db949abbd3c56268a220e2b77f7b9e Author: Will Deacon Date: Thu Jul 16 13:06:39 2026 +0100 arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates commit e057b94772328221405b067c3a85fe479b915dc8 upstream. When seccomp support was originally added to arm64 in a1ae65b21941 ("arm64: add seccomp support"), seccomp was erroneously called _before_ the ptrace syscall-enter-stop and therefore the tracer could trivially manipulate the syscall register state after the seccomp check had passed. This was subsequently fixed in a5cd110cb836 ("arm64/ptrace: run seccomp after ptrace") by moving the seccomp check after the tracer has run. Unfortunately, a decade later, that fix has been reported to be incomplete. On arm64, both the first argument to a syscall and its eventual return value are allocated to register x0. In order to facilitate syscall restarting and querying of syscall arguments on the syscall exit path, the original value of x0 is stashed in 'struct pt_regs::orig_x0' early during the syscall entry path and is returned for the first argument by syscall_get_arguments(). Unlike 32-bit Arm, this stashed value is not directly exposed via ptrace() and so changes to register x0 made by the tracer on a syscall-enter-stop are not reflected in 'orig_x0'. This means that seccomp, syscall tracepoints and audit can observe a stale value for the register compared to the argument that will be observed by the actual syscall. Re-sync 'orig_x0' from x0 on the syscall entry path following a potential ptrace stop (i.e. PTRACE_EVENTMSG_SYSCALL_ENTRY or SECCOMP_RET_TRACE). This behaviour is limited to native tasks (because compat tasks expose 'orig_r0' to ptrace) where the syscall is not being skipped (because x0 is updated to hold the return value of -ENOSYS in that case). Cc: Kees Cook Cc: Jinjie Ruan Cc: Mark Rutland Cc: stable@vger.kernel.org Reported-by: Yiqi Sun Link: https://lore.kernel.org/all/20260529065444.1336608-1-sunyiqixm@gmail.com/ Suggested-by: Catalin Marinas Fixes: a5cd110cb836 ("arm64/ptrace: run seccomp after ptrace") Reviewed-by: Jinjie Ruan Tested-by: Jinjie Ruan Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 9cd4b1a52eff330798d668c1775f8bc450776280 Author: Dev Jain Date: Fri Jul 3 11:41:54 2026 +0000 arm64: make huge_ptep_get handled unaligned addresses commit f73a8edc2ccc6ec72c37d5c578e7592d2e1f9922 upstream. huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma). The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic. Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block. Fixes: 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms") Cc: stable@vger.kernel.org Acked-by: David Hildenbrand (Arm) Signed-off-by: Dev Jain Acked-by: Muchun Song Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 9025946adec9a97d6cd599c718be0056fa182020 Author: Masami Hiramatsu (Google) Date: Mon Jul 20 19:12:20 2026 +0900 tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err() commit a9d6fb284039a5d3858a1d9f9a0d7e46cfb7c2d4 upstream. If trace_probe_log.argc is 0 in __trace_probe_log_err(), the loop constructing the command string will not execute and p will remain equal to command. Writing to *(p - 1) will cause an out-of-bounds access before command. This should not happen, but better to be treated. Reject if trace_probe_log.argc is 0. Link: https://lore.kernel.org/all/178454233992.290363.18323091580600697731.stgit@devnote2/ Fixes: ab105a4fb894 ("tracing: Use tracing error_log with probe events") Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 3b3be8653c594d394c0c2763140d865477c4bd8b Author: Masami Hiramatsu (Google) Date: Mon Jul 20 19:12:29 2026 +0900 tracing/probes: Fix potential underflow in LEN_OR_ZERO macro commit 8ce20bfba48902e1382187cd1a852f7cf3a1e739 upstream. In __set_print_fmt(), LEN_OR_ZERO is defined as (len ? len - pos : 0). If len is non-zero but smaller than pos, len - pos evaluates to a negative integer. When passed as a size argument to snprintf(), this negative value is cast to a large unsigned size_t, bypassing buffer size limits. Ensure len > pos before subtracting to avoid integer underflow. Link: https://lore.kernel.org/all/178454234934.290363.15247317871499514139.stgit@devnote2/ Fixes: 5bf652aaf46c ("tracing/probes: Integrate duplicate set_print_fmt()") Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 949ac1aeb37b87e93660dcf89459f018f0c62ee2 Author: Masami Hiramatsu (Google) Date: Mon Jul 20 19:12:10 2026 +0900 tracing/probes: Avoid temporary buffer truncation in trace_probe_match_command_args() commit 15f197856d68882af9416fc97516bb55079b7677 upstream. In trace_probe_match_command_args(), a stack buffer buf[MAX_ARGSTR_LEN + 1] (256 bytes) is used to format "=". However, since name can be up to 32 bytes (MAX_ARG_NAME_LEN) and comm up to 255 bytes (MAX_ARGSTR_LEN), the formatted string can exceed 256 bytes and get truncated by snprintf(), causing spurious argument matching failures. Instead of formatting into a temporary buffer on stack, compare the argument name, the '=' delimiter, and the comm expression directly. Link: https://lore.kernel.org/all/178454233010.290363.10428767141343428804.stgit@devnote2/ Fixes: eb5bf81330a7 ("tracing/kprobe: Add per-probe delete from event") Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 6b5098d7458117fb67b188fbac07a5ce6546ffe2 Author: Masami Hiramatsu (Google) Date: Mon Jul 20 19:12:38 2026 +0900 tracing/eprobe: Fix exact system name matching in eprobe_dyn_event_match() commit f418d68d71fd4a0a9cef92377bc8c4c3334b5b53 upstream. eprobe_dyn_event_match() checks if the target event system in argv[0] matches ep->event_system using strncmp(ep->event_system, argv[0], len). However, if ep->event_system is longer than len (e.g. "eprobes" vs "ep/event"), strncmp() still returns 0 because the first len characters match. Check that ep->event_system[len] is '\0' to ensure exact system name matching. Link: https://lore.kernel.org/all/178454235856.290363.14872590900774231133.stgit@devnote2/ Fixes: 7d5fda1c841f ("tracing: Fix event probe removal from dynamic events") Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit b6a4575f22925da7e6aa00171e9fc0e5029c0bc9 Author: Masami Hiramatsu (Google) Date: Fri Jul 17 11:51:49 2026 +0900 tracing: Fix union collision of module and refcnt for dynamic events commit b4eb07bde606c2096b24252be589e735eff6d413 upstream. In 'struct trace_event_call', the 'module' pointer and the 'refcnt' atomic variable share the same memory space in a union. For dynamic events, the union member is 'refcnt', which acts as an active reference counter. When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or wprobe) has a non-zero reference count (e.g. due to active event triggers or perf attachments), its 'call->module' evaluates to a small non-zero integer instead of NULL. When filtering or setting events for a specific module (e.g., writing ':mod:' to 'set_event'), the code in '__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads 'call->module' directly without checking whether the event is dynamic. This causes the kernel to treat the small integer (refcnt) as a 'struct module' pointer, leading to a NULL/invalid pointer dereference (Oops) when dereferencing the module name. Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked before treating 'call->module' as a valid pointer in these code paths. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/178425670947.84440.11344393611899824907.stgit@devnote2 Fixes: 4c86bc531e60 ("tracing: Add :mod: command to enabled module events") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit cf5a82bef623b969a609f2b7e392d06dbae34aa6 Author: deepakraog Date: Wed Jul 15 20:06:04 2026 +0530 tracing: Fix resource leak on mmiotrace trace_pipe close commit c1d87e724ae55e781b7cc7ccafb34d9e668582b2 upstream. The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak. Cc: stable@vger.kernel.org Fixes: c521efd1700a8 ("tracing: Add pipe_close interface) Link: https://patch.msgid.link/20260715143604.14481-1-gaikwad.dcg@gmail.com Signed-off-by: deepakraog Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 8464427e1c177809a9488a97dfa2807d9dcf323b Author: Steven Rostedt Date: Tue Jul 21 21:11:43 2026 -0400 tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev commit 144f29e85702234b23d2a62abf723e6a17eb5427 upstream. If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260721211143.36dbd559@gandalf.local.home Fixes: f984b51e0779 ("ftrace: add mmiotrace plugin") Reported-by: Sashiko Link: https://sashiko.dev/#/patchset/20260715143604.14481-1-gaikwad.dcg%40gmail.com Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 1f2e7cd0ff9766983650dfa9b3e4d231ccd1ce37 Author: Usama Arif Date: Fri Jul 17 10:32:52 2026 -0700 tracing: Fix context switch counter truncation commit 8f76afb9b114bee1c1251e0e52553e9dc7c59f20 upstream. trace_user_fault_read() samples nr_context_switches_cpu() before enabling preemption and retries the user copy if the counter changes. The helper returns unsigned long long because rq->nr_switches is u64, but the saved value is unsigned int. Once a CPU has performed 2^32 context switches, assigning the counter to cnt discards its upper bits. The comparison after the copy promotes cnt back to unsigned long long, but the lost bits remain zero, so it reports a change even when the task was never scheduled out. Every retry then fails the same way until the 100-try guard warns and the user copy is abandoned. This affects long-running systems and workloads with high context-switch rates. A CPU switching 1,000 times per second takes about 50 days. Store the sampled count in unsigned long long so the full value is preserved. Cc: stable@vger.kernel.org Fixes: 64cf7d058a00 ("tracing: Have trace_marker use per-cpu data to read user space") Link: https://patch.msgid.link/20260717173252.3431565-1-usama.arif@linux.dev Reported-by: Breno Leitao Signed-off-by: Usama Arif Acked-by: Masami Hiramatsu (Google) Reviewed-by: Breno Leitao Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 1da310b94504d42001e9c32c43c5dc105b777e5f Author: Xu Rao Date: Mon Jul 13 13:55:23 2026 +0800 misc: nsm: pin the module while the device is open commit 3b231f1e9990f4c21220d0a69733ce2105891ff9 upstream. misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations. Fixes: b9873755a6c8 ("misc: Add Nitro Secure Module driver") Cc: stable Signed-off-by: Xu Rao Link: https://patch.msgid.link/BE6951D13B5E5513+20260713055523.3193089-1-raoxu@uniontech.com Signed-off-by: Greg Kroah-Hartman commit 8f068342096b027181b168d91fef7ac7a2c64b25 Author: Runyu Xiao Date: Wed Jun 17 22:53:50 2026 +0800 misc: nsm: only unlock nsm_dev on post-lock error paths commit ce1fed11d18e163baf7f875152a33bf80f625c1a upstream. nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only. Fixes: b9873755a6c8 ("misc: Add Nitro Secure Module driver") Cc: stable Signed-off-by: Runyu Xiao Reviewed-by: Alexander Graf Link: https://patch.msgid.link/20260617145350.513875-1-runyu.xiao@seu.edu.cn Signed-off-by: Greg Kroah-Hartman commit caba30eb8bd321c465ecfc7d850ee85f5b353496 Author: Guangshuo Li Date: Wed Jul 15 15:08:51 2026 +0800 intel_th: fix MSC output device reference leak commit 761b785a0cfbce43761227bc42a7f984f31f8921 upstream. intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da ("intel_th: fix device leak on output open()") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops. Fixes: 95fc36a234da ("intel_th: fix device leak on output open()") Cc: stable Signed-off-by: Guangshuo Li Reviewed-by: Johan Hovold Link: https://patch.msgid.link/20260715070851.2077965-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 59dd34854202d9a3faaa87a85205e553fe7150e1 Author: Alexander Usyskin Date: Sun Jul 5 18:12:59 2026 +0300 mei: bus: access mei_device under device_lock on cleanup commit f112ea910e554d58b4b39a4492b7d302f0f4204f upstream. Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too. Cc: stable Fixes: 35e8a426b16a ("mei: bus: Check for still connected devices in mei_cl_bus_dev_release()") Reviewed-by: Menachem Adin Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20260705151259.3054795-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 5118872357279cd2a83d5435bc062831a41d0f52 Author: Ethan Nelson-Moore Date: Tue Jun 9 10:55:04 2026 -0700 selftests: ntsync: correct CONFIG_NTSYNC name commit f97752cfe511c1ed9933057455c73aaac07d6517 upstream. The config fragment for these tests defines CONFIG_WINESYNC, which refers to an earlier name for the ntsync driver before it was merged [1]. Correct it to define CONFIG_NTSYNC instead. [1] https://lore.kernel.org/all/f4cc1a38-1441-62f8-47e4-0c67f5ad1d43@codeweavers.com/ Fixes: 7f853a252cde ("selftests: ntsync: Add some tests for semaphore state.") Cc: stable Signed-off-by: Ethan Nelson-Moore Reviewed-by: Elizabeth Figura Link: https://patch.msgid.link/20260609175505.19632-1-enelsonmoore@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit b2a3eeb57ba24f8a0e34a69d40adcc63e5b9ca56 Author: Jiangshan Yi Date: Wed Jul 15 15:35:46 2026 +0800 serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms commit 7fb13fd7e9a59a37cd911efff83abe19e3ee029d upstream. Commit b1b4efea05a5 ("serial: 8250_mid: Disable DMA for selected platforms") replaced the dnv_board setup and exit callbacks with PTR_IF(false, ...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. Fix this by adding the missing NULL checks before calling the setup and exit callbacks. Fixes: b1b4efea05a5 ("serial: 8250_mid: Disable DMA for selected platforms") Cc: stable Reviewed-by: Andy Shevchenko Signed-off-by: Jiangshan Yi Link: https://patch.msgid.link/20260715073546.1875083-1-yijiangshan@kylinos.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 4fae473b856b49fb1c166da1052a66d126d80166 Author: Hugo Villeneuve Date: Thu Jul 16 17:08:09 2026 -0400 serial: sc16is7xx: implement gpio get_direction() callback commit af071d9e07e57cfff239e8d09d2f3b05ebc9c667 upstream. It's strongly recommended for GPIO drivers to always implement the .get_direction() callback - even when the direction is tracked in software. The GPIO core emits a warning when the callback is missing and a user reads the direction of a line, e.g. via /sys/kernel/debug/gpio. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable Signed-off-by: Hugo Villeneuve Acked-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260716210813.2582826-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 635be8b097f0c5851083ff4287dbd5d756c093d9 Author: Ben Hutchings Date: Mon May 25 14:04:22 2026 +0200 uio_hv_generic: Bind to FCopy device by default commit 87d3621ccc63b3999d756bb59f0cedd738c28eb3 upstream. The Hyper-V kernel-mode fcopy driver was removed in 6.10 and the new fcopy daemon requires this uio driver to function. However, by default the driver does not bind to any devices, and must be configured through the sysfs "new_id" file. Since the FCopy device is now only usable through this driver, add its ID to the driver's ID table so that the daemon will work "out of the box". Signed-off-by: Ben Hutchings Fixes: ec314f61e4fc ("Drivers: hv: Remove fcopy driver") Cc: stable Link: https://patch.msgid.link/ahQ6xuhSReidmN-3@decadent.org.uk Signed-off-by: Greg Kroah-Hartman commit cf26dd2d841583c54a87005c4934b92fddb930c3 Author: Ian Abbott Date: Wed May 27 13:51:03 2026 +0100 comedi: comedi_parport: deal with premature interrupt commit 17221216ae8ce6a24e8a4e787382e3ebc81b88a8 upstream. Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the "comedi_parport" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi "attach" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't. Fixes: 241ab6ad7108e ("Staging: comedi: add comedi_parport driver") Reported-by: syzbot+f24c3d5d316011bacc70@syzkaller.appspotmail.com Cc: stable Signed-off-by: Ian Abbott Link: https://patch.msgid.link/20260527125104.96596-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 9bb71b59e0aa385c3efcb565acc5cb4af749ea2d Author: Nathan Chancellor Date: Wed Jul 22 17:09:43 2026 -0700 x86/boot/compressed: Disable jump tables commit 4a9ec5ec9555ad62dc5b81a37ac946025c2ea002 upstream. After a recent upstream LLVM change to start generating jump and lookup tables in switch statements in more instances [1], linking the compressed x86 boot image when CONFIG_KERNEL_ZSTD is enabled fails with: ld.lld: error: Unexpected run-time relocations (.rela) detected! Dumping the relocations in misc.o, which is the only file influenced by CONFIG_KERNEL_ZSTD in the decompressor, shows dynamic relocations to some string constants, which correspond to the string literals in the switch statement in handle_zstd_error(): Relocation section '.rela.data.rel.ro' at offset 0x277b0 contains 31 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000000000 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 73a 0000000000000008 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e 0000000000000010 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e 0000000000000018 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e ... This optimization is problematic for the decompressor environment, as it is built as -fPIE without any explicit absolute references (as described at the top of misc.c) while not applying any dynamic relocations, hence the linker assertion. To opt out of this optimization, which is of little value in this special early boot code, and to mirror the other x86 startup code in arch/x86/boot/startup, disable jump tables in the decompressor. Signed-off-by: Nathan Chancellor Signed-off-by: Ingo Molnar Acked-by: Ard Biesheuvel Cc: Bill Wendling Cc: Justin Stitt Cc: Nick Desaulniers Cc: "H. Peter Anvin" Cc: Peter Zijlstra Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/fa02a6ed66b1700c996b49c96c6bc0eb014c9518 [1] Link: https://patch.msgid.link/20260722-x86-boot-compressed-disable-jt-clang-v2-1-7373d38482fb@kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/2165 Signed-off-by: Greg Kroah-Hartman commit 4f2db41a09eba7a45abd140bb86ffc519c191886 Author: Tze Yee Ng Date: Wed Jun 24 03:06:35 2026 -0700 firmware: stratix10-svc: fix memory leaks and list corruption bugs commit 9119ceb76e987c2ec2b549ea100e3268ce3a1c7c upstream. Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups. Fixes: 7ca5ce896524 ("firmware: add Intel Stratix10 service layer driver") Cc: stable@vger.kernel.org # 5.0+ Signed-off-by: Tze Yee Ng Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit 3ff7c1dbf722cf3fa538672452ba182318e0fcc3 Author: Cen Zhang (Microsoft) Date: Tue Jul 7 12:41:15 2026 -0400 rhashtable: clear stale iter->p on table restart commit 8173f7e2ce67e6ca1d4763f3da14e5b01ce77456 upstream. rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0 Fixes: 5d240a8936f6 ("rhashtable: improve rhashtable_walk stability when stop/start used.") Cc: Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Yuan Tan Closes: https://lore.kernel.org/linux-crypto/CAB8m9Wh559e+=n8z51gB8DrbEyCc2mc0MgGjrRR6_VXBmU=2AQ@mail.gmail.com Signed-off-by: Cen Zhang (Microsoft) Reviewed-by: NeilBrown Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit d43c5c0c935522deae7339e0c2399365f3bf0016 Author: Xu Rao Date: Mon Jul 20 20:44:21 2026 +0100 cdrom: fix stack out-of-bounds read in CDROMVOLCTRL commit b27e195d4db8dea263050bdbeb11881b2999c9c6 upstream. mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Xu Rao Signed-off-by: Phillip Potter Link: https://patch.msgid.link/20260720194421.1497-2-phil@philpotter.co.uk Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4427a33faabb4b81511b99dfee18ce0a38b5b5df Author: Rong Bao Date: Thu Jul 23 22:27:29 2026 +0800 LoongArch: Retrieve CPU package ID from PPTT when available commit 4e8f58620f6717f72f3d88a2c8f25c0c656d0ba7 upstream. Currently, the LoongArch CPU topology initialization code calculates each core's package ID by dividing its physical ID by loongson_sysconf. cores_per_package. This relies on the assumption that cores_per_package counts in the same domain as physical IDs. On Loongson-3B6000 (XB612B0V_1.2), cores_per_package matches the visible core count -- 24 in this case. However, the physical IDs range from 0 to 31 in a noncontinuous fashion: $ cat /proc/cpuinfo | grep -i -F 'global_id' global_id : 0 global_id : 1 global_id : 4 global_id : 5 global_id : 6 global_id : 7 global_id : 8 global_id : 9 global_id : 10 global_id : 11 global_id : 14 global_id : 15 global_id : 16 global_id : 17 global_id : 20 global_id : 21 global_id : 22 global_id : 23 global_id : 26 global_id : 27 global_id : 28 global_id : 29 global_id : 30 global_id : 31 Retrieve the exact package ID from ACPI PPTT when available, in the same style as retrieving the core ID and thread ID in parse_acpi_topology(). Use this information in loongson_init_secondary() when the PPTT readout is successful. The original division logic is kept as a fallback. Meanwhile, since some existing code paths like loongson3_cpufreq expect a continuous integer sequence of package IDs in [0, MAX_PACKAGES) when retrieving from cpu_data[], here we also canonicalize the package ID to be filled in parse_acpi_topology() to meet such an expectation. Cc: stable@vger.kernel.org Tested-by: Mingcong Bai Co-developed-by: Xi Ruoyao Signed-off-by: Xi Ruoyao Signed-off-by: Rong Bao Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 38b025fcdc45bdf5140a5726a1fbb2e694ea047b Author: Kanglong Wang Date: Thu Jul 23 22:27:29 2026 +0800 LoongArch: Move jump_label_init() before parse_early_param() commit ea68d444a658783234a06f05414e41cf93a18fb2 upstream. When enabling both CONFIG_MEM_ALLOC_PROFILING=y and CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=y, then diabling memory profiling by adding the boot parameter 'sysctl.vm.mem_profiling=0' will cause the kernel failed to boot. After analysis, this is because jump_label_init() must be called before parse_early_param(), the early param handlers may modify static keys by static_branch_enable/disable(). Fix this by moving jump_label_init() to before parse_early_param(). The solution is similar to other architectures. Cc: Signed-off-by: Kanglong Wang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 6ab0abb5a2e0c2493817f8cc446c1a033c222768 Author: Haoran Jiang Date: Thu Jul 23 22:27:30 2026 +0800 LoongArch: Fix oops during single-step debugging commit 73555fdab5e1e4f24ca000c41a616b34edf4b55d upstream. When entering KDB via a breakpoint and then performing single-step debugging, an oops is triggered. Now during single-step debugging, kdb_local() expects the reason to be KDB_REASON_SSTEP, but it is actually KDB_REASON_OOPS. In kdb_stub(), when determining the reason, the ex_vector for single-step should be 0, as already implemented on other architectures such as arm64 and riscv. Before the patch: [112]kdb> ss Entering kdb (current=0x900020009f520000, pid 10661) on processor 112 Oops: (null) due to oops @ 0x90000000005b57a4 Cc: stable@vger.kernel.org Signed-off-by: Haoran Jiang Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit a94d6726ec8680a2b0c453fc782a543f68a1ea06 Author: George Guo Date: Thu Jul 23 22:27:30 2026 +0800 LoongArch: Fix address space mismatch in kexec command line lookup commit 485ed44db5694d8d2e5027f63ad608e705286f30 upstream. When searching the loaded segments for the "kexec" command line marker, the kexec_load(2) path (file_mode == 0) passes the user-space segment buffer straight to strncmp() through a bogus (char __user *) cast. This dereferences a user pointer in kernel context, which is wrong and is flagged by sparse: arch/loongarch/kernel/machine_kexec.c:84:51: sparse: incorrect type in argument 2 (different address spaces) @@ expected char const * @@ got char [noderef] __user * Here copy the marker-sized prefix of each segment into a small on-stack buffer with copy_from_user() before comparing, and skip segments that fault. The subsequent copy_from_user() that stages the full command line into the safe area is left unchanged. Cc: stable@vger.kernel.org Fixes: 4a03b2ac06a5 ("LoongArch: Add kexec support") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202605051639.aEPioXdD-lkp@intel.com/ Co-developed-by: Kexin Liu Signed-off-by: Kexin Liu Signed-off-by: George Guo Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit c404b1f30b252f26eb2ae940f15e706235414dec Author: Miguel Ojeda Date: Fri Jul 10 19:32:52 2026 +0200 objtool/rust: add one more `noreturn` Rust function for Rust 1.99.0 commit 5a81c35c3b18cd59ded56171a6a9f643b92a6759 upstream. Starting with Rust 1.99.0 (expected 2026-10-01), under `CONFIG_RUST_DEBUG_ASSERTIONS=y`, `objtool` may report: rust/kernel.o: warning: objtool: _R..._6kernel12module_param9set_paramaEB4_() falls through to next function _R..._6kernel12module_param9set_paramhEB4_() (and many others) due to calls to the `noreturn` symbol [1]: core::panicking::panic_null_reference_constructed Thus add the mangled one to the list so that `objtool` knows it is actually `noreturn`. See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions") for more details. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: Petr Pavlu Link: https://github.com/rust-lang/rust/pull/158796 [1] Reported-by: Alice Ryhl Closes: https://lore.kernel.org/rust-for-linux/alEBInX9gD1M5NAr@google.com/ Reviewed-by: Alice Ryhl Tested-by: Alice Ryhl Link: https://patch.msgid.link/20260710173252.191781-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 8ccfb3b315a0edb4383347d77b5e9d11df404837 Author: Alexandre Courbot Date: Wed Jul 8 19:49:26 2026 +0900 rust: allow `clippy::unwrap_or_default` globally commit 4688cf884b3abcd12498e03b625d1916bf49a1e4 upstream. Starting with rustc 1.88, the `clippy::unwrap_or_default` lint triggers on `rust/kernel/soc.rs` if `CONFIG_CC_OPTIMIZE_FOR_SIZE=y`: warning: use of `unwrap_or` to construct default value --> ../rust/kernel/soc.rs:66:10 | 66 | .unwrap_or(core::ptr::null()) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `unwrap_or_default()` This is a clippy bug [1]: the lint decides whether an expression is equivalent to `Default::default()` by inspecting the optimized MIR of `<*const T as Default>::default` exported by `core`, so its outcome depends on the optimization level `core` was built with. Moreover, its suggestion ignores our MSRV of 1.85 (`Default` for `*const T` is only stable since Rust 1.88), so we could not apply it anyway. Disable the lint globally rather than working around this single occurrence; it can be re-enabled conditionally using `rustc-min-version` once clippy is fixed. Link: https://github.com/rust-lang/rust-clippy/issues/17379 [1] Suggested-by: Miguel Ojeda Signed-off-by: Alexandre Courbot Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://patch.msgid.link/20260708-soc_unwrap_or-v2-1-007ed724cc7b@nvidia.com [ Moved to non-versioned group. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 6db0c42c87c46e15f381a124bb553e3b4878fbdd Author: FUJITA Tomonori Date: Tue Jul 14 07:52:35 2026 +0900 rust: time: fix as_micros_ceil() to round correctly for negative Delta commit 880c43b185ca52239e75bc546cc4f4d9154d0fed upstream. The ceiling-division idiom `(n + d - 1) / d` only produces the correct result when `n` is non-negative. For example, if n = -1000 (exactly -1us), the old code computed (-1000 + 999) / 1000 == 0 instead of -1. For negative n, truncating division already rounds towards positive infinity, so no bias is needed in that case. Fixes: fae0cdc12340 ("rust: time: Introduce Delta type") Signed-off-by: FUJITA Tomonori Acked-by: Andreas Hindborg Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260713225235.3243480-1-tomo@flapping.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 12be1d75e9b29b387088aa729f8b79563ada400d Author: Alice Ryhl Date: Wed Jul 8 12:00:26 2026 +0000 rust_binder: only print failure if error has source commit bb66b1a3452534adb8b72abf2f761375970fe472 upstream. The commit that fixes BINDER_GET_EXTENDED_ERROR changed the condition for printing transaction failures so errors are printed even if the cause is a dead or frozen process. Undo this change so that the error is only printed if the failure has an errno associated with it. Cc: stable@kernel.org Fixes: 77bfebf11077 ("rust_binder: fix BINDER_GET_EXTENDED_ERROR") Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260708-get-extended-error-fix-printing-v1-1-6e293b213b70@google.com Signed-off-by: Greg Kroah-Hartman commit cc3bbff10b1a73121ada1cb06d5a5f66ecee6c13 Author: Zixing Liu Date: Fri Jul 24 16:33:14 2026 +0800 platform/loongarch: laptop: Explicitly reset bl_powered state when suspend commit 91a70492c03040d51b36f595530d6491d5d6c541 upstream. On EAECIS NL60R with EC firmware version 1.11, resuming from S3 has a very high chance (>90%) of causing the EC to lose the previous backlight power state. When this happens, the laptop resumes normally from S3, but the backlight remains off (when shining on the screen with a flash light, we can see the screen contents are updating normally). Since there is no generic way to query the EC's backlight state on Loongson laptop platforms, assume the worst-case scenario and restart the backlight power inside the kernel each time the system resumes. Cc: stable@vger.kernel.org Fixes: 53c762b47f72 ("platform/loongarch: laptop: Add backlight power control support") Tested-by: Yao Zi Tested-by: Xi Ruoyao Signed-off-by: Zixing Liu Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 1cd4e9b7967dab48c9f79a00b06ffff7208c0993 Author: Christian Brauner Date: Mon Jul 20 14:36:49 2026 +0200 binfmt_misc: set have_execfd only once the interpreter is opened commit bbf5f639918dc011aaf60aab8480218758ee68c5 upstream. load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting. Link: https://patch.msgid.link/20260720-beglichen-kognitiv-organismus-5e1e55326c56@brauner Fixes: bc2bf338d54b ("exec: Remove recursion from search_binary_handler") Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 2bc6bf70d41055377f390d06f0f3521deb62fd3b Author: Christian Brauner Date: Tue Jul 21 12:08:49 2026 +0200 exec: fix unsigned loop counter wrap in transfer_args_to_stack() commit 16cc4f5c1c4b9e45eca7f7deefa5410a292db599 upstream. The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 ("elf_fdpic_transfer_args_to_stack(): make it generic") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2. Link: https://patch.msgid.link/20260721-hochachtung-staumauer-pigmente-15d71f7d7d04@brauner Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reviewed-by: David Hildenbrand (Arm) Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Greg Kroah-Hartman commit 780b04d09c941262ee2a2b4a09906451b69df8a6 Author: Chengfeng Ye Date: Mon Jul 20 00:03:11 2026 +0800 Bluetooth: RFCOMM: Fix session UAF in set_termios commit c783399efc22d035443f1dfbf2a09bf9562aaa5e upstream. rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send. Fixes: 3a5e903c09ae ("[Bluetooth]: Implement RFCOMM remote port negotiation") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit a42f5536ea9c00e13f0c0fbb330feed95e2365ca Author: Chengfeng Ye Date: Mon Jul 20 00:24:27 2026 +0800 Bluetooth: hci_sync: Protect UUID list traversal commit e9027ffbf5a0f3c12ca8900822e884eae9f0821b upstream. The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion. Fixes: 161510ccf91c ("Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 1") Cc: stable@vger.kernel.org Signed-off-by: Chengfeng Ye Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 91eff666c9078921e88d518b517cbfcf948bd85e Author: MinJea Kim Date: Tue Jul 14 22:14:21 2026 +0900 staging: rtl8723bs: fix inverted HT40 secondary channel offset commit 30d49cba27f8905bc288cef5846963f0004f644c upstream. rtw_get_chan_type() maps the driver's channel offset to nl80211 channel types the wrong way around. In this driver HAL_PRIME_CHNL_OFFSET_LOWER means the primary channel is the lower 20 MHz half of the 40 MHz pair, i.e. the secondary channel is above the primary one: rtw_get_center_ch() computes the center channel as "channel + 2" for OFFSET_LOWER, and bwmode_update_check() sets OFFSET_LOWER when the AP's HT operation IE announces SCA (secondary channel above). In nl80211 terms that is NL80211_CHAN_HT40PLUS, not HT40MINUS. Because of the inversion, cfg80211_rtw_get_channel() reports an HT40+ association as HT40-. For an HT40+ AP on a low channel (e.g. channel 3) the resulting chandef spans below the 2.4 GHz band edge and is invalid, so the regulatory core tears the connection down 60 seconds (REG_ENFORCE_GRACE_MS) after the AP's country IE triggers a regdomain change: reg_check_chans_work() considers the reported chandef unusable and calls cfg80211_leave(). The supplicant then reconnects, the country IE changes the regdomain again, and the cycle repeats, causing a disconnect/reconnect loop every ~65 seconds for as long as the link is up. Observed on a TECLAST X80 Power tablet (RTL8723BS) associated to an HT40+ AP on channel 3 with a KR country IE; a kprobe trace showed cfg80211_disconnect() being invoked from reg_check_chans_work(). With the mapping fixed, "iw dev wlan0 info" reports the correct "width: 40 MHz, center1: 2432 MHz" and the periodic disconnects stop. Fixes: 5402cc178c5d ("staging: rtl8723bs: add get_channel cfg80211 implementation") Cc: stable@vger.kernel.org Assisted-by: Claude-Code:claude-fable-5 bpftrace Signed-off-by: MinJea Kim Link: https://patch.msgid.link/20260714131421.3980-1-qndkdrnl@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 875479f18835ac11e21a83e88f3d4dc7ccdcd0c4 Author: Moksh Panicker Date: Thu Jun 25 20:29:11 2026 +0000 staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() commit 0e95ff792ae0aa6fbad9455943e9e1e4062670e9 upstream. rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable Signed-off-by: Moksh Panicker Link: https://patch.msgid.link/20260625202911.26782-1-mokshpanicker.7@gmail.com Signed-off-by: Greg Kroah-Hartman commit 0dbaff14fd6a8b7bbfe7e1379b17be0ffe4ffaf8 Author: Wentao Liang Date: Tue Jun 9 09:25:28 2026 +0000 wifi: ath11k: fix refcount leak in ath11k_ahb_fw_resources_init() commit 0e120ee0822b7cc650bd7b29682a34e137cec10d upstream. of_get_child_by_name() returns a node pointer with refcount incremented, but the error path when ath11k_ahb_setup_msa_resources() fails does not release it. Add the missing of_node_put() to avoid leaking the reference. Cc: stable@vger.kernel.org Fixes: 095cb947490c ("wifi: ath11k: allow missing memory-regions") Signed-off-by: Wentao Liang Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260609092528.220547-1-vulab@iscas.ac.cn Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit efe9de178e4b965eed6da080588294f4ad1d07b7 Author: LiangCheng Wang Date: Wed Jul 15 14:49:38 2026 +0800 wifi: brcmfmac: set F2 blocksize to 256 for BCM43752 commit 29ab31f3f27157648f2f7e6d5e1fd9792fdf0614 upstream. The BCM43752 is not reliable with the default 512-byte SDIO function 2 block size: on an i.MX8MP board with an AMPAK AP6275S module at SDR104 / 200 MHz, an iperf TX stress test kills WLAN within seconds: mmc_submit_one: CMD53 sg block write failed -84 brcmf_sdio_dpc: failed backplane access over SDIO, halting operation Commit d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization") set up the 43752 like the 4373 for the F2 watermark but missed the F2 block size, which the 4373 limits to 256 bytes. The vendor driver (bcmdhd) also programs a 256-byte F2 block size for this chip and runs the same hardware without errors. Group the 43752 with the 4373, matching the F2 watermark handling. With this change a 10-minute bidirectional iperf3 soak completes with zero SDIO errors at ~270 Mbit/s in each direction. Backporting note: kernels before v6.18 name this id SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752, so on those trees the case label added by this patch must be adjusted to that name. Cherry-picking the rename commit 74e2ef72bd4b ("wifi: brcmfmac: fix 43752 SDIO FWVID incorrectly labelled as Cypress (CYW)") first is not a clean alternative: on trees before v6.17 its context collides with the 43751 additions, and trees before v6.2 lack the FWVID framework it touches. Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization") Cc: stable@vger.kernel.org # see patch description, needs adjustments for <= 6.17 Signed-off-by: LiangCheng Wang Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260715-b43752-f2-blksz-v2-1-f9be49856050@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 044fca8f45ba9ab6ca526163155234cf88287ff5 Author: Fan Wu Date: Sat Jul 18 02:43:52 2026 +0000 wifi: brcmfmac: make release_scratchbuffers idempotent commit 538c51e9d124cf656f2dd0c0394a8545efc7102d upstream. brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool. Fixes: 4684997d9eea ("brcmfmac: reset PCIe bus on a firmware crash") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu Assisted-by: Codex:gpt-5.6 Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260718024353.3147201-2-fanwu01@zju.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 9cb72f67e1502aabba51aab9ac04ae7c386ee194 Author: Devin Wittmayer Date: Sat Jun 27 12:13:35 2026 -0700 wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses commit feeff151c83e7f0ffcdedcad5343852d23d1f6e1 upstream. PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for non-mmio devices"). Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Cc: stable@vger.kernel.org Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260627191336.20223-3-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 263816e92e8d66c81c98ccab2b5d2191ed08ec71 Author: Devin Wittmayer Date: Sat Jun 27 12:13:34 2026 -0700 wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses commit da4082e91acabc1498611ed8ccc53f0610baefc6 upstream. PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for non-mmio devices"). Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support") Cc: stable@vger.kernel.org Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260627191336.20223-2-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit ab4d213393e846baa6437497f94dda7553cbeda7 Author: Devin Wittmayer Date: Sat Jun 27 12:13:36 2026 -0700 wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses commit 39afc46c0243d10b7795e6e6cf4ae91f41732120 upstream. PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for non-mmio devices"). Fixes: eb99cc95c3b6 ("mt76: mt7615: introduce mt7663u support") Cc: stable@vger.kernel.org Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260627191336.20223-4-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit e511e93abd6eeedcd5b3c55516241f414fbde64a Author: Huihui Huang Date: Tue Jul 14 17:17:58 2026 +0800 wifi: wilc1000: validate assoc response length before subtracting header commit 4c4c97b60a5e978121d9ee8cb0ab3916e5d6a8de upstream. wilc_parse_assoc_resp_info() computes the trailing IE length as ies_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a "conn_info->status == WLAN_STATUS_SUCCESS" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association. Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Huihui Huang Link: https://patch.msgid.link/20260714091811.3596126-1-hhhuang@smu.edu.sg Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 9375a4ea4121625ef27a46b74781cda66a5cc61b Author: Doruk Tan Ozturk Date: Thu Jul 16 12:30:42 2026 +0200 wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper commit c3d68e294cbb6a4090bb219d3dcaca85a011809b upstream. mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: if (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && bss_desc->bcn_ht_cap && ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai). Fixes: 396939f94084 ("mwifiex: add HT operation IE in TDLS setup confirm") Cc: stable@vger.kernel.org Assisted-by: 0sec:multi-model Signed-off-by: Doruk Tan Ozturk Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260716103042.88469-1-doruk@0sec.ai Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 18965470d41e69d3fc10eb62afae29d10f4cdfd1 Author: Daniel Hodges Date: Fri Feb 6 13:52:07 2026 -0500 wifi: ath6kl: fix use-after-free in aggr_reset_state() commit ba7debb4dd6427386862220e8335a53a4bfc235d upstream. The aggr_reset_state() function uses timer_delete() (non-synchronous) for the aggregation timer before proceeding to delete TID state and before the structure is freed by callers like aggr_module_destroy(). If the timer callback (aggr_timeout) is executing when aggr_reset_state() is called, the callback will continue to access aggr_conn fields like rx_tid[] and stat[] which may be freed immediately after by kfree(aggr_info->aggr_conn) in aggr_module_destroy(). Additionally, the timer callback can re-arm itself via mod_timer() while aggr_reset_state() is running, creating a more complex race condition. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Cc: stable@vger.kernel.org Signed-off-by: Daniel Hodges Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20260206185207.30098-1-git@danielhodges.dev Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit 58c6c8dc2e022e1b4f3dc58725a1ca49ff470f9c Author: Tristan Madani Date: Thu Jul 2 00:50:20 2026 +0000 wifi: ath6kl: fix OOB access from firmware ADDBA window size commit 44126b6994eeb28f2103b638e698f40a1244f327 upstream. aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Cc: stable@vger.kernel.org Reviewed-by: Vasanthakumar Thiagarajan Signed-off-by: Tristan Madani Link: https://patch.msgid.link/20260702005020.708717-1-tristmd@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit 1395327a96614885552bae5fbb650e6dd182d49b Author: Norbert Szetei Date: Mon Jul 20 09:09:55 2026 +0200 ALSA: timer: don't re-enter an instance callback that is still running commit 70d28bfcd6224eed75986b3b987b997e59643fa4 upstream. The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost. Fixes: 37745918e0e7 ("ALSA: timer: Introduce virtual userspace-driven timers") Cc: stable@vger.kernel.org Suggested-by: Takashi Iwai Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Norbert Szetei Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/6F9B6501-8E65-4265-B02C-7EFB240D1664@doyensec.com Signed-off-by: Greg Kroah-Hartman commit 426c0ff1c433d6030610ad4f9375746dfe931caa Author: Norbert Szetei Date: Mon Jul 20 09:14:12 2026 +0200 ALSA: timer: drain a slave's callback before its master detaches it commit bdefe1346a8e6b8dc8593406dc2617e985fcbcab upstream. snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight. Fixes: 37745918e0e7 ("ALSA: timer: Introduce virtual userspace-driven timers") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Norbert Szetei Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/D26598EB-DBF7-4D76-9F71-8E4BD59822D4@doyensec.com Signed-off-by: Greg Kroah-Hartman commit 3bc4de57fc7d11371f95fff652bfb0e5ce9f4386 Author: Kai Vehmanen Date: Wed Jul 15 21:06:10 2026 +0300 ALSA: hda: codecs: hdmi: disable keep-alive before audio format change commit a3d6d3cedfe87bbd5a677d52b22ac20d28e59cf8 upstream. When a keep-alive (KAE) silent stream is active on an Intel HDMI/DP codec, opening a real PCM stream reprograms the converter format and the audio infoframe in snd_hda_hdmi_generic_pcm_prepare(). Part of that reprogramming - the converter channel count and the channel mapping in snd_hda_hdmi_setup_audio_infoframe() - is not safe to do while a keep-alive stream is active. This is most visible when switching to a multichannel PCM configuration, where the active channel count actually changes. In that case the newly opened PCM stream plays no sound. Add an optional hdmi_ops .prepare hook, called at the start of the PCM prepare sequence (before the format and infoframe are touched), and implement it for HSW+ to release keep-alive. Keep-alive is then re-enabled as before once the new stream has been set up, in the setup_stream op. Fixes: 15175a4f2bbb ("ALSA: hda/hdmi: add keep-alive support for ADL-P and DG2") Reported-by: Alexander Kaplan Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8412 Tested-by: Alexander Kaplan Cc: Signed-off-by: Kai Vehmanen Link: https://patch.msgid.link/20260715180610.1371243-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6a10025c7fd09a7d2af37a3ae1da188569fce470 Author: Norbert Szetei Date: Tue Jul 14 10:29:23 2026 +0200 ALSA: seq: close a re-opened queue timer in the destructor commit 2c4dc0ed50b05cd847a4b34b8cebf0775f19aeb9 upstream. queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Norbert Szetei Link: https://patch.msgid.link/422FDB81-2A68-47C7-A22D-2D3301E2E86D@doyensec.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2ec8f95a08fed5882a74f8f98169ab20d3fcf873 Author: Nikita Maksimov Date: Mon Jul 20 21:02:14 2026 +0300 ALSA: hda/realtek: Fix speakers on Lunnen Ground 14 commit 5c3f8dac531b454bf67b6ee3c2aac89f0aaaef74 upstream. The firmware on the Lunnen Ground 14 marks pin 0x1b as unused even though the internal speakers are connected to it. As a result, the speakers are not detected. Add a pin configuration quirk for PCI subsystem ID 2782:a212 to configure pin 0x1b as an internal speaker. The pin configuration was tested on a Lunnen Ground 14 (DMI product LL4FA) with an ALC269VC codec. The internal speakers and microphone work as expected. Cc: stable@vger.kernel.org Signed-off-by: Nikita Maksimov Link: https://patch.msgid.link/20260720180214.73770-1-nickstogramm@yandex.ru Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4091b216d11b3ed787b18786e1fe9156a9ad6cbb Author: Johan Hovold Date: Tue Apr 7 12:08:31 2026 +0200 media: vpif_capture: fix OF node reference imbalance commit 2282f979560af6bbc8ee2c1ee8663197312cee5b upstream. The driver reuses the OF node of the parent device but fails to take another reference to balance the one dropped by the platform bus code when unbinding the parent and releasing the child devices. Fix this by using the intended helper for reusing OF nodes. Fixes: 4a5f8ae50b66 ("[media] davinci: vpif_capture: get subdevs from DT when available") Cc: stable@vger.kernel.org # 4.13 Cc: Kevin Hilman Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 1349af7f87df57940619f5b87990b799dac9ed8a Author: Guangshuo Li Date: Thu Apr 16 00:20:58 2026 +0800 media: vivid: fix cleanup bugs in vivid_init() commit a07c179a92e949172ca52f6d4a13202ea88cd4b7 upstream. When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection. Fixes: f46d740fb0258 ("[media] vivid: turn this into a platform_device") Fixes: d7c969f37515d ("media: vivid: Add 'Is Connected To' menu controls") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 492c97cb50feaa60ccd7792d3d6b904ed8ec61bf Author: Hans Verkuil Date: Wed May 20 09:22:41 2026 +0200 media: vivid: check for vb2_is_busy() when toggling caps commit c2d1a2130c93f6d758af58590b86b2254c7a1dec upstream. The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless. Reviewed-by: Nicolas Dufresne Fixes: 73c3f48230cd ("[media] vivid: add the control handling code") Cc: stable@vger.kernel.org Reported-by: syzbot+dac8f5eaa46837e97b89@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 26e7a8ac286f3a5ab326dd7ed23b60c4fde20e81 Author: Hans Verkuil Date: Wed May 20 09:30:44 2026 +0200 media: vivid: add vivid_update_reduced_fps() commit 1d793a29efb4260f90913f5287939bf95573b073 upstream. Don't call vivid_update_format_cap() when switching to/from reduced fps for HDMI inputs: that will also reset the format, which is overkill for this. Make a new vivid_update_reduced_fps() function that just updates the dev->timeperframe_vid_cap. Reviewed-by: Nicolas Dufresne Fixes: c79aa6aeadb0 ("[media] vivid-capture: add control for reduced frame rate") Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 3780ad3810718bf749151e8187bbc3c374619085 Author: Guangshuo Li Date: Wed Apr 15 23:45:37 2026 +0800 media: vimc: fix reference leak on failed device registration commit 33e2b833c66b890a0d71c4fa82d4c97143f7f75f upstream. When platform_device_register() fails in vimc_init(), the embedded struct device in vimc_pdev has already been initialized by device_initialize(), but the failure path returns the error without dropping the device reference for the current platform device: vimc_init() -> platform_device_register(&vimc_pdev) -> device_initialize(&vimc_pdev.dev) -> setup_pdev_dma_masks(&vimc_pdev) -> platform_device_add(&vimc_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: 4babf057c143f ("media: vimc: allocate vimc_device dynamically") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 86ece01fba2d5555c421ea94777fab592d2a0962 Author: Guangshuo Li Date: Wed Apr 15 23:28:26 2026 +0800 media: vidtv: fix reference leak on failed device registration commit 9aa21e1549db8882ff77b691e7714153df21dff0 upstream. When platform_device_register() fails in vidtv_bridge_init(), the embedded struct device in vidtv_bridge_dev has already been initialized by device_initialize(), but the failure path returns the error without dropping the device reference for the current platform device: vidtv_bridge_init() -> platform_device_register(&vidtv_bridge_dev) -> device_initialize(&vidtv_bridge_dev.dev) -> setup_pdev_dma_masks(&vidtv_bridge_dev) -> platform_device_add(&vidtv_bridge_dev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fixes: f90cf6079bf67 ("media: vidtv: add a bridge driver") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 16ae8c166e78757a46d7b7884f810a348b3d13c9 Author: Benjamin Gaignard Date: Tue Jun 24 14:29:38 2025 +0200 media: verisilicon: Export only needed pixels formats commit e0f5d6ae76423ec5b6f97c7c3e1f02187b988afd upstream. Some pixel formats can only be produced if the decoder outputs reference pictures directly. In some cases, such as AV1 film-grain, the use of the post-processor is strictly required. In this case, only enumerate the post-processor supported formats. The exception is when V4L2_FMTDESC_FLAG_ENUM_ALL is set, in this case, we enumerate everything regardless of the state. Signed-off-by: Benjamin Gaignard Fixes: bcd4f091cf1e ("media: verisilicon: Use V4L2_FMTDESC_FLAG_ENUM_ALL flag") Cc: stable@vger.kernel.org Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b88c929188e3c4e4ea7b9310419ada411189e9a3 Author: Zile Xiong Date: Fri Mar 20 14:54:45 2026 +0800 media: vb2: use ssize_t for vb2_read/vb2_write commit a562d6dc86bdfdd299e1b4734977a8d63e803583 upstream. vb2_read() and vb2_write() return size_t, but propagate negative errno values from __vb2_perform_fileio(). This relies on implicit signed/unsigned conversions in callers (e.g. vb2_fop_read()) to recover error codes: __vb2_perform_fileio() -> -EINVAL vb2_read() -> (size_t)-EINVAL vb2_fop_read() -> -EINVAL This relies on implicit conversions that are not obvious. These helpers are exported (EXPORT_SYMBOL_GPL) and part of the vb2 API, so changing their return type may affect existing users. However, they conceptually follow read/write semantics, where ssize_t is typically used to return either a byte count or a negative error code. Switch vb2_read() and vb2_write() to ssize_t, and update __vb2_perform_fileio() accordingly. Signed-off-by: Zile Xiong Acked-by: Marek Szyprowski Fixes: b25748fe6126 ("[media] v4l: videobuf2: add read() and write() emulator") Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 072a883061a461ff1d1b6a5de171ce8a85e0c9f2 Author: Sakari Ailus Date: Sat Mar 21 23:41:50 2026 +0200 media: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely commit 0bcbfd1c1142d85faef8df5cb679d37f71394c5f upstream. If a sub-device does not set enable_streams() and disable_streams() pad ops while it sets the s_stream() video op to v4l2_subdev_s_stream_helper(), enabling or disabling streaming either way on the sub-device will result calling v4l2_subdev_s_stream_helper() and v4l2_subdev_{enable,disable}_streams() recursively, exhausting the stack. Return -ENOIOCTLCMD in this case to handle the situation gracefully. Fixes: b62949ddaa52 ("media: subdev: Support single-stream case in v4l2_subdev_enable/disable_streams()") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Laurent Pinchart Signed-off-by: Greg Kroah-Hartman commit cf9732fd6c4f2f803ccfc46d89489b6635590270 Author: Mirela Rabulea Date: Fri May 22 17:31:20 2026 +0300 media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() commit 06cb687a5132fcffe624c0070576ab852ac6b568 upstream. The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal. Fixes: aef69d54755d ("media: v4l: fwnode: Add a convenience function for registering sensors") Cc: stable@vger.kernel.org Suggested-by: Frank Li Link: https://lore.kernel.org/linux-media/20240315073125.275501-2-sakari.ailus@linux.intel.com/ Signed-off-by: Mirela Rabulea Reviewed-by: Laurent Pinchart Reviewed-by: Frank Li Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 3068ab802fc98b121dcb451e1f7f4d338ffc7a19 Author: Pengpeng Hou Date: Tue Mar 24 11:13:26 2026 +0800 media: v4l2-ctrls: validate HEVC active reference counts commit afbe4bc252d90a6f8fad869b06d5430f615f22f9 upstream. HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts. Fixes: d395a78db9eab ("media: hevc: Add decode params control") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Reviewed-by: Nicolas Dufresne Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 836cfffb2ddbbf0f703efef8440bad544238172b Author: Sergey Shtylyov Date: Fri May 1 23:28:31 2026 +0300 media: v4l2-ctrls-request: add NULL check in v4l2_ctrl_request_complete() commit caced3578bf9f104a4aaad8f46c4c719e705d9a6 upstream. If CONFIG_MEDIA_CONTROLLER is undefined, media_request_object_find() will always return NULL, so its 2nd call in v4l2_ctrl_request_complete() would fail as well as the 1st one and thus cause hdl to have a wrong value (at the top of memory) and list_for_each_entry() to iterate over the garbage data located there. Add NULL check for the 2nd call and place the error cleanup at the end of v4l2_ctrl_request_complete()... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: c3bf5129f339 ("media: v4l2-ctrls: always copy the controls on completion") Cc: stable@vger.kernel.org Signed-off-by: Sergey Shtylyov Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 7e6521dd747eca3cb3d4cd3ddcf20f266494f63d Author: Myeonghun Pak Date: Sun Apr 26 22:16:31 2026 +0900 media: ti: vpe: unwind v4l2 device registration on probe error commit e0f1c9a90ef665f2587c274a8fed59f2dfc575a6 upstream. If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register(). Fixes: 4d59c7d45585 ("media: ti-vpe: vpe: Add missing null pointer checks") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Reviewed-by: Yemike Abhilash Chandra Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 127fc44e83256e713e8e9e2716c95b0e560a1bad Author: Hungyu Lin Date: Thu May 7 02:22:13 2026 +0000 media: tegra-video: vi: fix invalid u32 return value in format lookup commit d5b50055338e131a1a99f923ebb0361974a00f36 upstream. tegra_get_format_fourcc_by_idx() returns a u32 but uses -EINVAL to signal an out-of-bounds index. This results in a large unsigned value being returned, which may be interpreted as a valid fourcc. Returning 0 is not a valid fourcc either. This condition should never happen, so use WARN_ON_ONCE() to catch unexpected out-of-bounds access and return a valid fallback format instead. Suggested-by: Hans Verkuil Fixes: 3d8a97eabef0 ("media: tegra-video: Add Tegra210 Video input driver") Cc: stable@vger.kernel.org Reviewed-by: Luca Ceresoli Signed-off-by: Hungyu Lin Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 118c2f5d1d3639835917edd5962ac14ea4b08d1f Author: Dmitry Osipenko Date: Wed Mar 25 13:57:42 2026 +0300 media: synopsys: hdmirx: Fix HPD lane hold time commit d1162a5adbb5e95953d460b5bde3a04cd4473fe9 upstream. Increase time of holding HPD lane low by 50ms. This fixes EDID change not detected by source/display side. Fixes: 7b59b132ad43 ("media: platform: synopsys: Add support for HDMI input driver") Cc: stable@vger.kernel.org Reported-by: Ross Cawston Closes: https://lore.kernel.org/linux-rockchip/20260209061654.54757-1-ross@r-sc.ca/ Signed-off-by: Dmitry Osipenko Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b5184b3f0e9d4cc47059ba1138c9a73d43d2493f Author: Valery Borovsky Date: Mon May 11 20:12:11 2026 +0300 media: sun4i-csi: Return queued buffers on start_streaming() failure commit bbba3e260a62810a717b4442a3bb96d0ec0f6309 upstream. The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure"). Fixes: 577bbf23b758 ("media: sunxi: Add A10 CSI driver") Cc: stable@vger.kernel.org Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 931abe1deb65b919d23fa203d7f6d6fbd4fccd8e Author: Myeonghun Pak Date: Sun Apr 26 21:43:49 2026 +0900 media: stm32: dcmi: unregister notifier on probe failure commit 084973ebd67b28f0945c5d45408f86c58b540110 upstream. dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. Signed-off-by: Myeonghun Pak Signed-off-by: Hans Verkuil Fixes: d079f94c9046 ("media: platform: Switch to v4l2_async_notifier_add_subdev") Cc: stable@vger.kernel.org [hverkuil: added Fixes tag] Signed-off-by: Greg Kroah-Hartman commit ed342a86bb2f9c1b44a0fc4f6b08c14073946e4f Author: Valery Borovsky Date: Mon May 11 20:12:10 2026 +0300 media: stm32-dcmipp: Return queued buffers on start_streaming() failure commit ffc8eec06378a340d708c889184ab3e14b57d540 upstream. The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. dcmipp_bytecap_start_streaming() returned -EINVAL when the source subdevice could not be resolved from the media graph, before pm_runtime_resume_and_get() and media_pipeline_start() had been called. The remaining error paths already converge on the err_buffer_done label, which calls dcmipp_bytecap_all_buffers_done(..., VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate err_pm_put / err_media_pipeline_stop labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure"). Fixes: 28e0f3772296 ("media: stm32-dcmipp: STM32 DCMIPP camera interface driver") Cc: stable@vger.kernel.org Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b7936e8cbec1b96b126058eeb005e5b9111df38e Author: Ma Ke Date: Thu Apr 2 15:35:29 2026 +0800 media: saa7134: Fix a possible memory leak in saa7134_video_init1 commit f86ed548386e3050e5f8f25b450d09dc009d9a88 upstream. In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review. Signed-off-by: Ma Ke Cc: stable@vger.kernel.org Fixes: a00e68888d5d ("[media] saa7134: move saa7134_pgtable to saa7134_dmaqueue") Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a7a141e4e93c8bca495c3195989bb6b731d39934 Author: Tommaso Merciai Date: Tue Dec 30 18:09:15 2025 +0100 media: rzg2l-cru: Skip ICnMC configuration when ICnSVC is used commit cd4ce68875f406b0cf3f5a94c0fd22989689222f upstream. When the CRU is configured to use ICnSVC for virtual channel mapping, as on the RZ/{G3E, V2H/P} SoC, the ICnMC register must not be programmed. Return early after setting up ICnSVC to avoid overriding the ICnMC register, which is not applicable in this mode. This prevents unintended register programming when ICnSVC is enabled. Cc: stable@vger.kernel.org Fixes: 3c5ca0a48bb0 ("media: rzg2l-cru: Drop function pointer to configure CSI") Signed-off-by: Tommaso Merciai [Rework to not break image format programming] Signed-off-by: Jacopo Mondi Reviewed-by: Lad Prabhakar Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 894e83509c66910112b9eaeaa8cd66cd9806db91 Author: Valery Borovsky Date: Mon May 11 20:12:09 2026 +0300 media: rtl2832_sdr: Return queued buffers on start_streaming() failure commit 33ca0aab6f4bd90921fc1395478f38f72c4d19af upstream. The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and "return ret". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here. 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 2c71bda6edc630a1f8c3c45d8df5fc22d234e042 Author: Deepanshu Kartikey Date: Wed Apr 22 20:17:34 2026 +0530 media: rtl2832: fix use-after-free in rtl2832_remove() commit 680daf40a82d483949f87f0d8f98639dc47e610c upstream. cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final. Fixes: cddcc40b1b15 ("[media] rtl2832: convert to use an explicit i2c mux core") Cc: stable@vger.kernel.org Reported-by: syzbot+019ced393ab913002b75@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=019ced393ab913002b75 Signed-off-by: Deepanshu Kartikey Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 64cb15878b35e5574ff4f80a0b613a79e47867ba Author: Myeonghun Pak Date: Wed May 13 16:02:37 2026 +0900 media: radio-si476x: Unregister v4l2_device on probe failure commit 436a693af04ffb889aaf87cb69ec1f2b21d3569c upstream. si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls. Fixes: b879a9c2a755 ("[media] v4l2: Add a V4L2 driver for SI476X MFD") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a58d01a0ed3977e9048b70ba5714fd94220922e9 Author: Bryan O'Donoghue Date: Tue Apr 7 11:34:54 2026 +0100 media: qcom: camss: Fix RDI streaming for CSID GEN3 commit ad136e52634d5a393a9dc93383f8ea1e898faf37 upstream. Fix streaming from CSIDn RDI1 and RDI2 to VFEn RDI1 and RDI2. A pattern we have replicated throughout CAMSS where we use the VC number to populate both the VC fields and port fields of the CSID means that in practice only VC = 0 on CSIDn:RDI0 to VFEn:RDI0 works. Fix that for CSID gen3 by separating VC and port. Fix to VC zero as a bugfix we will look to properly populate the VC field with follow on patches later. Fixes: d96fe1808dcc ("media: qcom: camss: Add CSID 780 support") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Reviewed-by: Vladimir Zapolskiy Reviewed-by: Loic Poulain Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit c39a1d9fde82b9ec858e5e4cc2746200651bae00 Author: Bryan O'Donoghue Date: Tue Apr 7 11:34:53 2026 +0100 media: qcom: camss: Fix RDI streaming for CSID GEN2 commit 618765634cefbdddafa84f07f82e9dd05b86cb9c upstream. Fix streaming from CSIDn RDI1 and RDI2 to VFEn RDI1 and RDI2. A pattern we have replicated throughout CAMSS where we use the VC number to populate both the VC fields and port fields of the CSID means that in practice only VC = 0 on CSIDn:RDI0 to VFEn:RDI0 works. Fix that for CSID gen2 by separating VC and port. Fix to VC zero as a bugfix we will look to properly populate the VC field with follow on patches later. Fixes: 729fc005c8e2 ("media: qcom: camss: Split testgen, RDI and RX for CSID 170") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Reviewed-by: Vladimir Zapolskiy Reviewed-by: Loic Poulain Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit 4e451100b35eed78fbf4349e339bdf2c947edbeb Author: Bryan O'Donoghue Date: Tue Apr 7 11:34:51 2026 +0100 media: qcom: camss: Fix RDI streaming for CSID 680 commit 93ea81d16570442dbca04d2e2563ae8c3e65fa1b upstream. Fix streaming to RDI1 and RDI2. csid->phy.en_vc contains a bitmask of enabled CSID ports not virtual channels. We cycle through the number of available CSID ports and test this value against the vc_en bitmask. We then use the passed value both as an index to the port configuration macros and as a virtual channel index. This is a very broken pattern. Reviewing the initial introduction of VC support it states that you can only map one CSID to one VFE. This is true however each CSID has multiple sources which can sink inside of the VFE - for example there is a "pixel" path for bayer stats which sources @ CSID(x):3 and sinks on VFE(x):pix. That is CSID port # 3 should drive VFE port #3. With our current setup only a sensor which drives virtual channel number #3 could possibly enable that setup. This is deeply wrong the virtual channel has no relevance to hooking CSID to VFE, a fact that is proven after this patch is applied allowing RDI0,RDI1 and RDI2 to function with VC0 whereas before only RDI1 worked. Another way the current model breaks is the DT field. A sensor driving different data-types on the same VC would not be able to separate the VC:DT pair to separate RDI outputs, thus breaking another feature of VCs in the MIPI data-stream. Default the VC back to zero. A follow on series will implement subdev streams to actually enable VCs without breaking CSID source to VFE sink. Fixes: 253314b20408 ("media: qcom: camss: Add CSID 680 support") Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Reviewed-by: Vladimir Zapolskiy Reviewed-by: Loic Poulain Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit cb16b79a2be2cec9c3ebe4147490817c4d8b1de3 Author: Valery Borovsky Date: Mon May 11 20:12:08 2026 +0300 media: pwc: Return queued buffers on start_streaming() failure commit 975b2ee20e569d47821e4f6c9761b4664d48a6a4 upstream. The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure"). Fixes: ceede9fa8939 ("[media] pwc: Fix locking") Cc: stable@vger.kernel.org Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9afd605dcd96c7a45f338eded1de16679b30e1df Author: Valery Borovsky Date: Wed May 13 08:42:44 2026 +0300 media: pwc: Drain fill_buf on start_streaming() failure commit 906e410dcffbbd99fb4081abab817a830033aa28 upstream. pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 ("[media] pwc: fix WARN_ON"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/ Fixes: 885fe18f5542 ("[media] pwc: Replace private buffer management code with videobuf2") Cc: stable@vger.kernel.org Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 08ddfd628a2dbd9d385da677afccd893d0ab37e1 Author: Krzysztof Kozlowski Date: Tue Apr 28 16:50:08 2026 +0200 media: pci: dm1105: Free allocated workqueue commit 1a65db225b25bb8c8febf16974c060e0cc242eb9 upstream. Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak. Fixes: 519a4bdcf822 ("V4L/DVB (11984): Add support for yet another SDMC DM1105 based DVB-S card.") Cc: Signed-off-by: Krzysztof Kozlowski Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4e077bcb5e1f634b28365efc197f4cf71e7911d1 Author: Guoniu Zhou Date: Mon Mar 23 16:33:31 2026 +0800 media: nxp: imx8-isi: Fix scale factor calculation for hardware rounding commit 5eb54da3f874b44149556542d949909898865e29 upstream. The ISI hardware rounds the actual output size up to an integer, as described in i.MX93 Reference Manual section 57.7.8 (Channel 0 Scale Factor). The scale factor must be calculated to ensure the theoretical output value rounds up to exactly the desired size. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260323-isi-v3-2-8df53b24e622@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 28ae75dba701d7aa69a36802c398582933d3e0e6 Author: Guoniu Zhou Date: Mon Mar 23 16:33:30 2026 +0800 media: nxp: imx8-isi: Fix potential out-of-bounds issues commit 57a7ec5c9f38ce6c4d6209c4b75c8e57e1fea6cf upstream. The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Guoniu Zhou Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260323-isi-v3-1-8df53b24e622@oss.nxp.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 659a7cea0be8029df342b0b8965638bbbb7f3d76 Author: Xiaolei Wang Date: Thu May 7 12:13:17 2026 +0800 media: nxp: imx8-isi: Fix missing v4l2_subdev_cleanup() in pipe init error path commit 8262de0663318124824aaafd97ddb5d7bb53bd77 upstream. After v4l2_subdev_init_finalize() succeeds in mxc_isi_pipe_init(), if platform_get_irq() or devm_request_irq() fails, the error path jumps to a label that only calls media_entity_cleanup() and mutex_destroy(), missing the v4l2_subdev_cleanup() call needed to free the subdev active state allocated by v4l2_subdev_init_finalize(). Add an error_subdev label that calls v4l2_subdev_cleanup() before falling through to the existing error cleanup. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Xiaolei Wang Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260507041318.491594-4-xiaolei.wang@windriver.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 4702afbd56f1d3a26eabae99627673382433f1dc Author: Xiaolei Wang Date: Thu May 7 12:13:18 2026 +0800 media: nxp: imx8-isi: Clean up already-initialized pipes on probe failure commit d970b27cc48ec42f8a72bc3a4a4ad2e5c7a36395 upstream. When mxc_isi_pipe_init() fails partway through the channel loop or when mxc_isi_v4l2_init() fails, the already initialized pipes are not cleaned up. Fix this by calling mxc_isi_pipe_cleanup() for each already-initialized pipe in the err_xbar error path. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Xiaolei Wang Reviewed-by: Laurent Pinchart Reviewed-by: Frank Li Link: https://patch.msgid.link/20260507041318.491594-5-xiaolei.wang@windriver.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9e61258fbc3cfc053e4c2ed72254c2de76772354 Author: Xiaolei Wang Date: Thu May 7 12:13:16 2026 +0800 media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe commit 567418eedd25b3d86d489807682030b4b98b73d9 upstream. Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm "(udev-worker)", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Xiaolei Wang Reviewed-by: Frank Li Reviewed-by: Laurent Pinchart Link: https://patch.msgid.link/20260507041318.491594-3-xiaolei.wang@windriver.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 181a0aeefd56f9285325b84789aa348aba0508bf Author: David Carlier Date: Sat Mar 28 18:18:09 2026 +0000 media: nuvoton: npcm-video: fix memory leaks in probe and remove commit 50cc0e547da50b887e63dfa1ad203cd5b735d01e upstream. npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails. Fixes: 46c15a4ff1f4 ("media: nuvoton: Add driver for NPCM video capture and encoding engine") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2147acb948a945901d58f5c0e61eb60f19a4d49e Author: David Carlier Date: Sat Mar 28 18:17:49 2026 +0000 media: nuvoton: npcm-video: fix error handling in npcm_video_init() commit 60ca00792bce46ec170c7ed101f376186d4cf8a9 upstream. npcm_video_init() has two error handling issues after of_reserved_mem_device_init() is called: When dma_set_mask_and_coherent() fails, the function releases the reserved memory but does not return, allowing execution to fall through into npcm_video_ece_init() with a failed DMA configuration. When npcm_video_ece_init() fails, the function returns an error without calling of_reserved_mem_device_release(), leaking the reserved memory association. Fix both by adding the missing return after the DMA mask failure and adding the missing of_reserved_mem_device_release() call on the ECE init error path. Fixes: 46c15a4ff1f4 ("media: nuvoton: Add driver for NPCM video capture and encoding engine") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 264b5380c4f8aa92dbc2983ecd2b627f1d5e0061 Author: Valery Borovsky Date: Mon May 11 20:12:07 2026 +0300 media: msi2500: Return queued buffers on start_streaming() failure commit 7201c17786a498497bca57752883b90914d405ac upstream. The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure"). Fixes: 977e444f59ad ("[media] Mirics MSi3101 SDR Dongle driver") Cc: stable@vger.kernel.org Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 1391b75bf0119b5d37f1c1c3078d452a01967f9b Author: Anand Moon Date: Wed May 20 10:10:41 2026 +0530 media: meson: vdec: Fix memory leak in error path of vdec_open commit 940f161f734b25f175a95d2684c2021f6323693a upstream. The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm "v4l_id", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70 Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver") Cc: stable@vger.kernel.org Signed-off-by: Anand Moon Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 18e3b838e09d7b7b052febad6987cb72fbd09621 Author: Guangshuo Li Date: Fri Apr 17 14:53:30 2026 +0800 media: marvell-cam: fix missing pci_disable_device() on remove commit 033ff0420e4c9c240ae5523fff39770298efa964 upstream. During manual code audit, we found that cafe_pci_probe() enables the PCI device with pci_enable_device(), and its probe error path properly calls pci_disable_device() on failure. However, cafe_pci_remove() tears down the controller and frees the driver data without disabling the PCI device, leaving the remove path inconsistent with probe cleanup. Add the missing pci_disable_device() call to cafe_pci_remove(). Fixes: abfa3df36c01 ("[media] marvell-cam: Separate out the Marvell camera core") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit cf48e9db856529d5d57a0f1806ac0cca81ce0ad5 Author: Dmitry Baryshkov Date: Fri May 29 14:27:10 2026 +0300 media: iris: Fix use IRQF_NO_AUTOEN when requesting the IRQ commit 45ac2230f929b9f0fae899c4a5c6bf763250fc13 upstream. Requesting the IRQ and then immediately disabling it is fragile as it leaves a window when the IRQ is still enabled although the underlying device might be not completely setup for IRQ handling. Pass IRQF_NO_AUTOEN instead of calling disable_irq_nosync(). Fixes: fb583a214337 ("media: iris: introduce host firmware interface with necessary hooks") Reviewed-by: Konrad Dybcio Reviewed-by: Dikshita Agarwal Signed-off-by: Dmitry Baryshkov [bod: Appended Fix to patch title for -stable clarity] [bod: Added cc stable for backporting] Cc: stable@vger.kernel.org Signed-off-by: Bryan O'Donoghue Signed-off-by: Greg Kroah-Hartman commit d56044558a7571b03a115cdc21a98f59dd5d80e9 Author: Marco Nenciarini Date: Wed Apr 1 18:25:47 2026 +0200 media: intel/ipu6: Improve DWC PHY HSFREQRANGE band selection for overlapping ranges commit 477620dccf3e9481ed6ae67cb5c747f25751c531 upstream. The get_hsfreq_by_mbps() function searches the freqranges[] table backward (from highest to lowest index). Because adjacent frequency bands overlap, a data rate that falls in the overlap region always lands on the higher-indexed band. For data rates up to 1500 Mbps (index 42) every band uses osc_freq_target 335. Starting at index 43 (1461-1640 Mbps) the osc_freq_target drops to 208. A sensor running at 1498 Mbps sits in the overlap between index 42 (1414-1588, osc 335) and index 43 (1461-1640, osc 208). The backward search picks index 43, programming the lower osc_freq_target of 208 instead of the optimal 335. This causes DDL lock instability and CSI-2 CRC errors on affected configurations, such as the OmniVision OV08X40 sensor on Intel Arrow Lake platforms (Dell Pro Max 16). Rewrite get_hsfreq_by_mbps() to select the optimal band: 1. Among bands whose min/max range covers the data rate, prefer the one with the higher osc_freq_target. 2. If osc_freq_target is equal, prefer the band whose default_mbps is closest to the requested rate. Since the frequency ranges are monotonically increasing, the loop exits early once min exceeds the requested rate. For 1498 Mbps this now correctly selects index 42 (osc_freq_target 335, range 1414-1588) instead of index 43 (osc_freq_target 208, range 1461-1640). Fixes: 1e7eeb301696 ("media: intel/ipu6: add the CSI2 DPHY implementation") Cc: stable@vger.kernel.org Signed-off-by: Marco Nenciarini Signed-off-by: Sakari Ailus Signed-off-by: Greg Kroah-Hartman commit 00a98fb2a6fb2e3d646f15da6de2de75cbeb17e4 Author: Sakari Ailus Date: Sat Feb 21 01:38:15 2026 +0200 media: imx219: Fix maximum frame length in lines commit 2c4f1ba7354312ad2d6e34e70a518a51a9344715 upstream. The driver used the maximum frame length in lines value of 0xffff, but the maximum appears to be 0xfffe instead. Fix it. Fixes: 1283b3b8f82b ("media: i2c: Add driver for Sony IMX219 sensor") Cc: stable@vger.kernel.org Signed-off-by: Sakari Ailus Reviewed-by: Dave Stevenson Reviewed-by: Laurent Pinchart Signed-off-by: Greg Kroah-Hartman commit 7337c88205ed0ffc654f40266be0d3c3eb15fb29 Author: Martin Hecht Date: Fri May 8 11:59:03 2026 +0200 media: i2c: alvium: fix critical pointer access in alvium_ctrl_init commit 4f6f28ff24709710c08557c127b3e4c3fb1b4159 upstream. The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags. 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 c68c4ce72feb6fcccc843eb3baa7af60189ed567 Author: Wang Jun <1742789905@qq.com> Date: Fri Mar 20 15:04:53 2026 +0800 media: cx23885: add ioremap return check and cleanup commit a0701e387b46e2481c05b47f1235b954bfc2af3e upstream. Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure. Fixes: d19770e5178a ("V4L/DVB (6150): Add CX23885/CX23887 PCIe bridge driver") Cc: stable@vger.kernel.org Signed-off-by: Wang Jun <1742789905@qq.com> Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f468b7ee5d6332b01e6c538179a4c720e6dae93b Author: Johan Hovold Date: Mon Mar 30 11:37:27 2026 +0200 media: cx231xx: fix devres lifetime commit 7d6358ab02866e5b7ed8d3a00805297617bbb0ec upstream. USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind. Fixes: 184a82784d50 ("[media] cx231xx: use devm_ functions to allocate memory") Cc: stable@vger.kernel.org # 3.17 Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f24ca8b53fe15db40957bdaa40c9aa68e1557bbe Author: Brandon Brnich Date: Fri Mar 20 13:05:26 2026 -0500 media: chips-media: wave5: Move src_buf Removal to finish_encode commit b20157147089a9c16a38c7810e2fe6f2df8e3277 upstream. During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode. Fixes: 9707a6254a8a6 ("media: chips-media: wave5: Add the v4l2 layer") Cc: stable@vger.kernel.org Signed-off-by: Brandon Brnich Tested-by: Jackson Lee Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9924cb548ee7753a6473997949c3ec48092de0b0 Author: Pengpeng Hou Date: Tue Mar 24 16:08:56 2026 +0800 media: cedrus: skip invalid H.264 reference list entries commit 10358ea986c3c85516d1c8206486464f79d36e76 upstream. Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries. Fixes: e000e1fa4bdbd ("media: uapi: h264: Update reference lists") Cc: stable@vger.kernel.org Signed-off-by: Pengpeng Hou Reviewed-by: Nicolas Dufresne Acked-by: Jernej Skrabec Tested-by: Chen-Yu Tsai Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 000e51afb6068bcaf3e51959f030c8002d8110a7 Author: Samuel Holland Date: Tue Apr 7 01:14:02 2026 +0300 media: cedrus: Fix missing cleanup in error path commit d99732334aaf33b9f93926b70b6a11c2cef3de39 upstream. According to the documentation struct v4l2_fh has to be cleaned up with v4l2_fh_exit() before being freed. [1] Currently there is no actual bug here, when v4l2_fh_exit() isn't called. v4l2_fh_exit() in this case only destroys internal mutex. But it may change in the future, when v4l2_fh_init/v4l2_fh_exit will be enhanced. 1. https://docs.kernel.org/driver-api/media/v4l2-fh.html Signed-off-by: Samuel Holland Signed-off-by: Andrey Skvortsov Fixes: 50e761516f2b ("media: platform: Add Cedrus VPU decoder driver") Cc: stable@vger.kernel.org Acked-by: Paul Kocialkowski Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 73504935e4365d931a367f23f9b7c29c2722e750 Author: Myeonghun Pak Date: Wed May 6 21:41:16 2026 +0900 media: cedrus: clean up media device on probe failure commit 2c869b6969f3061cbbdab587f4c0a88bd7fc3cc9 upstream. cedrus_probe() initializes the media device before registering the video device, the media controller, and the media device. If any of those later steps fails, probe returns without calling media_device_cleanup(), so the media device internals initialized by media_device_init() are left behind. Add a media-device cleanup label to the probe unwind path and route video registration failures through it as well. Fixes: 50e761516f2b8c ("media: platform: Add Cedrus VPU decoder driver") Cc: stable@vger.kernel.org Reviewed-by: Paul Kocialkowski Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6efe665356ec81221928cbcca6e89e66f48bc7db Author: Myeonghun Pak Date: Fri Apr 24 23:36:01 2026 +0900 media: cec: seco: unregister adapter on IR probe failure commit c3a78691be8245e52ced489f268e413f18061ac2 upstream. If secocec_ir_probe() fails after cec_register_adapter() succeeds, probe returns an error and the driver remove callback is not called. The current unwind path unregisters the notifier and then falls through to cec_delete_adapter(), which violates the CEC adapter lifetime rules after a successful registration. Add a registered-adapter unwind path that unregisters the notifier and the adapter instead. Fixes: daef95769b3a ("media: seco-cec: add Consumer-IR support") Cc: stable@vger.kernel.org Signed-off-by: Myeonghun Pak Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0459a4304cff8e702a5a2bf6060a9e23061796aa Author: David Carlier Date: Sat Mar 28 11:23:30 2026 +0000 media: aspeed: fix missing of_reserved_mem_device_release() on probe failure commit 253c8ef7d57da0c74db251f385324faaa5ae2257 upstream. aspeed_video_init() calls of_reserved_mem_device_init() to associate reserved memory regions with the device. When aspeed_video_setup_video() subsequently fails in aspeed_video_probe(), the error path frees the JPEG buffer and unprepares the clocks but does not release the reserved memory association, leaking the rmem_assigned_device entry on the global list. The normal remove path already calls of_reserved_mem_device_release() correctly; only the probe error path was missing it. Add the missing of_reserved_mem_device_release() call to the aspeed_video_setup_video() failure cleanup. Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver") Cc: stable@vger.kernel.org Signed-off-by: David Carlier Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 391fe3e36e59f3c6e3d46edfb3a5de51e00cd216 Author: Ricardo Ribalda Date: Thu May 7 20:58:11 2026 +0000 media: amlogic-c3: Add validations for ae and awb config commit 9724164f71974a2a44a5e026614fbcc05bab6d91 upstream. Avoid invalid memory access if the zones_num is bigger than zone_weight. This patch fixes the following smatch errors: drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max Cc: stable@vger.kernel.org Fixes: fb2e135208f3 ("media: platform: Add C3 ISP driver") Reviewed-by: Jacopo Mondi Reviewed-by: Laurent Pinchart Signed-off-by: Ricardo Ribalda Reviewed-by: Keke Li Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 73bd2779865372b1017d4f555b45270aa2d0d710 Author: Valery Borovsky Date: Mon May 11 20:12:06 2026 +0300 media: airspy: Return queued buffers on start_streaming() failure commit 04344d0b4929caa94c0df72f767752aa0935ef5d upstream. The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on start_streaming() failure"). Fixes: 634fe5033951 ("[media] airspy: AirSpy SDR driver") Cc: stable@vger.kernel.org Signed-off-by: Valery Borovsky Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit a096a6aba601152a45d4e272207bd37e03ca3f92 Author: Maíra Canal Date: Sat Jul 18 10:44:36 2026 -0300 drm/v3d: Reach the GMP through the hub registers on V3D 7.x commit f7df2da0d1c375c1c4c70e1e0b569592de0d6b73 upstream. v3d_idle_axi() drains the GPU's memory interface for a safe powerdown by using the V3D_GMP_CFG register. It reached both registers with the macros V3D_CORE_READ and V3D_CORE_WRITE. On V3D 7.x the GMP is no longer a per-core block; it lives in the hub register region. Reaching it through the per-core register block addresses the wrong region. Select the hub accessors (V3D_{READ,WRITE}) for the GMP on V3D 7.x and keep the per-core path for earlier generations. Cc: stable@vger.kernel.org Fixes: 0ad5bc1ce463 ("drm/v3d: fix up register addresses for V3D 7.x") Link: https://patch.msgid.link/20260718-v3d-pm-axi-transactions-v1-1-4ecd7729ed70@igalia.com Reviewed-by: Iago Toral Quiroga Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit a2212fef8e18724e06432fce01fa257296d9f053 Author: Matthew Brost Date: Tue Jul 14 10:00:25 2026 -0700 drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict commit 847b371debf3c8c72384ab7b9a0c4123a74cc925 upstream. If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path. Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost Reviewed-by: Himal Prasad Ghimiray Link: https://patch.msgid.link/20260714170025.3487974-1-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman commit 6deaa317201851c644c431b57682e54d06b35838 Author: Linmao Li Date: Tue Jul 21 09:15:58 2026 +0800 drm/vc4: Prevent shader BO mappings from becoming writable commit 0c9e6367639548307d3f578f6943ce72c9d39087 upstream. vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects. Fixes: 463873d57014 ("drm/vc4: Add an API for creating GPU shaders in GEM BOs.") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://lore.kernel.org/dri-devel/20260720085554.B0AF01F000E9@smtp.kernel.org/ Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260721011558.1672477-1-lilinmao@kylinos.cn Reviewed-by: Maíra Canal Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit b1379f0c42b88cb60b9f3757eb5d1e73ad460ed8 Author: Ian Forbes Date: Tue Jun 23 14:33:14 2026 -0500 drm/vmwgfx: Validate vmw_surface_metadata::array_size commit a4f55260f7f7d4dc4d0ee55063dfb0c457b77991 upstream. This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available. Fixes: 504901dbb0b5 ("drm/vmwgfx: Refactor surface_define to use vmw_surface_metadata") Reported-by: Zero Day Initiative Cc: stable@vger.kernel.org Signed-off-by: Ian Forbes Reviewed-by: Maaz Mombasawala Signed-off-by: Zack Rusin Link: https://patch.msgid.link/20260623193314.506257-1-ian.forbes@broadcom.com Signed-off-by: Greg Kroah-Hartman commit 2b85e19792be4fda511f23b6b7a69b4fba23bca1 Author: Leo Li Date: Thu Jul 23 09:44:50 2026 -0400 drm/amd/display: Fix missing DCE check in dm_gpureset_toggle_interrupts() commit fbbaca9e208733652828ea98d00f09f260a7770e upstream. This line was lost when cping from amd-staging-drm-next to drm-fixes. So add it back. Cc: stable@vger.kernel.org Fixes: 8382cd234981 ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock") Reported-by: Lu Yao Signed-off-by: Leo Li Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260723134450.13838-1-sunpeng.li@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman commit a38f2724eb93a78ba250b01e0caf3468df4d3956 Author: Linmao Li Date: Mon Jul 20 16:44:26 2026 +0800 drm/vc4: Shut down BO cache timer before teardown commit 6273dd3ffb54ec581855b82ae77331b66028249c upstream. The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync(). Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.") Cc: stable@vger.kernel.org Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260720084426.1632508-1-lilinmao@kylinos.cn Reviewed-by: Maíra Canal Signed-off-by: Maíra Canal Signed-off-by: Greg Kroah-Hartman commit ee44ea4f7e309191790875f8bb88e61d91eae370 Author: Leo Li Date: Thu Jul 23 14:01:59 2026 -0400 drm/amd/display: Fix flip-done timeouts on mode1 reset commit 82730dba0cf9d9524af0ceeb7eb6b5c3ab1bdb87 upstream. The vblank on/off callbacks mixed use of amdgpu_irq_get/put() and amdgpu_dm_crtc_set_vupdate_irq() to enable and disable IRQs. With get/put, base driver will callback into DC to disable IRQs when refcount == 0. With set_vupdate_irq(), DC is called directly to disable IRQs, bypassing base driver's refcount tracking. During gpu reset, base driver can restore IRQs via amdgpu_irq_gpu_reset_resume_helper() > amdgpu_irq_update(). So if get/put() is not used (i.e. refcount == 0), then vupdate_irq will be disabled. This is problematic if DRM requests vblank on before amdgpu_irq_update() is called: drm_vblank_on() > set_vupdate_irq() enables vupdate_irq, but the refcount is still 0. gpu_reset_resume_helper() > irq_update() then immediately disables it, thus leading to flip done timeouts. This is made worse on DCN since VUPDATE_NO_LOCK is the only IRQ enabled. Prior to 8382cd234981, a combination of GRPH_FLIP and VSTARTUP IRQs were used, and they used get/put(). This explains why 8382cd234981 exposed this issue. Fix by using get/put() instead of set_vupdate_irq(). DCE is unchanged, since it relies on unbalanced enable/disable calls based on VRR status, and hence requires direct set_vupdate_irq(). Plus, it also uses GRPH_FLIP and VLINE IRQs, which are properly tracked by get/put(). Cc: stable@vger.kernel.org Fixes: 8382cd234981 ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock") Signed-off-by: Leo Li Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260723180159.52121-1-sunpeng.li@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman commit ba7b6444097a73ccd3d3ac9e2be4ebb73d226460 Author: Zhu Lingshan Date: Wed Jul 1 18:53:21 2026 +0800 drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved commit a2f895f3c852063258d62e9f74b081de07ca95df upstream. amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. Signed-off-by: Zhu Lingshan Reviewed-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fd2de80f28a0796254f45a437f26a87d59db8d14 Author: Mario Limonciello Date: Wed Jul 8 22:15:20 2026 -0500 drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge commit 0148ac33547b9af1c5a7f3bb6e5baffcb6e9fac2 upstream. AMD Ryzen Pinnacle Ridge (Zen+, family 0x17 model 0x08) CPUs have PCI controllers that don't support PCIe dynamic speed switching, causing system freezes during GPU initialization when enabled. Disable dynamic speed switching when this CPU is detected. Assisted-by: Claude:sonnet Fixes: 466a7d115326 ("drm/amd: Use the first non-dGPU PCI device for BW limits") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5436 Reviewed-by: Lijo Lazar Link: https://patch.msgid.link/20260709031520.841611-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 9ceb4e034a327a04155f32f1cd1a5031dfa5fe02) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 490ceacd2162de919a142bcb4eff363bb493b1de Author: Mario Limonciello Date: Mon Jun 29 15:27:00 2026 -0500 drm/amd/display: Fix backlight max_brightness to match exported range commit f1b5d8f9cc54ae8a2567ac126867ae488e1bf625 upstream. [Why] FWTS autobrightness fails on eDP panels because actual_brightness can read higher than the advertised max_brightness (e.g. 63576 vs 62451). The conversion helpers expose the firmware PWM range to userspace as [0..max]. But max_brightness is advertised as (max - min), which is smaller. So reading the level can return a value above max_brightness. This regressed in commit 4b61b8a39051 ("drm/amd/display: Add debugging message for brightness caps"), which changed max_brightness to (max - min) and undid commit 8dbd72cb7900 ("drm/amd/display: Export full brightness range to userspace"). [How] Advertise max_brightness as max, and scale the initial AC/DC brightness against max too. Update the KUnit expectations to match. Fixes: 4b61b8a39051 ("drm/amd/display: Add debugging message for brightness caps") Reviewed-by: Alex Hung Signed-off-by: Mario Limonciello Signed-off-by: George Zhang Signed-off-by: Alex Deucher (cherry picked from commit bd9e2b5b0473c75abc0f4134dfe79ecbfb16610d) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9c0432044d34bf629f3c0dec3251128e7c8451fe Author: Alessandro Rinaldi Date: Fri Jun 26 16:36:00 2026 +0200 drm/amd/display: Force PWM backlight on Lenovo Legion 5 15ARH05 commit bad177fa75e607e396cd57daaaed881450d7a471 upstream. The Lenovo Legion 5 15ARH05 (Renoir) ships a BOE 0x08DF eDP panel that advertises AUX/DPCD backlight control, so amdgpu's automatic detection (amdgpu_backlight == -1) selects AUX. On this panel the AUX backlight path has no effect: brightness writes are accepted but the panel level never changes, the display is stuck at a fixed brightness and max_brightness is reported as a bogus 511000. As a result neither the desktop brightness slider nor the brightness hotkeys do anything. Forcing PWM backlight (amdgpu.backlight=0) restores working control: max_brightness becomes 65535 and the level tracks writes. This has long been applied by users as a manual kernel-parameter workaround. Extend the generic panel backlight quirk with a force_pwm flag, add an entry for the Legion 5 15ARH05 / BOE 0x08DF panel, and have amdgpu disable AUX backlight (use PWM) when the quirk matches and the user lets the driver auto-select the backlight type. Signed-off-by: Alessandro Rinaldi Tested-by: Alessandro Rinaldi Reviewed-by: George Zhang Signed-off-by: Alex Deucher (cherry picked from commit 81b39f43e7e53589491e2eef6bad5389626b4b9c) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 51ea665c30c424c98959101f3bf6f48ab42949c8 Author: Andriy Korud Date: Fri Jul 10 12:52:26 2026 +0200 drm/amd/display: dce100: skip non-DP stream encoders for DP MST commit d340cba0df4cf327c7e89c7c1a4e79d4771d7dd5 upstream. On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch Signed-off-by: Andriy Korud Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5162 Signed-off-by: Alex Deucher (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0b9fa4272e24bfc28fe075118f246cb09b9770ed Author: Leo Li Date: Fri Jun 12 13:29:31 2026 -0400 drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock commit 8382cd234981ae36299bb66a10bac2cd8ff1b99d upstream. [Why] On DCN, vblank events were delivered from VSTARTUP/VUPDATE (dm_crtc_high_irq/dm_vupdate_high_irq) and pageflip completion from GRPH_PFLIP (dm_pflip_high_irq). These signals can be masked by hardware by a few things: * DPG - DCN can Dynamically Power Gate parts of the display pipe when a self-refresh capable eDP is connected. DPG is engaged when there's enough static frames (detected through drm_vblank_off). Once gated, even though the OTG (output timing generator) is still enabled, VSTARTUP and GRPH_FLIP are masked. * GSL - Driver can use the Global Sync Lock to block HW from latching onto double-buffered registers during programming, to prevent HW from latching onto a partially programmed state. This will mask VSTARTUP, GRPH_FLIP, and VUPDATE. See dcn20_pipe_control_lock(). * MALL - A DCN accessible cache introduced in DCN32+ DGPUs that can store fb data to allow for longer DRAM sleep. When scanning out from MALL, VSTARTUP is masked. When masked, events are never delivered, which can show up as flip_done timeouts in the wild. However, there is an interrupt source on DCN that is never masked: VUPDATE_NO_LOCK. It's simply an unmasked variant of VUPDATE, which fires while the OTG is active, at the exact point hardware latches double-buffered registers. It is therefore the natural single signal for delivering both vblank and flip-completion events on DCN, and the correct point to timestamp both VRR and non-VRR vblanks. DCE's interrupt sources are different, it does not have an unmaskable VUPDATE_NO_LOCK. The only unmaskable DCE interrupt is VLINE0, but it can only be programmed as a vline offset from vsync_start, making it unsuitable for VRR. Thus, we keep DCE untouched and use the existing mix of interrupt sources. [How] For DCN1 and newer only: * Factor the body of dm_crtc_high_irq() into dm_crtc_high_irq_handler() and drive it from dm_vupdate_high_irq() (VUPDATE_NO_LOCK). DCE keeps using dm_crtc_high_irq() (VSTARTUP) and dm_pflip_high_irq() (GRPH_PFLIP) unchanged. * Stop registering VSTARTUP (crtc_irq) and GRPH_PFLIP (pageflip_irq) on DCN, and stop enabling them in amdgpu_dm_crtc_set_vblank() / manage_dm_interrupts(). Enable VUPDATE whenever vblank is enabled on DCN (previously only in VRR mode). The secure-display vline0 interrupt is left untouched. * VUPDATE_NO_LOCK does not early-fire on an immediate (tearing / async) flip, since HW latches the new address right away. Deliver the flip completion event immediately after programming such flips in amdgpu_dm_commit_planes(), and clear pflip_status so the next vupdate handler does not double-send. v2: Do not gate VUPDATE_NO_LOCK on DCN in dm_handle_vrr_transition() Also toggle VUPDATE_NO_LOCK on DCN in dm_gpureset_toggle_interrupts() Re-cook vblank event count and timestamp for immediate flips Fixes: 9b47278cec98 ("drm/amd/display: temp w/a for dGPU to enter idle optimizations") Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/3787 Link: https://gitlab.freedesktop.org/drm/amd/-/work_items/4141 Assisted-by: Copilot:claude-opus-4.8 Co-developed-by: Matthew Schwartz Signed-off-by: Matthew Schwartz Tested-by: Mario Limonciello (AMD) Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Leo Li Signed-off-by: Alex Deucher (cherry picked from commit c87e6635d2db02c88ae8d09529362da672d34770) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 679f23f0a3606afcef1ffabd72222f00a54ad9e3 Author: WenTao Liang Date: Sun Jun 28 15:27:40 2026 +0800 drm/amd/display: set new_stream to NULL after release commit 9fa26b9eed6195bf840f39ac183b9a6237548755 upstream. In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. Fixes: 9b690ef3c704 ("drm/amd/display: Avoid full modeset when not required") Signed-off-by: WenTao Liang Reviewed-by: George Zhang Signed-off-by: Alex Deucher (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 123692ebc1ea731c82790f438654427b6e137300 Author: Timur Kristóf Date: Mon Jul 13 08:14:43 2026 +0200 drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X) commit 85371c5ef502d10add72eab38711e191dccea981 upstream. The old radeon driver has a documented workaround in ci_dpm.c which claims that Bonaire 0x6658 with old memory controller firmware is unstable with MCLK DPM, so as a precaution I disabled MCLK DPM on this ASIC in amdgpu. Note that the old MC firmware is not actually used with amdgpu, but in theory it's possible that the VBIOS sets up the ASIC with an old MC firmware that is already running when amdgpu initializes (in which case amdgpu doesn't load its own firmware). What I expected to happen is that the GPU would simply use its maximum memory clock, and indeed this is what seemed to happen according to amdgpu_pm_info which reads the current MCLK value from the SMU. However, some users reported a huge perf regression and upon a closer look it seems that the GPU seems to not actually use the highest MCLK value, despite the SMU reporting that it does. Let's not disable MCLK DPM on Bonaire 0x6658 (R7 260X). Keep MCLK DPM disabled on R9 M380 in the 2015 iMac because that still hangs if we enable it. Fixes: 9851f29cb06c ("drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs") Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit d34acad064ee7d82bd18f5d87592c422d4d323ac) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d8dc3a9e815d6b225616dce4f1eac7261a8ead0f Author: Mario Limonciello Date: Wed Jul 8 14:35:14 2026 -0500 drm/amdgpu: Fix VFCT bus number matching with soft filter commit db7e8108809a2245f0a17ba323f027cac0941ffb upstream. On systems where PCI bus renumbering occurs (e.g. pci=realloc, resource conflicts), the runtime bus number may differ from the BIOS POST bus number recorded in the VFCT table. This causes amdgpu_acpi_vfct_bios() to fail finding the VBIOS even though the correct device entry exists. Introduce amdgpu_acpi_vfct_match() which treats the bus number as a soft filter: vendor/device/function identity is the hard requirement, while exact bus match is the preferred path. When bus numbers disagree but device identity matches, accept the VFCT entry and log a dev_notice for diagnostics. Reported-by: Oz Tiram Closes: https://lore.kernel.org/amd-gfx/20260621173211.28443-1-oz@shift-computing.de/ Reviewed-by: Alex Deucher Link: https://patch.msgid.link/20260708193518.702584-2-mario.limonciello@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 11c141672045ffc0187aa604f2c0f597bc334fb2) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 312278b3091912fa56a6a587609f17dcb33465c2 Author: Mario Limonciello Date: Wed Jul 8 14:35:15 2026 -0500 drm/amdgpu: Release VFCT ACPI table reference commit 65bff26617607c1331283232016c0e89088c5b78 upstream. amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. Reviewed-by: Alex Deucher Link: https://patch.msgid.link/20260708193518.702584-3-mario.limonciello@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e64b2f1e826af697f2b786dc30d166135bec5609 Author: Osama Abdelkader Date: Tue Jul 14 18:30:55 2026 +0200 drm/panthor: return error on truncated firmware commit 4a2c8cbe9bcba170706fdf08b1c84b6cbcf5b044 upstream. panthor_fw_load() detects truncated firmware images, but jumps to the common cleanup path without setting ret. If no previous error was recorded, the function can return 0 and treat the invalid firmware as successfully loaded. Set ret to -EINVAL before leaving the truncated-image path. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader Reviewed-by: Liviu Dudau Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20260714163056.22329-1-osama.abdelkader@gmail.com Signed-off-by: Liviu Dudau Signed-off-by: Greg Kroah-Hartman commit 22aa7fb4e7d0b3ab41d1240ed743167980912970 Author: Matthew Brost Date: Thu Jul 2 14:48:15 2026 -0700 drm/ttm: Account for NULL and handle pages in ttm_pool_backup commit 5b7b3b6595ee77d01c7463757baed114786094dd upstream. Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f930b844000 CR3: 000000000262e003 CR4: 0000000008f70ef0 PKRU: 55555554 Call Trace: __change_page_attr_set_clr+0x989/0xe90 ? __purge_vmap_area_lazy+0x6c/0x3a0 ? _vm_unmap_aliases+0x250/0x2a0 set_pages_array_wb+0x7f/0x120 ttm_pool_backup+0x4c9/0x5b0 [ttm] ? dma_resv_wait_timeout+0x3b/0xf0 ttm_tt_backup+0x32/0x60 [ttm] ttm_bo_shrink+0x66/0x110 [ttm] xe_bo_shrink_purge+0x12b/0x1b0 [xe] xe_bo_shrink+0xbb/0x270 [xe] __xe_shrinker_walk+0xf7/0x160 [xe] xe_shrinker_walk+0x9d/0xc0 [xe] xe_shrinker_scan+0x11f/0x210 [xe] do_shrink_slab+0x13b/0x270 shrink_slab+0xf1/0x400 shrink_node+0x352/0x8a0 balance_pgdat+0x32c/0x700 kswapd+0x205/0x2f0 ? __pfx_autoremove_wake_function+0x10/0x10 ? __pfx_kswapd+0x10/0x10 kthread+0xd1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x1b1/0x200 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Cc: Christian Koenig Cc: Huang Rui Cc: Matthew Auld Cc: Matthew Brost Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Simona Vetter Cc: Thomas Hellström Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Fixes: b63d715b8090 ("drm/ttm/pool, drm/ttm/tt: Provide a helper to shrink pages") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Matthew Brost Reviewed-by: Thomas Hellström Link: https://patch.msgid.link/20260702214815.4009271-1-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman commit b2d8b66c673933ce62bc05a54b047d7354b2e298 Author: Jason Macnak Date: Thu Jun 25 10:08:28 2026 -0700 drm/virtio: Don't detach GEM from a non-created context commit d489a5305b9d5480d6fb97d5636f5f4b1e0b3827 upstream. Applies the same treatment as commit 7cf6dd467e87 ("drm/virtio: Don't attach GEM to a non-created context in gem_object_open()") to virtio_gpu_gem_object_close() to avoid trying to detach a resource that was never attached due to a context never being created when context_init is supported. Fixes: 086b9f27f0ab ("drm/virtio: Don't create a context with default param if context_init is supported") Cc: # v6.14+ Signed-off-by: Jason Macnak Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260625170828.3335431-1-natsu@google.com Signed-off-by: Greg Kroah-Hartman commit a4a1866d50c49d9fabbc7f3a0eaa2e33b9d632bd Author: Alex Deucher Date: Fri Jun 26 16:29:13 2026 -0400 drm/gfx10: Program DB_RING_CONTROL commit f0262c3a3f14d60140f6b826d40d44edf62c36d6 upstream. This is needed to allocate occlusion counters across both gfx pipes. Fixes: b7a1a0ef12b8 ("drm/amd/amdgpu: add pipe1 hardware support") Reviewed-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit 6807352cbabb74b61ba42888769283af72191f66) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e163c5a0946de528d9a83f567153677d31202f12 Author: Yang Wang Date: Mon Jul 6 09:29:24 2026 +0800 drm/amd/pm: fix smu14 power limit range calculation commit e987eabc02646920cd13ab75902693e99735eca0 upstream. SMU14 derives the default PPT limit from SocketPowerLimitAc/Dc, but MsgLimits.Power may expose a different firmware limit for the same PPT0 throttler. Using those values independently as fixed min/max bases can report an incorrect configurable power range. Keep the socket power limit as the default value and as the fallback for current-limit queries. Calculate the reported range from both firmware values instead, using the lower value as the minimum base and the higher value as the maximum base before applying OD percentages. Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher (cherry picked from commit c936b8126b444401318fcbeb1828488cc5312dee) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e3bcd3bf7eeca9570b9fa0b2f8a602c7bcc6b0d0 Author: Jani Nikula Date: Thu Jun 25 17:22:04 2026 +0300 drm/i915/mst: limit DP MST ESI service loop commit 005771c18c5b2c98cb4e7517661aea460990fd3f upstream. The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. Reported-by: Martin Hodo Fixes: 3c0ec2c2d594 ("drm/i915: Flatten intel_dp_check_mst_status() a bit") Cc: stable@vger.kernel.org # v5.8+ Cc: Ville Syrjälä Cc: Imre Deak Reviewed-by: Imre Deak Link: https://patch.msgid.link/20260625142204.1078287-1-jani.nikula@intel.com Signed-off-by: Jani Nikula (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 726f27bca93e6c83b263542669132ee1d0eb693e Author: Joonas Lahtinen Date: Wed Jul 1 10:55:55 2026 +0300 drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU commit 2b56757a9a7456825eb668fde92299e01c5e2721 upstream. Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") Cc: Faith Ekstrand Cc: Simona Vetter Cc: Tvrtko Ursulin Cc: Maarten Lankhorst Cc: # v5.15+ Signed-off-by: Joonas Lahtinen Reviewed-by: Maarten Lankhorst Reviewed-by: Andi Shyti Link: https://patch.msgid.link/20260701075555.52142-1-joonas.lahtinen@linux.intel.com (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 37951ce1567ccf8c86c7a1b8fb7d55a32c821b87 Author: Joonas Lahtinen Date: Wed Jul 1 10:30:30 2026 +0300 drm/i915/gem: Do not leak siblings[] on proto context error commit eed3de2acf6aa5154d49098b026710b646db67ee upstream. After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)") Cc: Faith Ekstrand Cc: Simona Vetter Cc: Tvrtko Ursulin Cc: Maarten Lankhorst Cc: # v5.15+ Signed-off-by: Joonas Lahtinen Reviewed-by: Maarten Lankhorst Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260701073030.44850-1-joonas.lahtinen@linux.intel.com (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 1173190412fb9d12e7efce76734118d9712ff970 Author: Shahyan Soltani Date: Mon Jul 6 08:15:21 2026 -0400 drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() commit 04cc4aa3617b0ed67e859f91f09de5d896a46f3a upstream. The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. Signed-off-by: Shahyan Soltani Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 5df5a59c32b46fe8e7f292df688c2b248aa9f4f2 Author: Kenneth Feng Date: Thu Jun 25 17:48:22 2026 +0800 drm/amd/amdgpu: disable ASPM on VI if pcie dpm is disabled commit 18a7826aea6fd09f2d371c02cec70c7234fc4879 upstream. Disable ASPM on VI if PCIE dpm is disabled. Fixes: bb00bf17328d ("drm/amd/amdgpu: decouple ASPM with pcie dpm") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5370 Signed-off-by: Kenneth Feng Reviewed-by: Yang Wang Signed-off-by: Alex Deucher (cherry picked from commit 873a8d6b3c0a386408c891e4ff1c684fa11783e1) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8b2da44446f9dce2ae50fee78bac2734d4277143 Author: Jani Nikula Date: Fri Jun 26 17:01:55 2026 +0300 drm/i915/bios: range check LFP Data Block panel_type2 commit 2084503f2d087bf956198e7f6eb25b03a7049cb2 upstream. While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) Reported-by: Martin Hodo Fixes: 6434cf630086 ("drm/i915/bios: calculate panel type as per child device index in VBT") Cc: stable@vger.kernel.org # v6.0+ Cc: Animesh Manna Cc: Ville Syrjälä Reviewed-by: Michał Grzelak # v1 Reviewed-by: Ville Syrjälä Link: https://patch.msgid.link/20260626140155.1389655-1-jani.nikula@intel.com Signed-off-by: Jani Nikula (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit cbec6a57959ab503e3ad4ad6edd51efb585dce92 Author: Joonas Lahtinen Date: Wed Jun 24 12:09:40 2026 +0300 drm/i915: Return NULL on error in active_instance commit 1e33f0de5fdcd09e51fdec1e5822448970b6420f upstream. Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo Fixes: bfaae47db3c0 ("drm/i915: make lockdep slightly happier about execbuf.") Cc: Maarten Lankhorst Cc: Thomas Hellström Cc: Simona Vetter Cc: # v5.13+ Signed-off-by: Joonas Lahtinen Reviewed-by: Sebastian Brzezinka Reviewed-by: Maarten Lankhorst Link: https://patch.msgid.link/20260624090940.74840-1-joonas.lahtinen@linux.intel.com (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit d20b5c139b2906bcd8ab4bfe5b8be500318161d1 Author: Alex Deucher Date: Mon Jun 15 18:26:28 2026 -0400 drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() commit 9e98ed3113943257ad6e5c1e6beddbdb482a70ad upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak Signed-off-by: Alex Deucher (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 09da54636bac146c1a3c461c4e7eb08d355bb86e Author: Alex Deucher Date: Mon Jun 15 18:27:15 2026 -0400 drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() commit b9dd618a635d39fbb211454b6e8837b2a7f10fb0 upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak Signed-off-by: Alex Deucher (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 51fd52087165180967cf7d5ee99badee7e172ea0 Author: Alex Deucher Date: Mon Jun 15 18:27:54 2026 -0400 drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() commit ec42c96c322e5cc48099ab5e67b5cbe236cb1949 upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak Signed-off-by: Alex Deucher (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4c09483325360373656214cc7a2fd29dc73037a5 Author: Alex Deucher Date: Mon Jun 15 18:28:29 2026 -0400 drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() commit e80e28f398f5d9f6e361ffb56382d2e74fc87556 upstream. There's no need to crash the kernel for these cases. Reviewed-by: Vitaly Prosyak Signed-off-by: Alex Deucher (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3d2ef8d389495e7889c6062d8bddc46d2a5fbdef Author: Jani Nikula Date: Thu Jun 25 20:03:04 2026 +0300 drm/i915/hdcp: check streams[] bounds before overflow commit bbb15a6b042d02e5508a02b4847e02d2579ee7bc upstream. The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo Fixes: e03187e12cae ("drm/i915/hdcp: MST streams support in hdcp port_data") Cc: stable@vger.kernel.org # v5.12+ Cc: Anshuman Gupta Cc: Suraj Kandpal Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/20260625170304.1104723-1-jani.nikula@intel.com Signed-off-by: Jani Nikula (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 1f876bd8adc791c8a4b26272354f647ff1df6b3d Author: Jani Nikula Date: Thu Jun 25 13:44:07 2026 +0300 drm/i915/hdcp: require monotonically increasing seq_num_v commit db9e64c983dcb07ff256bd455f258c44aa530ff8 upstream. The HDCP 2.2 specification requires the seq_num_v to be monotonically increasing, and repeated seq_num_v needs to be treated as an integrity failure. Make it so. For the first message, seq_num_v must be zero, and is already checked. We can only check for less-than-or-equal for the subsequent messages, where hdcp2_encrypted is true. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo Fixes: d849178e2c9e ("drm/i915: Implement HDCP2.2 repeater authentication") Cc: stable@vger.kernel.org # v5.2+ Cc: Suraj Kandpal Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/20260625104407.1025614-1-jani.nikula@intel.com Signed-off-by: Jani Nikula (cherry picked from commit 58a224375c81179b52558c53d8857b93196d2687) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 35be0e2c6862abcd5e5f5445261f1fd910d4a9b4 Author: Bryam Vargas Date: Sat Jun 20 21:43:34 2026 -0500 drm/virtio: bound EDID block reads to the response buffer commit 4e1a53892ba7f8a3e1da6bfc53c83ae7c812dccd upstream. virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected. Fixes: b4b01b4995fb ("drm/virtio: add edid support") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260620-b4-disp-22bba7bf-v1-1-b95924cee742@proton.me Signed-off-by: Greg Kroah-Hartman commit 4ee77643e6194f2deb62fe62f04396f9825e27d8 Author: WenTao Liang Date: Fri Jun 26 20:45:55 2026 +0800 drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference commit a6e14b976be48eebd8769cb5b883a6af7fc5ade1 upstream. prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. Fixes: 54618888d1ea ("drm/amd/display: break down dc_link.c") Signed-off-by: WenTao Liang Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260626124555.36910-1-vulab@iscas.ac.cn Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8a77ccf9cb9927122d9764b3dffe0565d15bd994 Author: Thomas Zimmermann Date: Wed Jun 10 17:18:17 2026 +0200 drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips commit ac11060c6d4959e2d4ceada037d2e1e1bfcf6645 upstream. The mode-setting pipeline can disabled damage clippings for a commit by setting ignore_damage_clips in struct drm_plane_state. The commit will then do a full display update. Test the flag in DCN code and do a full update in DCN code if it has been set. Commit 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers to ignore damage clips") introduced ignore_damage_clips to selectively ignore damage clipping in certain framebuffer changes. This driver does not do that, but DRM's damage iterator will soon rely on the flag. Therefore supporting it here as well make sense for consistency. Signed-off-by: Thomas Zimmermann Fixes: 35ed38d58257 ("drm: Allow drivers to indicate the damage helpers to ignore damage clips") Cc: Javier Martinez Canillas Cc: Thomas Zimmermann Cc: Zack Rusin Cc: dri-devel@lists.freedesktop.org Reviewed-by: Javier Martinez Canillas Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher (cherry picked from commit a24019f6480fad5c077b5956eed942c8960323d6) Cc: # v6.8+ Signed-off-by: Greg Kroah-Hartman commit abce3276c57e36c955627307469b9f009057a467 Author: Yongqiang Sun Date: Mon Jul 6 15:15:07 2026 -0400 drm/amdkfd: fix 32-bit overflow in CWSR total size calculation commit 2b0386d4293920e690c0e017708f999b93cc729b upstream. total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). Signed-off-by: Yongqiang Sun Reviewed-by: Philip Yang Signed-off-by: Alex Deucher (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fd1691ec62701c982ea32e749678988c67fd4c21 Author: David Francis Date: Mon Jul 6 10:19:04 2026 -0400 drm/amdkfd: Check bounds on CRIU restore queue type and mqd size commit 47ea05f246bebc81c7796f56265cffd812cf0601 upstream. We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. Reviewed-by: David Yat Sin Signed-off-by: David Francis Signed-off-by: Alex Deucher (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 50319efb865f72db45f191c8709511746d58ee0a Author: David Francis Date: Thu May 21 09:18:59 2026 -0400 drm/amdkfd: Check bounds in allocate_event_notification_slot commit bb52249fbbe948875155ccd45cd8d74bf4ae747b upstream. The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist Signed-off-by: David Francis Reviewed-by: David Yat Sin Signed-off-by: Alex Deucher (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 14a631dca9df00fdbe0e8f1b0a1e4ee07baa3e31 Author: David Francis Date: Thu Jun 25 10:09:13 2026 -0400 drm/amdkfd: Use kvcalloc to allocate arrays commit 9c8b85f95c1d4736b967e17b8eb4a463c055bea3 upstream. There were a few instances in kfd_chardev.c of kvzalloc being used to allocate memory for an array. Switch those to kvcalloc, which - is the standard way of allocating a zero-initialized array - does a check for the mul overflowing Signed-off-by: David Francis Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit 60b048c93f7a3add39757ad65fe2bb6e58eeae23) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6253bb56bb2ebdf317d8b599ce737a2510cc2e17 Author: Icenowy Zheng Date: Tue Jul 14 15:36:41 2026 +0800 drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM commit 17e2030f37600994440f875dc410615d5c66ee6d upstream. The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*(). Cc: stable@vger.kernel.org Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Fixes: 4bc736f890ce ("drm/imagination: vm: make use of GPUVM's drm_exec helper") Signed-off-by: Icenowy Zheng Reviewed-by: Alessio Belle Link: https://patch.msgid.link/20260714073641.1935075-1-zhengxingda@iscas.ac.cn Signed-off-by: Alessio Belle Signed-off-by: Greg Kroah-Hartman commit c45fafa69fe3f79e319369cf665da89868e3ef98 Author: Luigi Santivetti Date: Tue Jul 7 16:17:16 2026 +0100 drm/imagination: fix error checking of pvr_vm_context_lookup() commit cf385cf6e713eba0720651174dac0b2d2f5bb8f8 upstream. Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]--- Fixes: d2d79d29bb98 ("drm/imagination: Implement context creation/destruction ioctls") Cc: stable@vger.kernel.org Signed-off-by: Luigi Santivetti Reviewed-by: Alessio Belle Link: https://patch.msgid.link/20260707-staging-ddkopsrc-2435-v1-1-24e160d44476@imgtec.com Signed-off-by: Alessio Belle Signed-off-by: Greg Kroah-Hartman commit b983a35dad3701399c692d7c6eb57d8b6ffc0929 Author: Shuvam Pandey Date: Wed Jul 1 11:44:34 2026 -0700 drm/imagination: Fix user array stride in pvr_set_uobj_array() commit 8dc8f3f4c2382fb7d1b1986ba8f33a2466cd3d7a upstream. pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available. Fixes: f99f5f3ea7ef ("drm/imagination: Add GPU ID parsing and firmware loading") Cc: stable@vger.kernel.org # v6.8+ Reviewed-by: Alessio Belle Signed-off-by: Shuvam Pandey Link: https://patch.msgid.link/6a456012.eb165e5c.113c2a.b71d@mx.google.com Signed-off-by: Alessio Belle Signed-off-by: Greg Kroah-Hartman commit c88fdbf3da26e0179629530cae7768cd3d4ead85 Author: Brajesh Gupta Date: Tue Jun 30 21:10:07 2026 +0530 drm/imagination: Fix double call to drm_sched_entity_fini() commit 4af24c27a39ba147a613a09e10b9e0f7294524c0 upstream. Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 ("drm/sched: Account entity GPU time"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]--- Fixes: eaf01ee5ba28 ("drm/imagination: Implement job submission and scheduling") Cc: stable@vger.kernel.org Signed-off-by: Brajesh Gupta Reviewed-by: Alessio Belle Link: https://patch.msgid.link/20260630-b4-sched_fix-v7-1-71aa39c62627@imgtec.com Signed-off-by: Alessio Belle Signed-off-by: Greg Kroah-Hartman commit c1954c66662de477a8f4309335b775f7b07bd28b Author: Nitin Gote Date: Sat Jul 11 00:40:28 2026 +0530 drm/xe: Hold a dma-buf reference for imported BOs commit 62775525a27c3b0d56382e08ba81ee2d322058b6 upstream. An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8023 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Cc: Thomas Hellstrom Cc: Christian Konig Cc: Matthew Auld Suggested-by: Thomas Hellstrom Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Reviewed-by: Thomas Hellström Signed-off-by: Nitin Gote Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20260710191027.260160-2-nitin.r.gote@intel.com (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 038d0b80ab77884b63593ade2dff01079dbe0bd0 Author: Matthew Brost Date: Wed Jul 1 18:24:34 2026 -0700 drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds commit 34a4dd45cf210c04fee773b0dbc350aec285f03c upstream. xe_vm_populate_pgtable() indexed the source PTE array (update->pt_entries) by the per-call loop counter, assuming each call starts at the first entry of the update. That holds for the CPU bind path (xe_migrate_update_pgtables_cpu), which populates a whole update in a single call, but not for the GPU bind path: write_pgtable() splits an update into MAX_PTE_PER_SDI (510) sized MI_STORE_DATA_IMM chunks, invoking the populate callback once per chunk with an advancing qword_ofs but a fresh command- buffer destination pointer. As a result, every chunk after the first re-read pt_entries from index 0 instead of from its true offset, so PTEs beyond the first 510 entries of a single update were programmed with the wrong physical pages, shifting the mapping by exactly MAX_PTE_PER_SDI pages. This stayed latent because a single update only exceeds 510 qwords when a large (e.g. 2M) region is bound as individual 4K PTEs rather than a single huge-page entry, which happens when the backing store is sufficiently fragmented. It was surfaced by the BO defrag path, which deliberately rebinds such fragmented ranges via the GPU bind path, producing deterministic data corruption offset by 510 pages. Index pt_entries by the chunk's absolute offset relative to update->ofs so both the CPU and GPU paths pick the correct entries. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Matthew Brost Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20260702012434.3861171-1-matthew.brost@intel.com (cherry picked from commit e6f2d0b757c4fb577a513c577140109d1d292a9a) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 90a8a938e0caecc9ee9dec3eb9eda92d66ba02a3 Author: Matthew Brost Date: Wed Jun 17 06:51:01 2026 -0700 drm/xe: Return error on non-migratable faults requiring devmem commit 136fb61ba8571076dc5d49350a0e6d002d740b74 upstream. Non-migratable faults that require devmem incorrectly jump to the 'out' label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. Reported-by: Sashiko Fixes: 4208fac3dce5 ("drm/xe: Add more SVM GT stats") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost Reviewed-by: Francois Dugast Link: https://patch.msgid.link/20260617135101.1245574-1-matthew.brost@intel.com (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac) Signed-off-by: Thomas Hellström Signed-off-by: Greg Kroah-Hartman commit 3e1f909556aa61b72523d0621e17fd1e1717d6d0 Author: Pavel Ondračka Date: Wed Jun 10 10:32:45 2026 +0200 drm/radeon: fix r100_copy_blit for large BOs commit f896e86273dbbebb5eac966b4a201b5c62a02e9a upstream. r100_copy_blit() copies BOs as 1024-pixel-wide ARGB8888 blits, so one GPU page becomes one blit row. Large copies are split into chunks of at most 8191 rows. The kernel register header names the packet coordinate dwords SRC_Y_X and DST_Y_X. In the BITBLT_MULTI description in R5xx_Acceleration_v1.5.pdf docs, these correspond to [SRC_X1 | SRC_Y1] and [DST_X1 | DST_Y1], which are signed 13-bit coordinates in the -8192..8191 range. The old code kept SRC/DST_PITCH_OFFSET at the BO base and used SRC_Y_X/DST_Y_X as the chunk address, so large BO moves could exceed that coordinate range. Compute per-chunk SRC/DST_PITCH_OFFSET bases and emit zero source and destination coordinates. r100_copy_blit() already packs SRC/DST_PITCH_OFFSET as pitch plus base offset, so large chunk addresses belong there rather than in the coordinate fields. This fixes Prison Architect corruption with 4096x4096 mipped textures after they are evicted to GTT under memory pressure on RV530. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/6716 Acked-by: Christian König Signed-off-by: Pavel Ondračka Signed-off-by: Alex Deucher (cherry picked from commit 87be26aee76239c6da03e599f238a426897f78ad) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fbb9effc81683e3ee75b41468f29f0e93b2954d8 Author: Wentao Liang Date: Sat Jun 6 15:56:06 2026 +0000 drm/nouveau/acr: fix missing nvkm_done() in error path of nvkm_acr_oneinit() commit c3027973f692077a1b66a9fb26d6a7c46c0dc72c upstream. In nvkm_acr_oneinit(), nvkm_kmap(acr->wpr) is invoked unconditionally at line 309 to obtain a mapping reference. Additionally, when both acr->wpr_fw and acr->wpr_comp are present, a second nvkm_kmap() is called inside the conditional block. Both mappings are expected to be released by nvkm_done(acr->wpr) at line 320 before the function returns successfully. However, when a mismatch is detected during the loop within the conditional block, the function returns -EINVAL at line 318 without calling nvkm_done(). This results in a leak of the kmap reference(s) acquired earlier. Fix the issue by invoking nvkm_done(acr->wpr) prior to the early return to ensure proper release of the mapping references. Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure boot"") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang Link: https://patch.msgid.link/20260606155606.77593-1-vulab@iscas.ac.cn Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 45db277b2e1e34bcc99a0852026791108339ec3e Author: Joonas Lahtinen Date: Mon Jun 22 16:25:39 2026 +0300 drm/i915/gem: Add missing nospec on parallel submit slot commit 914a76a9f08366434bf595700f62026b7a19a9cc upstream. Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo Fixes: e5e32171a2cf ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface") Cc: Matthew Brost Cc: Tvrtko Ursulin Signed-off-by: Joonas Lahtinen Reviewed-by: Matthew Brost Reviewed-by: Tvrtko Ursulin Cc: # v5.16+ Link: https://patch.msgid.link/20260622132539.165558-1-joonas.lahtinen@linux.intel.com (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 748d425e53c313d06c36c46e49e4fed5c7efc601 Author: Jani Nikula Date: Wed Jun 10 17:15:49 2026 +0300 drm/displayid: fix Tiled Display Topology ID size commit 90c0486a82e27393f9eaf3bb350f51a0bd38cb6b upstream. The Tiled Display Topology ID of a DisplayID Tiled Display Topology Data Block consists of three fields: - Tiled Display Manufacturer/Vendor ID Field (3 bytes) - Tiled Display Product ID Code Field (2 bytes) - Tiled Display Serial Number Field (4 bytes) i.e. a total of 9 bytes, not 8. The DisplayID Tiled Display Topology ID is used as the tile group identifier. Update both struct displayid_tiled_block topology_id member and struct drm_tile_group group_data member to full 9 bytes. The group data was missing the last byte of the serial number. I don't know whether there are known bug reports that might be linked to this, but it's plausible the last byte could be the differentiating part for the tile groups, and fewer tile groups might have been created than intended. Fixes: b49b55bd4fba ("drm/displayid: add displayid defines and edid extension (v2)") Fixes: 138f9ebb9755 ("drm: add tile_group support. (v3)") Cc: Dave Airlie Cc: stable@vger.kernel.org # v3.19+ Reviewed-by: Dave Airlie Link: https://patch.msgid.link/20260610141549.555605-1-jani.nikula@intel.com Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 5452eb5c166301d0ae00c71c31a6bc89d786cf78 Author: Thomas Zimmermann Date: Thu Jun 18 10:41:59 2026 +0200 drm/sysfb: Return errno code from drm_sysfb_get_visible_size() commit 7bab0f09d753f098977bbba3955d694c2e2c25da upstream. Change the return type of drm_sysfb_get_visible_size() to s64 so that it returns a possible errno code from _get_validated_size0(). Fix callers to handle the errno code. The currently returned unsigned type converts an errno code to a very large size value, which drivers interpret as visible size of the system framebuffer. Later efforts to reserve the framebuffer resource fail. The bug has been present since efidrm and vesadrm got merged. It was then part of each driver. Signed-off-by: Thomas Zimmermann Fixes: 32ae90c66fb6 ("drm/sysfb: Add efidrm for EFI displays") Fixes: a84eb6abe2b6 ("drm/sysfb: Add vesadrm for VESA displays") Reviewed-by: Javier Martinez Canillas Cc: Thomas Zimmermann Cc: Javier Martinez Canillas Cc: dri-devel@lists.freedesktop.org Cc: # v6.16+ Link: https://patch.msgid.link/20260618084327.46567-4-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 154795885e8f0033c918c815aece543168bee670 Author: Thomas Zimmermann Date: Thu Jun 18 10:41:58 2026 +0200 drm/sysfb: Avoid possible truncation with calculating visible size commit b771974988ec7ce077a7246fa0fa588c246fe581 upstream. Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32(). Signed-off-by: Thomas Zimmermann Fixes: 32ae90c66fb6 ("drm/sysfb: Add efidrm for EFI displays") Fixes: a84eb6abe2b6 ("drm/sysfb: Add vesadrm for VESA displays") Reported-by: Sashiko Closes: https://lore.kernel.org/dri-devel/20260617114027.1F2A71F000E9@smtp.kernel.org/ Cc: Thomas Zimmermann Cc: Javier Martinez Canillas Cc: dri-devel@lists.freedesktop.org Cc: # v6.16+ Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260618084327.46567-3-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 4e109faa9ea2b6c04cc5a99e76db3126575a59d1 Author: Junrui Luo Date: Wed Jun 10 18:01:28 2026 +0800 drm/nouveau: fix reversed error cleanup order in ucopy functions commit ab99ead646b1b833ecd57fe577a2816f2e848167 upstream. nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence. Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Reported-by: Yuhao Jiang Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo Link: https://patch.msgid.link/SYBPR01MB7881484D91A6F80271415F71AF1A2@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman commit 315d2e5741a81b0be763e80413a2677e22b7e596 Author: Mario Limonciello Date: Fri Jun 12 21:07:24 2026 -0500 drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 commit 84c4c36acd5c4b2558b5069f869a165b2c655c84 upstream. Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. Fixes: ac9287055ff1 ("drm/amdgpu: add gfx shadow CS IOCTL support") Reviewed-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3fb10ec43c25a6b2e9b8335bd162ca7688e01e37 Author: Timur Kristóf Date: Mon May 25 13:33:18 2026 +0200 drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT commit ee94a65f192c05c543b4d3ad7137cd696b5c18fc upstream. The UVD code relies on GTT to GTT moves in order to ensure that its BOs don't cross 256M segments. Fixes: bfe5e585b44f ("drm/ttm: move last binding into the drivers.") Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 21fd45e5e2628d00b478590bcc3d14d3de5d45b6) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9c2b01508831b7e74ed48e4bc6a4382298dd9b10 Author: Jiqian Chen Date: Thu Jun 4 18:30:23 2026 +0800 drm/amdgpu/gfx9: Fix Ring and IB test fail after mode2 commit 85ed06d990ff73212b5a91a406671cabd962e521 upstream. For Renior APU with gfx9, in some test scenarios with disabling ring_reset, like accessing an unmapped invalid address, it can trigger a gpu job timeout event, then driver uses Mode2 reset to reset GPU, but after Mode2 compute Ring test and IB test fail randomly. It because the HQDs of MECs are always active before or after Mode2, that causes MECs use stale HQDs when MECs are unhalted before driver restore MQDs, and causes CPC and CPF are still stuck after Mode2, then causes compute Ring and IB tests fail. So, add sequences to deactivate HQDs of MECs in suspend IP function of the resetting process. v2: Move all sequences into a new function gfx_v9_0_cp_mode2_clear_state (Ray Huang) To check reset Mode2 method in the if condition (Ray Huang) v3: Move all sequences before Mode2 instead of after Mode2 (Timur Kristóf) v4: Call amdgpu_gfx_rlc_enter/exit_safe_mode int the begin and end of gfx_v9_0_deactivate_kcq_hqd (Alex Deucher) Signed-off-by: Jiqian Chen Reviewed-by: Huang Rui Reviewed-by: Timur Kristóf Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher (cherry picked from commit c3988a7ad4799514447294f04f063b422e0551df) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f835eda74cf6565a4f2554152cb5e1a4d7c70a5a Author: Thomas Zimmermann Date: Thu Jun 18 10:42:00 2026 +0200 drm/sysfb: Avoid truncating maximum stride commit 9206b22fb959f4a9cf1921f34aed0df1dcb1ab04 upstream. Passing a maximum as 64-bit type to drm_sysfb_get_validated_int0() can truncate the value to 32 bits. Use drm_sysfb_get_validated_size0(), which uses 64-bit arithmetics. Then test the returned stride against the limits of int to avoid truncations in the returned value. A valid stride is in the range of [1, INT_MAX] inclusive. Signed-off-by: Thomas Zimmermann Reported-by: Sashiko Closes: https://lore.kernel.org/dri-devel/20260617114016.5A5991F000E9@smtp.kernel.org/ Fixes: 32ae90c66fb6 ("drm/sysfb: Add efidrm for EFI displays") Fixes: a84eb6abe2b6 ("drm/sysfb: Add vesadrm for VESA displays") Cc: Thomas Zimmermann Cc: Javier Martinez Canillas Cc: dri-devel@lists.freedesktop.org Cc: # v6.16+ Reviewed-by: Javier Martinez Canillas Link: https://patch.msgid.link/20260618084327.46567-5-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 7daefc6d519524fbbe2ebc8cc635e6dfd0464e65 Author: Thomas Zimmermann Date: Thu Jun 18 10:41:57 2026 +0200 drm/sysfb: Do not page-align visible size of the framebuffer commit 134844856c399bfa9462a159dcf860bfdb748055 upstream. Only return the actually visible size of the system framebuffer in drm_sysfb_get_visible_size_si(). Drivers use this size value for reserving access to framebuffer memory. Increasing the value can make later attempts to do so fail. Signed-off-by: Thomas Zimmermann Fixes: 32ae90c66fb6 ("drm/sysfb: Add efidrm for EFI displays") Fixes: a84eb6abe2b6 ("drm/sysfb: Add vesadrm for VESA displays") Reviewed-by: Javier Martinez Canillas Cc: Thomas Zimmermann Cc: Javier Martinez Canillas Cc: dri-devel@lists.freedesktop.org Cc: # v6.16+ Link: https://patch.msgid.link/20260618084327.46567-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit ddba17b3dfa0efc80d6c98621c2fb7af66adb622 Author: Mario Limonciello Date: Fri Jun 12 21:11:53 2026 -0500 drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO commit 93475c34111916df71c63e510fc52db01351f809 upstream. The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller's VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &(bo_va)->valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. Fixes: 4d82724f7f2b ("drm/amdgpu: Add mapping info option for GEM_OP ioctl") Reviewed-by: Alex Deucher Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d068a2f53afc8310a1b9e8196287a59fb0adbf66 Author: Timur Kristóf Date: Mon May 25 13:33:19 2026 +0200 drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older commit 8002b744ad70055ef11ff7d0a7d685bfe8ffe6e4 upstream. These UVD versions don't fully support GPUVM and are only validated to work when their VCPU BO is placed in VRAM. Signed-off-by: Timur Kristóf Reviewed-by: Christian König Signed-off-by: Alex Deucher (cherry picked from commit 01b8dfc0660db5d6cdd62c22dc20f774a26ce853) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b3a01cda0ae169cb1f128a16d13c478488c50c1b Author: Timur Kristóf Date: Mon May 25 13:33:20 2026 +0200 drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't at 0 (v2) commit 32bd35f068a3507a1b3922cd12ea2985fc58c85b upstream. UVD 4.x and older can only access MSG, FEEDBACK buffers from a specific 256M VRAM segment that the VCPU BO is also located in. We already modify all placements of the given BO to ensure the BO is placed within this segment. Previously, it always assumed that the VCPU segment is the first 256M of VRAM, even though under some conditions the VCPU BO could be allocated outside this segment, which made UVD non-functional as the BOs were not inside the same segment as the UVD VCPU BO. Solve that by using the segment where the VCPU BO actually is. This fixes an issue with UVD failing to initialize on SI/CIK when resizable BAR is enabled and the VCPU BO is allocated in a different segment. v2: - For other BOs, keep using the same UVD segment as before. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/3851 Reviewed-by: Christian König Signed-off-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit cbfd4d3fc2061a1ec8e9d36e65973ac3e813358a) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e28420e36542ae8b66a5bdcec419525f521bddf8 Author: Asad Kamal Date: Fri Jun 5 23:44:08 2026 +0800 drm/amdgpu/gfx: fix cleaner shader IB buffer overflow commit 3e864bf2a32a1cbdf1e0f9c5a5a4176e8575f4a3 upstream. The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) Fixes: d361ad5d2fc0 ("drm/amdgpu: Add sysfs interface for running cleaner shader") Suggested-by: Lijo Lazar Signed-off-by: Asad Kamal Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a) CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d5c70523cafa26ad2c7a37b612849abe2683baa8 Author: Ashutosh Desai Date: Sun May 10 20:31:28 2026 +0000 drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers commit 6b89ba3dba2f583626fb693e47e951ffb8bf591f upstream. Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: # v3.17+ Signed-off-by: Ashutosh Desai Reviewed-by: Lyude Paul [added fixes tag] Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260510203128.2884846-1-ashutoshdesai993@gmail.com Signed-off-by: Greg Kroah-Hartman commit e2c29d51c0f65459ae5bbf7ccc302df4c359c473 Author: Alessio Belle Date: Mon Mar 30 08:56:37 2026 +0100 drm/imagination: Fit paired fragment job in the correct CCCB commit 4baf9e70cb756d78dd56419f8baee2978a72d0c3 upstream. For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20 Fixes: eaf01ee5ba28 ("drm/imagination: Implement job submission and scheduling") Cc: stable@vger.kernel.org Signed-off-by: Alessio Belle Reviewed-by: Brajesh Gupta Link: https://patch.msgid.link/20260330-job-submission-fixes-cleanup-v1-2-7de8c09cef8c@imgtec.com Signed-off-by: Matt Coster Signed-off-by: Greg Kroah-Hartman commit 1e5827839ad0ceb0079d1560c321fa3656b54f21 Author: Ashutosh Desai Date: Fri Apr 10 04:19:01 2026 +0000 drm/dp/mst: fix buffer overflows in sideband chunk accumulation commit 55bd5e685bda455b9b50c835f8c8442d52a344a3 upstream. drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection. Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: # v3.17+ Signed-off-by: Ashutosh Desai Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260410041901.2438960-1-ashutoshdesai993@gmail.com Signed-off-by: Greg Kroah-Hartman commit 533d9e2bede4aeefdc2a0561d7071cfede95958f Author: Ashutosh Desai Date: Sun May 10 20:17:33 2026 +0000 drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers commit 1a8f537f5a1eeac941f262fe73078d6b08ba83c0 upstream. drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: # v3.17+ Signed-off-by: Ashutosh Desai Reviewed-by: Lyude Paul [added missing fixes tag] Signed-off-by: Lyude Paul Link: https://patch.msgid.link/20260510201733.2882224-1-ashutoshdesai993@gmail.com Signed-off-by: Greg Kroah-Hartman commit c0384d6872f4dc2701960048a0be1a12a8d2dc6e Author: Vitor Soares Date: Tue May 5 14:47:05 2026 +0100 drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() commit 2d8b08844c0ecc6f2002fa68711e779aa18c8585 upstream. The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks. Link: https://lore.kernel.org/all/fbde0659-78f3-46e4-98cf-d832f765a18b@ideasonboard.com/ Cc: stable@vger.kernel.org # 6.1.x Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver") Reviewed-by: Tomi Valkeinen Signed-off-by: Vitor Soares Reviewed-by: Luca Ceresoli Link: https://patch.msgid.link/20260505134705.188661-2-ivitro@gmail.com Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman commit 943fa73ea0efa335d9c1800fcfac47915de4ff89 Author: Alessio Belle Date: Mon Mar 30 08:56:36 2026 +0100 drm/imagination: Count paired job fence as dependency in prepare_job() commit 9cd74f935306cd857f46686975c43383e1d95f94 upstream. The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]--- Fixes: eaf01ee5ba28 ("drm/imagination: Implement job submission and scheduling") Cc: stable@vger.kernel.org Signed-off-by: Alessio Belle Reviewed-by: Brajesh Gupta Link: https://patch.msgid.link/20260330-job-submission-fixes-cleanup-v1-1-7de8c09cef8c@imgtec.com Signed-off-by: Matt Coster Signed-off-by: Greg Kroah-Hartman commit 6ab29a86835721566f0c26bd7bebcdcdcb0cb093 Author: Chen Ni Date: Mon Feb 9 11:31:23 2026 +0800 drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() commit 45895f4d4d5f222d07412f90664f88b059627859 upstream. Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available. Fixes: 718b3bb9c0ab ("drm/rockchip: analogix_dp: Expand device data to support multiple edp display") Cc: stable@vger.kernel.org Signed-off-by: Chen Ni Reviewed-by: Dragan Simic Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/20260209033123.1089370-1-nichen@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 50cd8a7e98dd21c67a235934ebf3460560c3eb93 Author: Sergey Shtylyov Date: Fri Jan 30 23:35:42 2026 +0300 drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video() commit 46c31e1604d121221167cb09380de8c7d53290b9 upstream. The result of cdn_dp_reg_write() is checked everywhere (with the error being logged by the callers) except one place in cdn_dp_config_video(). Add the missing result check, bailing out early on error... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399") Signed-off-by: Sergey Shtylyov Cc: stable@vger.kernel.org Reviewed-by: Chaoyi Chen Signed-off-by: Heiko Stuebner Link: https://patch.msgid.link/adf6b313-f7db-4d8f-9000-8c65446ba041@auroraos.dev Signed-off-by: Greg Kroah-Hartman commit 86ab4d93b3d478378db84f4a6738e33c19fc009e Author: Tomi Valkeinen Date: Wed Mar 11 11:14:44 2026 +0200 drm/tidss: Fix missing drm_bridge_add() call commit 83084bb36847cbd2b13743f7333aaca12613a72b upstream. tidss encoder-bridge is not added with drm_bridge_add() call, which leads to: [drm] Missing drm_bridge_add() before attach Add the missing call, using devm_drm_bridge_add() variant to get the drm_bridge_remove() handled automatically. The commit marked with the Fixes tag (from v6.6) is the commit that added the encoder bridge without drm_bridge_add(). However, this fix is not directly applicable there as devm_drm_bridge_alloc() was not used to alloc the bridge, so using devm version for drm_bridge_add() wouldn't be safe. Instead, drm_bridge_add() and drm_bridge_remove() would be needed there, but that would require new plumbing code as we don't have a separate cleanup function in the tidss_encoder.c, not in the tidss_kms.c from which the encoder is created. Also, there has been no reported bugs caused by the missing drm_bridge_add(). The drm_bridge_add() initializes the bridge's hpd_mutex, but HPD is not used for the encoder bridge. drm_bridge_add() also adds the bridge to the global bridge_list, which is only used in of_drm_find_bridge(), and again that is not used for the encoder bridge. Thus, while the original commit is not right, there should be no bugs caused by it, and for the time being I'm not sending a patch for the stable kernels for the original commit. This fix applies on top of commit 66cdf05f8548 ("drm/tidss: encoder: convert to devm_drm_bridge_alloc()"), which changes the tidss_encoder.c to use the devm variant (added in v6.17). The warning print was added in v6.19, so applying this fix to v6.17+ gets rid of the warning for all kernel versions. Cc: stable@vger.kernel.org # v6.17+ Fixes: c932ced6b585 ("drm/tidss: Update encoder/bridge chain connect model") Acked-by: Maxime Ripard Link: https://patch.msgid.link/20260311-tidss-minor-fixes-v2-2-cb4479784458@ideasonboard.com Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman commit 300a2d970a535d9be35884fbf06c63397496441a Author: Biju Das Date: Mon Mar 30 11:44:44 2026 +0100 drm: renesas: rzg2l_mipi_dsi: Move rzg2l_mipi_dsi_set_display_timing() commit 5bfa858d53bb252d7a012c2e0a97ae18182edfb1 upstream. The RZ/G2L hardware manual (Rev. 1.50, May 2025), Section 34.4.2.1, requires display timings to be set after the HS clock is started. Move rzg2l_mipi_dsi_set_display_timing() from rzg2l_mipi_dsi_atomic_pre_enable() to rzg2l_mipi_dsi_atomic_enable(), placing it after rzg2l_mipi_dsi_start_hs_clock(). Drop the unused ret variable from rzg2l_mipi_dsi_atomic_pre_enable(). Fixes: 5ce16c169a4c ("drm: renesas: rz-du: Add atomic_pre_enable") Fixes: 7a043f978ed1 ("drm: rcar-du: Add RZ/G2L DSI driver") Cc: stable@vger.kernel.org Reviewed-by: Tommaso Merciai Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260330104450.128512-2-biju.das.jz@bp.renesas.com Signed-off-by: Biju Das Signed-off-by: Greg Kroah-Hartman commit aa8ad3e0d1fe9c80560751920f0fff7809f46c7e Author: Biju Das Date: Mon Mar 30 11:44:45 2026 +0100 drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay commit 7cbba8a8ba0219a267844d3116dbc77cecb4fcf8 upstream. The RZ/G2L hardware manual (Rev. 1.50, May 2025), Section 34.4.2.1, requires waiting at least 1 msec after deasserting the CMN_RSTB signal before the DSI-Tx module is ready. Increase the delay from 1 usec to 1 msec by replacing udelay(1) with fsleep(1000) for RZ/G2L SoCs. Fixes: 7a043f978ed1 ("drm: rcar-du: Add RZ/G2L DSI driver") Cc: stable@vger.kernel.org Reviewed-by: Tommaso Merciai Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260330104450.128512-3-biju.das.jz@bp.renesas.com Signed-off-by: Biju Das Signed-off-by: Greg Kroah-Hartman commit 786d690257ec7a0c839f8710456e444ce3f1348b Author: Chengfeng Ye Date: Fri Jul 24 18:38:56 2026 +0800 bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() [ Upstream commit 2d66a033864e27ab8d5e44cb36f31d9d2413bee4 ] tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Chengfeng Ye Reviewed-by: Emil Tsalapatis Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/87fr18lmzo.fsf%40cloudflare.com/ Link: https://lore.kernel.org/netdev/20260719161630.2901208-1-nicoyip.dev%40gmail.com/ [v1] Link: https://patch.msgid.link/20260724103856.3399001-1-nicoyip.dev@gmail.com Signed-off-by: Eduard Zingerman Signed-off-by: Sasha Levin commit 3a924139cf526b9b3524e01f2eaeb09faac8f564 Author: Lorenzo Bianconi Date: Mon Jul 20 13:22:28 2026 +0200 net: airoha: fix ETS channel derivation in airoha_tc_setup_qdisc_ets() [ Upstream commit 649ea07fc25a17aa51bff710baac1ab161022a7c ] Derive the hardware QoS channel from opt->parent instead of opt->handle in airoha_tc_setup_qdisc_ets(). The ETS qdisc handle is either user-specified or auto-allocated by qdisc_alloc_handle() and bears no relation to the HTB leaf classid that identifies the hardware channel. HTB derives the channel from TC_H_MIN(opt->classid), and ETS is always attached as a child of an HTB leaf, so its opt->parent matches that classid. Using opt->handle instead can cause two ETS qdiscs on different HTB leaves to collide on the same hardware channel, corrupting scheduler configuration and stats. Fixes: 20bf7d07c956 ("net: airoha: Add sched ETS offload support") Reviewed-by: Simon Horman Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260720-airoha-ets-handle-fix-v2-1-6f7129ddc06f@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 391a23c503856323300b26f7d2cf70048b48d1a5 Author: Minhong He Date: Mon Jul 20 15:25:18 2026 +0800 mctp: check register_netdevice_notifier() error in mctp_device_init() [ Upstream commit d9a33cadc70a94c1582f65e6042e81027cd200c6 ] mctp_device_init() handles errors from rtnl_af_register() and rtnl_register_many(), but ignores the return value of register_netdevice_notifier(). If notifier registration fails, init can still return success while the module is only partially initialized. Check the notifier registration error and fail module init early. Fixes: 583be982d934 ("mctp: Add device handling and netlink interface") Signed-off-by: Minhong He Link: https://patch.msgid.link/20260720072518.112614-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 74ecebfbf1555605c5c512f6ce565806a459022d Author: Clark Wang Date: Mon Jul 20 09:25:08 2026 +0800 ptp: netc: explicitly clear TMR_OFF during initialization [ Upstream commit c3f2fc231a39e29fe9f0adc14a3ecc3c1260d3c5 ] The NETC timer does not support function level reset, so TMR_OFF_L/H registers are not cleared by pcie_flr(). If TMR_OFF was set to a non-zero value in a previous binding, it will persist across driver rebind and cause inaccurate PTP time. There is also a hardware issue: after a warm reset or soft reset, TMR_OFF_L/H registers appear to be cleared to zero, but the timer clock domain internally retains the stale value. When the timer is re-enabled, TMR_CUR_TIME continues to track the old offset until TMR_OFF is written explicitly. This can cause incorrect PTP timestamps and even PTP clock synchronization failures. Per the recommendation from the IP team, explicitly write 0 to TMR_OFF in netc_timer_init() to flush the internally cached value and ensure TMR_CUR_TIME follows the freshly initialized counter. Fixes: 87a201d59963 ("ptp: netc: add NETC V4 Timer PTP driver support") Signed-off-by: Clark Wang Signed-off-by: Wei Fang Reviewed-by: Vadim Fedorenko Reviewed-by: Breno Leitao Link: https://patch.msgid.link/20260720012508.23227-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 16df2d154ec82e2f7e7585b4fa154751ba37729a Author: Cen Zhang (Microsoft) Date: Sun Jul 19 17:03:57 2026 -0400 rds: tcp: unregister sysctl before tearing down listen socket [ Upstream commit 167e54c703ccd4fa028feb568b0d1002020cff86 ] rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer. Fixes: 7f5611cbc487 ("rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxy") Reported-by: AutonomousCodeSecurity@microsoft.com Link: https://lore.kernel.org/all/20260719203718.9680-1-blbllhy@gmail.com Reviewed-by: Allison Henderson Signed-off-by: Cen Zhang (Microsoft) Link: https://patch.msgid.link/20260719210357.10179-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1db34097998cc97b665ba1727cdfd4e6559cbd37 Author: Nikola Z. Ivanov Date: Sun Jul 19 13:57:59 2026 +0300 ipv6: Change allocation flags to match rcu_read_lock section requirements [ Upstream commit 313a123e1fca8827bb463db1f4bb211309764563 ] Since the call to __ip6_del_rt_siblings has been converted under rcu read lock and it only has one call point we should no longer block or yield. Our stack trace from the syzbot reproducer looks as follows: __ip6_del_rt_siblings rtnl_notify (Here we pass gfp_any() -> GFP_KERNEL) nlmsg_notify nlmsg_multicast nlmsg_multicast_filtered netlink_broadcast_filtered (GFP_KERNEL passed from earlier) netlink_broadcast_filtered can yield if GFP_KERNEL is passed, which we do not want to happen. Fix this by changing the allocation flag of rtnl_notify. Also change the flag passed to nlmsg_new. Even though it is not related to the syzbot generated bug it still falls under the same requirements. Reported-by: syzbot+84d4a405ed798b40c96d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=84d4a405ed798b40c96d Fixes: bd11ff421d36 ("ipv6: Get rid of RTNL for SIOCDELRT and RTM_DELROUTE.") Signed-off-by: Nikola Z. Ivanov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260719105759.558050-1-zlatistiv@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 684d4d0bda95a3fb21b3e29ff0f668f657707b54 Author: Paul Greenwalt Date: Fri Jul 17 11:53:32 2026 -0700 ice: prevent tstamp ring allocation for non-PF VSI types [ Upstream commit 144539bbfd3cea1ab0fb6f5216d6004c1f4f029b ] The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues. Fixes: ccde82e90946 ("ice: add E830 Earliest TxTime First Offload support") Signed-off-by: Paul Greenwalt Reviewed-by: Przemek Kitszel Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260717185340.3595286-11-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a32604e8d9e2ca058e2605845f8d793cee641ce2 Author: Marcin Szycik Date: Fri Jul 17 11:53:28 2026 -0700 ice: fix LAG recipe to profile association [ Upstream commit d6da9b7d48599db078aea6144997a381f8d90d45 ] ice_init_lag() associates recipes to profiles, assuming that Link Aggregation-related profiles will always have profile ID lower than 70 (ICE_PROFID_IPV6_GTPU_IPV6_TCP_INNER). This value seems arbitrary and might not always be valid for some versions of DDP package, i.e. LAG profiles may have profile ID greater than 70. This would lead to misconfigured switch and LAG not working properly. Fix it by checking up to maximum profile ID. Fixes: 1e0f9881ef79 ("ice: Flesh out implementation of support for SRIOV on bonded interface") Signed-off-by: Marcin Szycik Reviewed-by: Michal Swiatkowski Reviewed-by: Aleksandr Loktionov Reviewed-by: Dave Ertman Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260717185340.3595286-7-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3a81345467674f5ca84cd04a9efe3ec8a8dbdbf8 Author: Vincent Chen Date: Fri Jul 17 11:53:23 2026 -0700 ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV [ Upstream commit 99d0f42b0e5c57e4c02070a908aaff082881293a ] Currently ice_eswitch_attach_vf() is called unconditionally in ice_start_vfs(), which causes VF creation to fail when CONFIG_ICE_SWITCHDEV is not defined. Fix this by adding switchdev mode checks at the call sites before calling ice_eswitch_attach_vf(), consistent with how ice_eswitch_attach_sf() is already handled in ice_devlink_port_new(). This is similar to commit aacca7a83b97 ("ice: allow creating VFs for !CONFIG_NET_SWITCHDEV") which fixed the same issue for the previous ice_eswitch_configure() API. Fixes: 415db8399d06 ("ice: make representor code generic") Signed-off-by: Vincent Chen Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260717185340.3595286-2-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5d54d603cf3e96b92c66501d758abbbcd4f406c4 Author: Li RongQing Date: Fri Jul 17 22:32:30 2026 +0800 net: ipv6: fix dif and sdif mismatch in raw6_icmp_error [ Upstream commit 440e274da4d1b93c7df2cb0ce893c3009dd4db55 ] In raw6_icmp_error(), raw_v6_match() is called with inet6_iif(skb) passed to both the 'dif' and 'sdif' arguments. This is a copy-paste or typo error, as the last argument should represent the secondary interface index (sdif). This mismatch breaks ICMPv6 error handling for IPv6 raw sockets in VRF (Virtual Routing and Forwarding) environments. When a raw socket is bound to a VRF master device, raw_v6_match() fails to find a match because it is not given the correct sdif value, causing the socket to miss relevant ICMPv6 error notifications. Fix this by properly passing inet6_sdif(skb) as the last argument to raw_v6_match(). Fixes: 5108ab4bf446fa ("net: ipv6: add second dif to raw socket lookups") Signed-off-by: Li RongQing Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260717143230.1836-1-lirongqing@baidu.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e60e6009d3baed030b7622481b5067beb158453b Author: Hariprasad Kelam Date: Fri Jul 17 14:13:49 2026 +0530 octeontx2-pf: tc: fix egress ratelimiting [ Upstream commit bb0d96ebe5f4d1acccf4dc36ca7f01f9a8fa1ba1 ] The egress rate calculation computes an incorrect mantissa and exponent, causing up to ~50% deviation from the configured rate at lower speeds. Rework the computation to follow the hardware rate formula: rate = 2 * (1 + mantissa/256) * 2^exp / (1 << div_exp) Keep div_exp = 0 and derive exp and mantissa from half of the requested rate. Rates below 2 Mbps are floored to the smallest encodable step (exp = 0, mantissa = 0). Fixes: e638a83f167e ("octeontx2-pf: TC_MATCHALL egress ratelimiting offload") Signed-off-by: Hariprasad Kelam Signed-off-by: Nitin Shetty J Link: https://patch.msgid.link/20260717084349.2227796-1-nshettyj@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d612754a515cb1f46e159f13be1b3dcdf5d6a5bd Author: Alexei Lazar Date: Fri Jul 17 10:51:25 2026 +0300 net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation [ Upstream commit 9173e1d3c7c7d49a71eee813091f9e834ec7cee5 ] Credit Based (CB) TSA is not supported by the mlx5 driver, so reject any configurations that specify it. Fixes: 08fb1dacdd76 ("net/mlx5e: Support DCBNL IEEE ETS") Signed-off-by: Alexei Lazar Reviewed-by: Carolina Jubran Signed-off-by: Tariq Toukan Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/20260717075125.1244877-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a7e430349fc5ee9750731b384e8e742c471924a7 Author: Alexei Lazar Date: Fri Jul 17 10:51:24 2026 +0300 net/mlx5e: Report zero bandwidth for non-ETS traffic classes [ Upstream commit ffb1873b2df11945b8c395e859169248675c91c5 ] The IEEE 802.1Qaz standard defines that bandwidth allocation percentages only apply to Enhanced Transmission Selection (ETS) traffic classes. For STRICT and VENDOR transmission selection algorithms, bandwidth percentage values are not applicable. Currently for non-ETS 100 bandwidth is being reported for all traffic classes in the get operation due to hardware limitation, regardless of their TSA type. Fix this by reporting 0 for non-ETS traffic classes. Fixes: 820c2c5e773d ("net/mlx5e: Read ETS settings directly from firmware") Signed-off-by: Alexei Lazar Reviewed-by: Carolina Jubran Signed-off-by: Tariq Toukan Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/20260717075125.1244877-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cdddc8188db46a472b7cfca94be2da15a9c4d72e Author: Yael Chemla Date: Fri Jul 17 10:33:06 2026 +0300 net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule [ Upstream commit d12956d083eb70f2c6d72711aebaf8c2ce21e170 ] esw_egress_acl_vlan_create() hardcodes num_dest=0 in its mlx5_add_flow_rules() call. When invoked from the non-bond path fwd_dest is NULL and num_dest=0 is correct. When invoked from esw_acl_egress_ofld_rules_create() during a bond event, fwd_dest is non-NULL and flow_act.action carries MLX5_FLOW_CONTEXT_ACTION_FWD_DEST, but _mlx5_add_flow_rules() rejects a non-NULL dest pointer paired with dest_num<=0 and returns -EINVAL. The error propagates as "configure slave vport egress fwd, err(-22)". The passive vport's egress ACL table ends up with its flow groups allocated but no FTEs, so prio-tagged packets are not popped and bond failover is broken on prio_tag_required devices. Fix by passing fwd_dest ? 1 : 0 as num_dest to match the actual number of destinations supplied. Fixes: bf773dc0e6d5 ("net/mlx5: E-Switch, Introduce APIs to enable egress acl forward-to-vport rule") Signed-off-by: Yael Chemla Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260717073306.1242399-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 87b39a8c875ca744b7de69af0a8ef8874cffccf1 Author: Gal Pressman Date: Fri Jul 17 10:23:38 2026 +0300 net/mlx5: Fix MCIA register buffer overflow on 32 dword reads [ Upstream commit 11c057d23465c7a5817a7284c896d19d54c0b616 ] The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords. Fixes: 271907ee2f29 ("net/mlx5: Query the maximum MCIA register read size from firmware") Signed-off-by: Gal Pressman Reviewed-by: Alex Lazar Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260717072338.1240582-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5f2ef3d53d37489a35005e43c7c37f98c900ace9 Author: Gal Pressman Date: Mon Nov 17 23:42:05 2025 +0200 net/mlx5: Refactor EEPROM query error handling to return status separately [ Upstream commit 2e4c44b12f4da60d3e8dcbc1ccf38bb28a878050 ] Matthew and Jakub reported [1] issues where inventory automation tools are calling EEPROM query repeatedly on a port that doesn't have an SFP connected, resulting in millions of error prints. Move MCIA register status extraction from the query functions to the callers, allowing use of extack reporting instead of a dmesg print when using the netlink API. [1] https://lore.kernel.org/netdev/20251028194011.39877-1-mattc@purestorage.com/ Cc: Matthew W Carlis Signed-off-by: Gal Pressman Reviewed-by: Jianbo Liu Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/1763415729-1238421-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: 11c057d23465 ("net/mlx5: Fix MCIA register buffer overflow on 32 dword reads") Signed-off-by: Sasha Levin commit 953d47cfe529a88ae321de5b74cc6e3046e31c43 Author: Runyu Xiao Date: Thu Jul 16 22:29:58 2026 +0800 raw: annotate lockless match fields in raw_v4_match() [ Upstream commit 18f116931f52e3c3303ad4b15ff41eb89b0e4239 ] raw_v4_match() is a lockless match helper under sk_for_each_rcu(). It still reads inet->inet_daddr, inet->inet_rcv_saddr and sk->sk_bound_dev_if with plain loads while bind, connect and bind-to-device paths can update the same match fields concurrently. Annotate only those mutable match fields in raw_v4_match(), and do so at the point of use instead of hoisting the bound-device read before the earlier short-circuit tests. Also annotate the raw bind writer and the shared IPv4 datagram connect writer used by raw sockets, so the address fields updated on bind and connect match explicit WRITE_ONCE() updates. This version intentionally leaves the shared disconnect-side IPv4 writers to follow-up cleanup and limits the writer changes here to the raw bind path and the datagram connect path directly exercised by raw sockets. Fixes: 0daf07e52709 ("raw: convert raw sockets to RCU") Signed-off-by: Runyu Xiao Link: https://patch.msgid.link/20260716142958.3064224-1-runyu.xiao@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8150c48fb978e01689f94ed80148f8a7499ae571 Author: Aldo Ariel Panzardo Date: Thu Jul 16 12:43:19 2026 -0300 net: qrtr: restrict socket creation to the initial network namespace [ Upstream commit 3b536db8fb32da9e9c62f2bb45e2e319331f0426 ] QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code). Fixes: bdabad3e363d ("net: Add Qualcomm IPC router") Signed-off-by: Aldo Ariel Panzardo Link: https://patch.msgid.link/20260716154319.3297699-1-qwe.aldo@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0d57d43d7c4c67b26f414e67959eb54de479377d Author: Chenguang Zhao Date: Wed Jul 22 10:53:53 2026 +0800 hinic: remove unused ethtool RSS user configuration buffers [ Upstream commit fe0c002928c6749b7f4a726f6f600f6dd70280ea ] rss_indir_user and rss_hkey_user are allocated and filled in __set_rss_rxfh() when the user configures RSS via ethtool, but nothing ever reads them. hinic_get_rxfh() fetches the state from the device, and the hardware is programmed from the original indir/key arguments. These buffers only leaked on driver unload. Drop the unused allocations, memcpys, and struct fields. Fixes: 4fdc51bb4e92 ("hinic: add support for rss parameters with ethtool") Signed-off-by: Chenguang Zhao Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260722025353.328179-1-chenguang.zhao@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8fc45a2a7cc24a27ccf1e3ac538600ef38235a36 Author: Eric Dumazet Date: Wed Jul 22 10:16:05 2026 +0000 ppp: annotate data races in ppp_generic [ Upstream commit 543adf072165aaf2e3b635c0476204f9658ed3bf ] Several fields in struct ppp can be read or updated concurrently from multiple CPUs without synchronization, causing data races: 1. ppp->mru is read concurrently in ppp_receive_nonmp_frame() while being updated via PPPIOCSMRU ioctl. Protect ppp->mru updates in PPPIOCSMRU with ppp_recv_lock(ppp). 2. PPPIOCGFLAGS reads ppp->flags, ppp->xstate, and ppp->rstate unlocked. Wrap the read in ppp_lock(ppp) to get a consistent snapshot. 3. ppp->debug is updated via PPPIOCSDEBUG and read concurrently on fast paths. Annotate reads with READ_ONCE() and writes with WRITE_ONCE(). 4. ppp->last_xmit and ppp->last_recv are updated on TX/RX data paths and read via PPPIOCGIDLE32 / PPPIOCGIDLE64 ioctls. Annotate with WRITE_ONCE() / READ_ONCE() and use max() to handle jiffies subtraction. 5. ppp->npmode[] is updated via PPPIOCSNPMODE and read on TX/RX paths. Annotate with WRITE_ONCE() / READ_ONCE(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Qingfang Deng Link: https://patch.msgid.link/20260722101605.2868548-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 19fe119dfa93fd7e50c05bafc88e4e4a00929231 Author: Eric Dumazet Date: Wed Jul 22 10:42:36 2026 +0000 ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup [ Upstream commit 853e164c2b321f0711361bc23505aaeb7dc432c3 ] When Linux forwards a packet and needs to generate an ICMP error, icmp_route_lookup() performs a reverse-path relookup. For non-local destinations, it performs a decoy lookup to find the expected egress interface (rt2->dst.dev) before validating the path with ip_route_input(). Currently, the decoy flow structure (fl4_2) only sets .daddr = fl4_dec.saddr, leaving .saddr, .flowi4_dscp, .flowi4_proto, .flowi4_mark, .flowi4_oif, .fl4_sport, .fl4_dport, and .flowi4_uid zeroed out. When policy routing rules (such as ip rule add from $SRC lookup 100, or dscp/fwmark/ipproto/port rules, or VRF bindings) are configured: 1. The decoy lookup fails to match the policy rule because saddr and other key flow selectors are missing in fl4_2. 2. It resolves a route using the default table instead, returning an incorrect egress netdev. 3. Passing the wrong netdev to ip_route_input() causes strict reverse-path filtering (rp_filter=1) to fail, logging false-positive "martian source" warnings and causing the relookup to fail. Fix this by initializing fl4_2 from fl4_dec and: - Swapping source/destination IP addresses. - Swapping L4 ports for transport protocols with ports (TCP, UDP, SCTP, DCCP) so port-based policy routing matches correctly. Non-port protocols (such as ICMP or GRE) leave the flowi_uli union fields intact to prevent corruption. - Setting .flowi4_oif = l3mdev_master_ifindex(route_lookup_dev) to ensure VRF routing tables are respected. - Setting .flowi4_flags |= FLOWI_FLAG_ANYSRC to allow output route lookups for non-local source IP addresses. - Using __ip_route_output_key() instead of ip_route_output_key() for fl4_2 so that raw FIB routing is used without triggering spurious XFRM policy lookups on the decoy flow (the actual XFRM lookup is performed later using fl4_dec). Fixes: 415b3334a21a ("icmp: Fix regression in nexthop resolution during replies.") Reported-by: Muhammad Ziad Closes: https://lore.kernel.org/netdev/CAOAwikA60AYKdFr_UDLyja3oU4hqyAE7uFZWqum5uRdaQsgRYg@mail.gmail.com/ Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://patch.msgid.link/20260722104236.2938082-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e037a41938c69e60acfa6362eeffd8649ea5e4c7 Author: Suman Ghosh Date: Wed Jul 15 10:50:07 2026 +0530 octeontx2-vf: set TC flower flag on MCAM entry allocation [ Upstream commit 0d4d31e3cc5dd6204fa1495c4107f5075acce5ed ] When MCAM entries are allocated for a VF netdev via the devlink mcam_count parameter, only OTX2_FLAG_NTUPLE_SUPPORT was set. That enabled ethtool ntuple filters but not tc flower offload. Also set OTX2_FLAG_TC_FLOWER_SUPPORT when entries are successfully allocated. Fixes: 2da489432747 ("octeontx2-pf: devlink params support to set mcam entry count") Signed-off-by: Suman Ghosh Signed-off-by: Ratheesh Kannoth Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260715052007.2099851-1-rkannoth@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 15a1c5f2ed2eeb3daad8d5766fd506aeda4710f3 Author: Yun Zhou Date: Mon Jul 13 23:09:45 2026 +0800 net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM [ Upstream commit 675ed582c1aa4d919dd535490de08c015005c653 ] Before commit 00d066a4d4ed ("netdev_features: convert NETIF_F_LLTX to dev->lltx"), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev->features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev->lltx flag, it placed 'dev->lltx = true' after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); lock(&qdisc_xmit_lock_key#6); lock(&qdisc_xmit_lock_key#3); Fix by moving dev->lltx = true before the early returns in both functions, restoring the original unconditional behavior. Fixes: 00d066a4d4ed ("netdev_features: convert NETIF_F_LLTX to dev->lltx") Signed-off-by: Yun Zhou Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260713150945.1779628-1-yun.zhou@windriver.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 55515c1b1285a119d004492ee6c46dd2aa7f8cd3 Author: vadik likholetov Date: Mon Jul 13 10:49:11 2026 +0300 net: stmmac: enable the MAC on link up for all supported speeds [ Upstream commit 9c99db3a2080b8c2cbbb1100369586a9bea43321 ] stmmac_mac_link_down() clears the MAC's transmit and receive enable bits. stmmac_mac_link_up() is expected to set them again through stmmac_mac_set(..., true), but it first switches on the negotiated speed and returns early for a speed the switch does not list. The MAC is then left gated off. The speed selection is split into three switches, keyed on the interface. The generic branch -- taken for everything that is neither USXGMII nor XLGMII, so including PHY_INTERFACE_MODE_10GBASER -- lists only SPEED_2500, SPEED_1000, SPEED_100 and SPEED_10. MGBE on Tegra234 runs 10GBASE-R into an Aquantia AQR113C. That PHY does rate matching, so phylink_link_up() replaces the media speed with the MAC-side interface speed before calling into the MAC: case RATE_MATCH_PAUSE: speed = phylink_interface_max_speed(link_state.interface); duplex = DUPLEX_FULL; The driver is therefore called as stmmac_mac_link_up(interface=10GBASER, speed=10000, duplex=1) which falls through to "default: return;". The interface stops passing traffic after the first link flap. The failure is easy to misread. The link still comes up, because the PHY is polled over MDIO and needs no MAC, so the interface reports carrier 1 at the media speed. The DMA is untouched, so its start bits stay set and descriptors are still consumed. Only the MAC itself is gated off: the receiver counts nothing (mmc_rx_framecount_gb stops advancing, RE is 0) and nothing reaches the wire (TE is 0). The interface survives boot only because stmmac_hw_setup(), called from ndo_open, enables the MAC unconditionally -- so the problem appears only once the cable has been unplugged and plugged back in, and "ip link set dev down && ip link set dev up" appears to fix it. The interface is not what the speed bits depend on: with the single exception of 2.5G, which is selected through the XGMII block on USXGMII and through the regular speed bits otherwise, each speed maps to one field of struct mac_link. The per-interface switches are speed validation, and phylink already validates the speed against priv->hw->link.caps. So collapse the three switches into one keyed on the speed alone, keeping the interface test only for the 2.5G case. This covers 10G on 10GBASE-R, and equally 5G, and 1G/100/10 on USXGMII, all of which hit "default: return;" today. A core that does not support a speed leaves the corresponding mac_link field at 0, and phylink will not offer it that speed in the first place. For dwxgmac2 at 10G, link.xgmii.speed10000 is XGMAC_CONFIG_SS_10000, which is 0 and is the correct speed selection for a 10GBASE-R MAC: ctrl then equals old_ctrl, the register write is skipped, and execution reaches stmmac_mac_set(..., true). Log an error in the default case, since a speed with no entry here leaves the MAC disabled and the symptom does not point at the cause. Fixes: d8ca113724e7 ("net: stmmac: tegra: Add MGBE support") Suggested-by: Maxime Chevallier Signed-off-by: vadik likholetov Reviewed-by: Jacob Keller Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260713074911.30090-1-vadikas@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1bcb737fb884dae99300e33613174e35bd132f79 Author: Nazim Amirul Date: Mon Jul 13 19:37:16 2026 -0700 net: stmmac: reset residual action in L3L4 filters on delete [ Upstream commit a448f821289934b961dd9d8d0beb006cc8937ba2 ] When deleting an L3/L4 flower filter entry, the action field is not reset. If a filter was previously configured with a drop action, that action may persist and affect subsequent filter configurations unintentionally. Clear the action field when the filter entry is deleted. Fixes: 425eabddaf0f ("net: stmmac: Implement L3/L4 Filters using TC Flower") Signed-off-by: Rohan G Thomas Signed-off-by: Nazim Amirul Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260714023716.29865-5-muhammad.nazim.amirul.nazle.asmade@altera.com Reviewed-by: Jakub Raczynski Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 370dde2b70e58d53cdb7222d4f4cda6e036ee372 Author: Nazim Amirul Date: Mon Jul 13 19:37:15 2026 -0700 net: stmmac: fix l3l4 filter rejecting unsupported offload requests [ Upstream commit 5536d7c843637e9430279b94935fcf7df98babb3 ] The basic flow parser in tc_add_basic_flow() does not validate match keys before proceeding. Unsupported offload configurations such as partial protocol masks, non-IPv4 network proto, or non-TCP/UDP transport proto are silently accepted instead of returning -EOPNOTSUPP. Add validation to return -EOPNOTSUPP early for: - No network or transport proto present in the key - Partial protocol mask (only full mask supported) - Network proto is not IPv4 - Transport proto is not TCP or UDP Each rejection includes an extack message so the user knows which part of the match is unsupported. Also propagate -EOPNOTSUPP from tc_add_basic_flow() in tc_add_flow() by returning it directly rather than using break. The break was silently discarding the error for FLOW_CLS_REPLACE operations where entry->in_use is already true, causing tc_add_flow() to return 0 (success) for unsupported replace requests. Fixes: 425eabddaf0f ("net: stmmac: Implement L3/L4 Filters using TC Flower") Signed-off-by: Rohan G Thomas Signed-off-by: Nazim Amirul Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260714023716.29865-4-muhammad.nazim.amirul.nazle.asmade@altera.com Reviewed-by: Jakub Raczynski Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 55d2a8d184e24239b4e934b3379c39e7e201682c Author: Nazim Amirul Date: Mon Jul 13 19:37:14 2026 -0700 net: stmmac: xgmac: fix l4 filter port overwrite on register update [ Upstream commit 9fcf274d93af17396f20cccb63f1d4c17492a000 ] The XGMAC_L4_ADDR register holds both source and destination port match values. The current implementation overwrites the entire register when configuring either port, so setting one silently erases the other. Fix this by reading the register first, then masking and updating only the relevant field before writing back. Fixes: 425eabddaf0f ("net: stmmac: Implement L3/L4 Filters using TC Flower") Signed-off-by: Rohan G Thomas Signed-off-by: Nazim Amirul Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260714023716.29865-3-muhammad.nazim.amirul.nazle.asmade@altera.com Reviewed-by: Jakub Raczynski Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 40413da850363fe9cefcac9a2242927effe7b766 Author: Russell King (Oracle) Date: Thu Jan 8 17:36:40 2026 +0000 net: stmmac: cores: remove many xxx_SHIFT definitions [ Upstream commit 8409495bf6c907a5bc9632464dbdd8fb619f9ceb ] We have many xxx_SHIFT definitions along side their corresponding xxx_MASK definitions for the various cores. Manually using the shift and mask can be error prone, as shown with the dwmac4 RXFSTS fix patch. Convert sites that use xxx_SHIFT and xxx_MASK directly to use FIELD_GET(), FIELD_PREP(), and u32_replace_bits() as appropriate. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1vdtw8-00000002Gtu-0Hyu@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Stable-dep-of: 9fcf274d93af ("net: stmmac: xgmac: fix l4 filter port overwrite on register update") Signed-off-by: Sasha Levin commit 4a3eea468a04103605c74c953065023379f78ac3 Author: Rohan G Thomas Date: Sat Nov 1 01:27:10 2025 +0800 net: stmmac: socfpga: Add hardware supported cross-timestamp [ Upstream commit fd8c4f6454963aa7ea895657472aa57f33779d57 ] Cross timestamping is supported on Agilex5 platform with Synchronized Multidrop Timestamp Gathering(SMTG) IP. The hardware cross-timestamp result is made available the applications through the ioctl call PTP_SYS_OFFSET_PRECISE, which inturn calls stmmac_getcrosststamp(). Device time is stored in the MAC Auxiliary register. The 64-bit System time (ARM_ARCH_COUNTER) is stored in SMTG IP. SMTG IP is an MDIO device with 0xC - 0xF MDIO register space holds 64-bit system time. This commit is similar to following commit for Intel platforms: Commit 341f67e424e5 ("net: stmmac: Add hardware supported cross-timestamp") Signed-off-by: Rohan G Thomas Link: https://patch.msgid.link/20251101-agilex5_ext-v2-4-a6b51b4dca4d@altera.com Signed-off-by: Jakub Kicinski Stable-dep-of: 9fcf274d93af ("net: stmmac: xgmac: fix l4 filter port overwrite on register update") Signed-off-by: Sasha Levin commit 01d45e6b2c500a611bfe0e197b8a9d62253875de Author: Rohan G Thomas Date: Sat Nov 1 01:27:08 2025 +0800 net: stmmac: socfpga: Enable TBS support for Agilex5 [ Upstream commit 4c00476d44804db3c16838299b87a11741cd0dbd ] Agilex5 supports Time-Based Scheduling(TBS) for Tx queue 6 and Tx queue 7. This commit enables TBS support for these queues. Signed-off-by: Rohan G Thomas Link: https://patch.msgid.link/20251101-agilex5_ext-v2-2-a6b51b4dca4d@altera.com Signed-off-by: Jakub Kicinski Stable-dep-of: 9fcf274d93af ("net: stmmac: xgmac: fix l4 filter port overwrite on register update") Signed-off-by: Sasha Levin commit dac8c2ab943a2698dc8a2d59cb7bfa14c6345238 Author: Rohan G Thomas Date: Sat Nov 1 01:27:07 2025 +0800 net: stmmac: socfpga: Agilex5 EMAC platform configuration [ Upstream commit 93d46ea3e984323fae0e5d2919cf5817e1297d41 ] Agilex5 HPS EMAC uses the dwxgmac-3.10a IP, unlike previous socfpga platforms which use dwmac1000 IP. Due to differences in platform configuration, Agilex5 requires a distinct setup. Introduce a setup_plat_dat() callback in socfpga_dwmac_ops to handle platform-specific setup. This callback is invoked before stmmac_dvr_probe() to ensure the platform data is correctly configured. Also, implemented separate setup_plat_dat() callback for current socfpga platforms and Agilex5. Signed-off-by: Rohan G Thomas Reviewed-by: Maxime Chevallier Tested-by: Maxime Chevallier Link: https://patch.msgid.link/20251101-agilex5_ext-v2-1-a6b51b4dca4d@altera.com Signed-off-by: Jakub Kicinski Stable-dep-of: 9fcf274d93af ("net: stmmac: xgmac: fix l4 filter port overwrite on register update") Signed-off-by: Sasha Levin commit d67136a931e5f76f476b72b685a3ef18b1da623f Author: Russell King (Oracle) Date: Thu Oct 16 15:36:51 2025 +0100 net: stmmac: remove xstats.pcs_* members [ Upstream commit 14f74bc6dc699f63b5a6dfa9b22229f0caea89f3 ] As a result of the previous commit, the pcs_link, pcs_duplex and pcs_speed members are not used outside of the interrupt handling code, and are only used to print their status using the misleading "Link is" messages that bear no relation to the actual status of the link. Remove the printing of these messages, these members, and the code that decodes them from the hardware. Reviewed-by: Andrew Lunn Signed-off-by: Russell King (Oracle) Tested-by: Maxime Chevallier Tested-by: Lad Prabhakar Link: https://patch.msgid.link/E1v9P63-0000000AolI-23Kf@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Stable-dep-of: 9fcf274d93af ("net: stmmac: xgmac: fix l4 filter port overwrite on register update") Signed-off-by: Sasha Levin commit 9f27c4f0ae35b5390ce4f7a54d3501144e41a54d Author: Xiang Mei (Microsoft) Date: Mon Jul 13 23:32:30 2026 +0000 bpf: tcp: fix double sock release on batch realloc [ Upstream commit 980a813452754f8001704744e92f7aa697c53dd3 ] bpf_iter_tcp_batch() releases the current batch via bpf_iter_tcp_put_batch(), which drops the socket refs and rewrites each slot with the socket cookie, then grows the batch. cur_sk/end_sk are kept for bpf_iter_tcp_resume(), but on realloc failure the function returns ERR_PTR() before resume runs, leaving cur_sk < end_sk over slots that now hold cookies rather than sock pointers. bpf_iter_tcp_seq_stop() then calls bpf_iter_tcp_put_batch() again and dereferences a cookie as a struct sock. Empty the batch on the failure path so stop() does not release it again. The sockets were already freed by the first bpf_iter_tcp_put_batch(), so nothing leaks, and a later read() rescans the bucket from the start instead of skipping it. The sibling GFP_NOWAIT failure path still holds real socket references and is left for stop() to release. BUG: KASAN: null-ptr-deref in __sock_gen_cookie Read of size 8 at addr 0000000000000059 by task exploit ... __sock_gen_cookie (net/core/sock_diag.c:28) bpf_iter_tcp_put_batch (net/ipv4/tcp_ipv4.c:2918) bpf_iter_tcp_seq_stop (net/ipv4/tcp_ipv4.c:3270) bpf_seq_read (kernel/bpf/bpf_iter.c:205) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 entry_SYSCALL_64_after_hwframe Kernel panic - not syncing: Fatal exception Fixes: cdec67a489d4 ("bpf: tcp: Make sure iter->batch always contains a full bucket snapshot") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Reviewed-by: Eric Dumazet Reviewed-by: Jordan Rife Link: https://patch.msgid.link/20260713233230.3553593-1-xmei5@asu.edu Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b43bb9ab600357d229a8721ddcf4cc8238067a4b Author: José Expósito Date: Fri Jul 3 17:07:43 2026 +0200 drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem [ Upstream commit b04a248cfa6cfa1e7dc9ce91cb1eb88b1a70dd69 ] drm_gem_shmem_test_purge [1] and drm_gem_shmem_test_get_pages_sgt [2] intermittently fail on ppc64le and s390x CI systems with a DMA address overflow: DMA addr 0x0000000100307000+4096 overflow (mask ffffffff, bus limit 0) WARNING: kernel/dma/direct.h:114 dma_direct_map_sg+0x778/0x920 drm_gem_shmem_test_purge: ASSERTION FAILED at drivers/gpu/drm/tests/drm_gem_shmem_test.c:330 Expected sgt is not error, but is: -5 The call chain leading to the failure is: drm_gem_shmem_test_purge() / drm_gem_shmem_test_get_pages_sgt() drm_gem_shmem_get_pages_sgt() drm_gem_shmem_get_pages_sgt_locked() [drm_gem_shmem_helper.c] dma_map_sgtable() [mapping.c] __dma_map_sg_attrs() dma_direct_map_sg() [direct.c] dma_direct_map_phys() [kernel/dma/direct.h] dma_capable() Checks addr against DMA mask -> FAILS: addr > 0xFFFFFFFF The root cause is that KUnit devices are initialized with a 32-bit DMA mask (DMA_BIT_MASK(32)) in lib/kunit/device.c. On ppc64le and s390x systems with physical memory above 4GB, page allocations can land at addresses that exceed this mask. When drm_gem_shmem_get_pages_sgt() attempts to DMA-map these pages via dma_map_sgtable(), the DMA layer rejects the mapping because the physical address overflows the 32-bit mask. The failure is intermittent because pages may or may not be allocated above 4GB on any given run depend on memory pressure. Fix by setting a 64-bit DMA mask on the device before calling drm_gem_shmem_get_pages_sgt() for all tests, following the same pattern already used in drm_gem_shmem_test_obj_create_private(). [1] https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/2643976103/test_s390x/15128551935/artifacts/jobwatch/logs/recipes/21561049/tasks/220716793/results/1014626315/logs/dmesg.log [2] https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/2643976103/test_ppc64le/15128551933/artifacts/jobwatch/logs/recipes/21561041/tasks/220716705/results/1014628163/logs/dmesg.log Fixes: 93032ae634d4 ("drm/test: add a test suite for GEM objects backed by shmem") Closes: https://datawarehouse.cki-project.org/issue/5345 Closes: https://datawarehouse.cki-project.org/issue/3184 Assisted-by: Claude:claude-4.6-opus Reviewed-by: Thomas Zimmermann Signed-off-by: José Expósito Link: https://patch.msgid.link/20260703150808.3832-1-jose.exposito89@gmail.com Signed-off-by: Sasha Levin commit 1b8fb5a20508bfb0db854e01214888c761b3a911 Author: Cen Zhang (Microsoft) Date: Tue Jul 14 00:15:41 2026 -0400 tipc: fix u16 MTU truncation in media and bearer MTU validation [ Upstream commit 9f29cd8a8e7901a2617c8064ce9f50fc67b97cb8 ] Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX. Fixes: 901271e0403a ("tipc: implement configuration of UDP media MTU") Reported-by: AutonomousCodeSecurity@microsoft.com Closes: https://lore.kernel.org/all/CAB8m9WgETt0AjmFwE=F-CKjGXsK6_WDv0=kbYRcC8-noo+amnA@mail.gmail.com Reviewed-by: Vadim Fedorenko Signed-off-by: Cen Zhang (Microsoft) Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260714041541.307702-1-blbllhy@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c8e4b2a567efb6e794c3e0af517f22b09cde0ab2 Author: Zhang Yi Date: Tue Jul 14 16:23:21 2026 +0800 iomap: correct the range of a partial dirty clear [ Upstream commit 88c26515313169806a412a362b32a1eca53d21bd ] The block range calculation in ifs_clear_range_dirty() is incorrect when partially clearing a range in a folio. We cannot clear the dirty bit of the first block or the last block if the start or end offset is not blocksize-aligned. This has not yet caused any issues since we always clear a whole folio in iomap_writeback_folio(). Fix this by rounding up the first block to blocksize alignment, and calculate the last block by rounding down (using truncation). Correct the nr_blks calculation accordingly. Fixes: 4ce02c679722 ("iomap: Add per-block dirty state tracking to improve performance") Signed-off-by: Zhang Yi Link: https://patch.msgid.link/20260714082325.325163-2-yi.zhang@huaweicloud.com Reviewed-by: Joanne Koong Reviewed-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 279339aa8bdcf9db40094cf2bcbd495c53dbe817 Author: Shuicheng Lin Date: Tue Jul 21 20:55:14 2026 +0000 drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() [ Upstream commit d2c6800ad1802bed72a6de1416536737f114f1d6 ] Commit 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a "simple" gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm->svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the unconditional xe_svm_init() call. Move the vm->size = 0 assignment out of the conditional so the xe_vm_is_closed() assert in xe_svm_fini() (and xe_svm_close()) holds for both modes. - Call xe_svm_close() for fault-mode VMs before xe_svm_fini(), matching the ordering used in xe_vm_close_and_put(). Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") Cc: Matthew Auld Assisted-by: Claude:claude-opus-4.7 Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260721205516.4058959-2-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit ca2a3587d577ba764e0fe628fb676244fc33ddd4) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit d18d9b2c29a124f924cc9ce75ab23b51aeecfe5f Author: Raag Jadav Date: Tue Jul 21 17:04:38 2026 +0530 drm/xe/i2c: Allow per domain unique id [ Upstream commit 5d8ed6b64220ad629aade5f174e3f690c37435f9 ] PCI bus, device and function can be same for devices existing across different domains. Allow per domain unique identifier while registering platform device to prevent name conflict. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Signed-off-by: Raag Jadav Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260721113438.651100-1-raag.jadav@intel.com Signed-off-by: Matt Roper (cherry picked from commit a79f6abc8b516b5bd906e2eca8121e3549ee163f) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 4fdb0f162ccdbe9626863b10003855703253fa29 Author: Harshaka Narayana Date: Mon Jul 13 07:09:15 2026 -0700 vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets [ Upstream commit 34a71f5361fc3adb5b7138da78750b0d535a8252 ] vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively. Fixes: 45dac1d6ea04 ("vmxnet3: Changes for vmxnet3 adapter version 2 (fwd)") Signed-off-by: Harshaka Narayana Reviewed-by: Ronak Doshi Reviewed-by: Sankararaman Jayaraman Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260713140915.3381715-1-harshaka.narayana@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18957373920caf5cdaf5cf32e5d1d7a99ca7700a Author: Qing Luo Date: Tue Jul 21 09:55:32 2026 +0800 sctp: auth: verify auth requirement when auth_chunk is NULL [ Upstream commit 8e04823c120b376ef7dab14b60ebf6823aa16c14 ] sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally. Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification of AUTH chunk") Signed-off-by: Qing Luo Acked-by: Xin Long Link: https://patch.msgid.link/20260721015532.120157-2-l1138897701@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ae0ec759865e02ef39574dc8e9ea5f295f94d403 Author: Michael Walle Date: Fri Jul 17 15:20:29 2026 +0200 net: dpaa: fix mode setting [ Upstream commit da2c6bcc5e30b1496ac587785dcacf6e849eb6ef ] Before converting to the phylink interface, the init function would have set a non-reserved I/F mode in the maccfg2 register. After converting to phylink, 0 is written as mode, which is a reserved value (although it's the hardware default). Without a valid mode, a SGMII link is never established between the MAC and the PHY and thus .link_up() is never called which could set the correct mode according to the actual speed. Fix it by setting the maximum speed of the phy_interface_t in use in .mac_config() - just like the driver did before the phylink conversion. Fixes: 5d93cfcf7360 ("net: dpaa: Convert to phylink") Suggested-by: Sean Anderson Signed-off-by: Michael Walle Reviewed-by: Sean Anderson Reviewed-by: Sean Anderson Link: https://patch.msgid.link/20260717132401.2653252-1-mwalle@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b5ded444621b6180df9f3d4e07045fc1fc1e8cd9 Author: Eric Dumazet Date: Tue Jul 21 10:12:40 2026 +0000 net: hsr: fix memory leak on slave unregistration by removing synced VLANs [ Upstream commit dcf15eaf5641812f1cfc5e96537380132a7da89d ] When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers. Fixes: 1a8a63a5305e ("net: hsr: Add VLAN CTAG filter support") Reported-by: syzbot+456957213f32970c0762@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a4cb6ca.57639fcc.86d58.000b.GAE@google.com/T/#u Signed-off-by: Eric Dumazet Reviewed-by: Fernando Fernandez Mancera Reviewed-by: Felix Maurer Link: https://patch.msgid.link/20260721101240.995597-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 17bb59682b8e6a5ab57a0a859884d1208d57405c Author: Nikolay Aleksandrov Date: Tue Jul 21 17:09:21 2026 +0300 net: bridge: vlan: fix vlan range dumps starting with pvid [ Upstream commit 43171c97e4714bf601b468401b37732244639c21 ] There is a bug in all range dumps that rely on br_vlan_can_enter_range() when the PVID is a range starting VLAN, all following VLANs that match its flags can enter the range, but when the range is filled in only the PVID VLAN is dumped and the rest of the range is discarded because br_vlan_fill_vids() checks for the PVID flag. Since the PVID VLAN can be only one, we need to break ranges around it, the best way to do that consistently for all is to alter br_vlan_can_enter_range() to take into account the PVID and return false to break the range when it's matched. Before the fix: $ ip l add br0 type bridge vlan_filtering 1 $ ip l add dumdum type dummy $ ip l set dumdum master br0 $ ip l set br0 up $ ip l set dumdum up $ bridge vlan add dev dumdum vid 1 pvid untagged master $ bridge vlan add dev dumdum vid 2 untagged master $ bridge vlan show dev dumdum # use legacy dump to show all vlans port vlan-id dumdum 1 PVID Egress Untagged 2 Egress Untagged $ bridge -d vlan show dev dumdum # use the new dump (RTM_GETVLAN) port vlan-id dumdum 1 PVID Egress Untagged state forwarding mcast_router 1 VLAN 2 is missing, and if there are more matching VLANs afterwards they'd be missing too. After the fix: [ same setup steps ] $ bridge vlan show dev dumdum port vlan-id dumdum 1 PVID Egress Untagged 2 Egress Untagged $ bridge -d vlan show dev dumdum # use the new dump (RTM_GETVLAN) port vlan-id dumdum 1 PVID Egress Untagged state forwarding mcast_router 1 2 Egress Untagged state forwarding mcast_router 1 Fixes: 0ab558795184 ("net: bridge: vlan: add rtm range support") Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260721140922.682265-2-razor@blackwall.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0a347ca1d6a2e3700b13c2df7af498ba5698eeb7 Author: Michael Bommarito Date: Sat Jul 11 11:19:34 2026 -0400 amt: make the head writable before rewriting the L2 header [ Upstream commit 53969d704fa5b7c1751e277fac96bfc22b435eac ] amt_multicast_data_handler(), amt_membership_query_handler() and amt_update_handler() rewrite the ethernet header of the decapsulated skb in place (eth->h_proto, eth->h_dest and, for the query, also eth->h_source) before handing it up the stack. The skb head may be shared, for example when a packet tap has cloned it on the underlay interface, so writing through it corrupts the other reader's copy. Call skb_cow_head() before the rewrite so the head is private. It is placed before the pointers into the head are (re-)derived, so a reallocation caused by the copy is picked up by those derivations. Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface") Signed-off-by: Michael Bommarito Reviewed-by: Simon Horman Reviewed-by: Taehee Yoo Link: https://patch.msgid.link/20260711151934.2955226-3-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ca0e8b661957f777591efe874cd9d9a63619cd99 Author: Michael Bommarito Date: Sat Jul 11 11:19:33 2026 -0400 amt: re-read skb header pointers after every pull [ Upstream commit 3656a79f94c471827a08f2cacce5f94ad5e52c24 ] Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived. Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface") Signed-off-by: Michael Bommarito Reviewed-by: Simon Horman Reviewed-by: Taehee Yoo Link: https://patch.msgid.link/20260711151934.2955226-2-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9ec22c8113d8cf72ed7197bb61037dcad09e50d8 Author: Amir Goldstein Date: Sun Jul 12 14:24:21 2026 +0200 ovl: check access to copy_file_range source with src mounter creds [ Upstream commit a1e0eb8f55cfe09bb31a202a388babc411292656 ] Commit 5dae222a5ff0c ("vfs: allow copy_file_range to copy across devices") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type. The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs. The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time. While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds. This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied. Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds. The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done. Fixes: 5dae222a5ff0c ("vfs: allow copy_file_range to copy across devices") Signed-off-by: Amir Goldstein Link: https://patch.msgid.link/20260712122421.203113-1-amir73il@gmail.com Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 31f5f7c959c3ed2f2bb677a70a3205fe78fab0c1 Author: Christian Brauner Date: Mon Nov 17 10:34:07 2025 +0100 ovl: port ovl_copyfile() to cred guard [ Upstream commit 14d35fda5b1139bacefb47c69f083fe2cfad211b ] Use the scoped ovl cred guard. Link: https://patch.msgid.link/20251117-work-ovl-cred-guard-v4-36-b31603935724@kernel.org Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner Stable-dep-of: a1e0eb8f55cf ("ovl: check access to copy_file_range source with src mounter creds") Signed-off-by: Sasha Levin commit cde234a493f6db1b2b0959c40e1fceeda4b0ed9c Author: Christian Brauner Date: Mon Nov 17 10:33:32 2025 +0100 ovl: add override_creds cleanup guard extension for overlayfs [ Upstream commit 6f5c84162a30514a795eab3495a12c19306d6f6c ] Overlayfs plucks the relevant creds from the superblock. Extend the override_creds cleanup class I added to override_creds_ovl which uses the ovl_override_creds() function as initialization helper. Add with_ovl_creds() based on this new class. Link: https://patch.msgid.link/20251117-work-ovl-cred-guard-v4-1-b31603935724@kernel.org Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner Stable-dep-of: a1e0eb8f55cf ("ovl: check access to copy_file_range source with src mounter creds") Signed-off-by: Sasha Levin commit 35f0b504394e0a24a421fc2c6d31dd77d2d623d3 Author: Christian Brauner Date: Mon Nov 3 00:12:43 2025 +0100 cred: add scoped_with_kernel_creds() [ Upstream commit ae40e6c65791f47c76cc14d0cce2707fe6053f72 ] Add a new cleanup class for override creds. We can make use of this in a bunch of places going forward. Based on this scoped_with_kernel_creds() that can be used to temporarily assume kernel credentials for specific tasks such as firmware loading, or coredump socket connections. At no point will the caller interact with the kernel credentials directly. Link: https://patch.msgid.link/20251103-work-creds-init_cred-v1-4-cb3ec8711a6a@kernel.org Reviewed-by: Jens Axboe Signed-off-by: Christian Brauner Stable-dep-of: a1e0eb8f55cf ("ovl: check access to copy_file_range source with src mounter creds") Signed-off-by: Sasha Levin commit 3139b806923b18988c063c957bd311956b67d241 Author: Julian Braha Date: Sun Jul 12 01:15:14 2026 +0100 drm/panel: s6e3ha8: fix unmet dependency on DRM_DISPLAY_HELPER [ Upstream commit 3667bc164849fee4f1b18b182bdfe643f758ca17 ] Currently, DRM_PANEL_SAMSUNG_S6E3HA8 selects DRM_DISPLAY_DSC_HELPER without ensuring its dependency, DRM_DISPLAY_HELPER, is enabled, causing an unmet dependency. Let's select DRM_DISPLAY_HELPER as other similar options do. This unmet dependency bug was found by kconfirm, a static analysis tool for Kconfig. Fixes: fd3b2c5f40a1 ("drm/panel: s6e3ha8: select CONFIG_DRM_DISPLAY_DSC_HELPER") Signed-off-by: Julian Braha Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260712001514.2318597-1-julianbraha@gmail.com Signed-off-by: Sasha Levin commit 790da254031cc56f55d97996b010b6e049e20425 Author: Yichong Chen Date: Wed Jul 8 16:22:21 2026 +0800 ovl: fix trusted xattr escape prefix matching [ Upstream commit a8e72879cd0d8422c0b47d6d3c1802274fe73b98 ] In the trusted.* xattr namespace, ovl_is_escaped_xattr() compares one byte less than the escaped overlay xattr prefix length. This makes it match "trusted.overlay.overlay" without requiring the trailing dot. As a result, an xattr such as "trusted.overlay.overlayfoo" is incorrectly treated as an escaped overlay xattr. This can be reproduced by setting "trusted.overlay.overlayfoo" on a lower file and listing xattrs through an overlay mount. listxattr() then exposes it as "trusted.overlay.oo", and a following getxattr() on that listed name fails with ENODATA. Compare the full escaped prefix, including the trailing dot, so similarly-prefixed private xattrs are not misclassified. Fixes: dad02fad84cbc ("ovl: Support escaped overlay.* xattrs") Signed-off-by: Yichong Chen Link: https://patch.msgid.link/20260708082221.633602-1-chenyichong@uniontech.com Reviewed-by: Amir Goldstein Signed-off-by: Christian Brauner (Amutable) Signed-off-by: Sasha Levin commit 00ebbf030d8c4a1cb89cbbae15e28332373649db Author: Shelley Yang Date: Mon May 25 16:38:59 2026 +0800 wifi: brcmfmac: fix 802.1X-SHA256 call trace warning [ Upstream commit 7cb34f6c4fe8a68af621d870abe63bfca2275dd6 ] Based on wpa_auth as 1x_256 mode, need to set up "use_fwsup" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4 Fixes: 2526ff21aa77 ("brcmfmac: support 4-way handshake offloading for 802.1X") Signed-off-by: Shelley Yang Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260525083859.581246-1-shelley.yang@infineon.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d5628f39fccc107dca00b98a491d9848898599f7 Author: Lorenzo Bianconi Date: Sun Jun 21 15:25:02 2026 +0200 wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() [ Upstream commit 2fffc472bec490c8357defcee9c075ca74467352 ] mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it. Fixes: ba01944adee9f ("wifi: mt76: mt7996: add EHT beamforming support") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260621-mt76_connac_get_he_phy_cap-fix-v1-4-ed4ccf7a0363@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 95b0cf02731c74e073ef8937f5526bd4442a0326 Author: Sean Wang Date: Tue Jun 16 11:10:16 2026 -0500 wifi: mt76: mt7925: fix crash in reset link replay [ Upstream commit bd8b2ec838184236c3fcbf738a926328836adf12 ] During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif->valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &vif->bss_conf for the legacy link. Fixes: 14061994184d ("wifi: mt76: mt7925: add link handling in mt7925_vif_connect_iter") Signed-off-by: Sean Wang Link: https://patch.msgid.link/20260616161016.19346-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d14238523ca4c6f5fcb54d1920eb2f8525a7711f Author: Lorenzo Bianconi Date: Sun Jun 21 15:25:01 2026 +0200 wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() [ Upstream commit e858cf6bf99880343348ff1e8c942aaff1d9d592 ] mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it. Fixes: 98686cd21624c ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260621-mt76_connac_get_he_phy_cap-fix-v1-3-ed4ccf7a0363@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 313343ab8cab7417973e7bdd43d3c3e93044b447 Author: Lorenzo Bianconi Date: Sun Jun 21 15:25:00 2026 +0200 wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() [ Upstream commit 8d1b6738c1ab48c086b17e7994034aca94258931 ] mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it. Fixes: c948b5da6bbec ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260621-mt76_connac_get_he_phy_cap-fix-v1-2-ed4ccf7a0363@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c058786b09cfab080125bc3ee7928a181dcbd37a Author: Lorenzo Bianconi Date: Sun Jun 21 15:24:59 2026 +0200 wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() [ Upstream commit 2c1fb2335f5e3afb34f91bc07ecb63517c328090 ] mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it. Fixes: d0e274af2f2e4 ("mt76: mt76_connac: create mcu library") Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260621-mt76_connac_get_he_phy_cap-fix-v1-1-ed4ccf7a0363@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 871549814eb4da081f1e93cc0c7ea626a310a966 Author: Ruoyu Wang Date: Sat Jun 20 23:53:32 2026 +0800 wifi: mt76: mt7915: guard HE capability lookups [ Upstream commit 8e9db062654a388d0fa587acbeeae68dd33eba41 ] mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available. Fixes: e6d557a78b60 ("mt76: mt7915: rely on mt76_connac_get_phy utilities") Signed-off-by: Ruoyu Wang Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260620155332.81120-1-ruoyuw560@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f1ee53e08fdd2906e90c6a6d71e1368fcd52bfc3 Author: Guangshuo Li Date: Wed Jul 8 15:55:39 2026 +0800 wifi: mt76: mt7925: guard link STA in decap offload [ Upstream commit 96ea44f2269f30364cffa054ee3a87e595bef0d4 ] mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink->wcid. Fixes: b859ad65309a ("wifi: mt76: mt7925: add link handling in mt7925_sta_set_decap_offload") Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260708075539.726200-1-lgs201920130244@gmail.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit cc4d2f8b984c2b4feae199c496b5b63ed507dd3d Author: Eric Dumazet Date: Wed Jul 15 05:55:41 2026 +0000 ppp: annotate concurrent dev->stats accesses [ Upstream commit ba712ecfd942b68b21a4b0a5daaf72f6616cc66d ] dev->stats fields can be updated concurrently from multiple CPUs without synchronization. Use DEV_STATS_INC() for stats increments and DEV_STATS_READ() when reading dev->stats in ppp_get_stats64() and ppp_get_stats() to avoid data races. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reviewed-by: Qingfang Deng Link: https://patch.msgid.link/20260715055541.1147542-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b52ff80948d1cfdd7b736f829bf80f6a4e3077ea Author: Qingfang Deng Date: Tue Mar 3 17:32:19 2026 +0800 ppp: don't store tx skb in the fastpath [ Upstream commit 70836c8d0fe046400de8cdcf0613b2f1f6bddde3 ] Currently, ppp->xmit_pending is used in ppp_send_frame() to pass a skb to ppp_push(), and holds the skb when a PPP channel cannot immediately transmit it. This state is redundant because the transmit queue (ppp->file.xq) can already handle the backlog. Furthermore, during normal operation, an skb is queued in file.xq only to be immediately dequeued, causing unnecessary overhead. Refactor the transmit path to avoid stashing the skb when possible: - Remove ppp->xmit_pending. - Rename ppp_send_frame() to ppp_prepare_tx_skb(), and don't call ppp_push() in it. It returns 1 if the skb is consumed (dropped/handled) or 0 if it can be passed to ppp_push(). - Update ppp_push() to accept the skb. It returns 1 if the skb is consumed, or 0 if the channel is busy. - Optimize __ppp_xmit_process(): - Fastpath: If the queue is empty, attempt to send the skb directly via ppp_push(). If busy, queue it. - Slowpath: If the queue is not empty, process the backlog in file.xq. Split dequeuing loop into a separate function ppp_xmit_flush() so ppp_channel_push() uses that directly instead of passing a NULL skb to __ppp_xmit_process(). This simplifies the states and reduces locking in the fastpath. Signed-off-by: Qingfang Deng Link: https://patch.msgid.link/20260303093219.234403-1-dqfext@gmail.com Signed-off-by: Paolo Abeni Stable-dep-of: ba712ecfd942 ("ppp: annotate concurrent dev->stats accesses") Signed-off-by: Sasha Levin commit cb9d3e0b55699979b4f4cc333d641edc764056ad Author: Qingfang Deng Date: Thu Jan 29 09:29:02 2026 +0800 ppp: enable TX scatter-gather [ Upstream commit 42fcb213e58a7da33d5d2d7517b4e521025c68c3 ] PPP channels using chan->direct_xmit prepend the PPP header to a skb and call dev_queue_xmit() directly. In this mode the skb does not need to be linear, but the PPP netdevice currently does not advertise scatter-gather features, causing unnecessary linearization and preventing GSO. Enable NETIF_F_SG and NETIF_F_FRAGLIST on PPP devices. In case a linear buffer is required (PPP compression, multilink, and channels without direct_xmit), call skb_linearize() explicitly. Signed-off-by: Qingfang Deng Link: https://patch.msgid.link/20260129012902.941-1-dqfext@gmail.com Signed-off-by: Paolo Abeni Stable-dep-of: ba712ecfd942 ("ppp: annotate concurrent dev->stats accesses") Signed-off-by: Sasha Levin commit e740e90ca8e7f70d9eac1aa31a8b3e0e4d32b2ef Author: Helen Koike Date: Mon Jul 13 17:49:35 2026 -0300 tipc: fix infinite loop in __tipc_nl_compat_dumpit [ Upstream commit 22f8aa35964e8f2ab026578f45befc9605fd1b28 ] cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error. Reported-by: syzbot+85d0bec020d805014a3a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=85d0bec020d805014a3a Fixes: d0796d1ef63d ("tipc: convert legacy nl bearer dump to nl compat") Signed-off-by: Helen Koike Reviewed-by: Tung Nguyen Link: https://patch.msgid.link/20260713204940.647668-1-koike@igalia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d536bf205c71f700f6de2086038c3e1d77724715 Author: Xiang Mei (Microsoft) Date: Mon Jul 13 22:15:51 2026 +0000 nexthop: initialize extack in nh_res_bucket_migrate() [ Upstream commit 6347c5314cee49f364aaf2e40ff15415a57a116e ] nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited("%s\n", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it. Fixes: 7c37c7e00411 ("nexthop: Implement notifiers for resilient nexthop groups") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260713221551.3344650-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 961e9b1e33445f8e42859ecc020c9f60d8b69a8b Author: Xiang Mei (Microsoft) Date: Fri Jul 10 23:07:24 2026 +0000 gtp: check skb_pull_data() return in gtp1u_send_echo_resp() [ Upstream commit cd170f051dba9ac146fabcd1b91726487c0cb9fa ] gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt Fixes: 9af41cc33471 ("gtp: Implement GTP echo response") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Link: https://patch.msgid.link/20260710230724.942574-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 023c5e0d0294a542ebe9e0224273d7efefad4884 Author: Matthieu Baerts (NGI0) Date: Fri Jul 10 20:04:45 2026 +0200 selftests: drv-net: increase timeout [ Upstream commit 3529d75d67411497341cd804a045185d6035dff2 ] The default timeout is 45 seconds, that's too low for the xdp.py test. Indeed, this test can take up to 3 minutes with some debug kernel config on NIPA. Set a timeout to 6 minutes, just to be on the safe side. Note that the Fixes tag here points to the introduction of the xdp.py test because I don't know when this test started to take more than 45 seconds. That's OK because a timeout of 6 minutes is not exaggerated. Fixes: 1cbcb1b28b26 ("selftests: drv-net: Test XDP_PASS/DROP support") Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-5-a2915c294ef5@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fa065685c8a9138aeadf87a013abdd27eed0df6d Author: Matthieu Baerts (NGI0) Date: Fri Jul 10 20:04:44 2026 +0200 selftests: ovpn: increase timeout [ Upstream commit 61ac7049aaa86ae044e8a5b94d852218163d5bf8 ] The default timeout is 45 seconds, that's too low for a few ovpn tests. Indeed, these tests can take up to 50 seconds with some debug kernel config on NIPA. Set a timeout to 90 seconds, just to be on the safe side. Note that the Fixes tag here points to the introduction of the ovpn tests because I don't know when they started to take more than 45 seconds. That's OK because a timeout of 1.5 minutes is not exaggerated. Fixes: 959bc330a439 ("testing/selftests: add test tool and scripts for ovpn module") Signed-off-by: Matthieu Baerts (NGI0) Acked-by: Antonio Quartulli Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-4-a2915c294ef5@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e2b3d426c7ee59f068afc0f13b6105fc7978c73a Author: Matthieu Baerts (NGI0) Date: Fri Jul 10 20:04:43 2026 +0200 selftests: ovpn: add IPV6 and VETH configs [ Upstream commit 90c792681a3732caaf7bf5bc435877736baf591a ] They are required to run the selftests: - Tests are executed in v4 and v6. - Virtual Ethernet are used between the different netns. This has not been seen on NIPA before, because the 'ovpn' tests are executed with the 'tcp_ao' ones, merging their config files. These two kernel config are present in tools/testing/selftests/net/tcp_ao/config. This issue is visible when only the ovpn config is used on top of the default one. This is the recommended way to execute selftest targets. Fixes: 959bc330a439 ("testing/selftests: add test tool and scripts for ovpn module") Signed-off-by: Matthieu Baerts (NGI0) Acked-by: Antonio Quartulli Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-3-a2915c294ef5@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 69eab5c4d9aa6c5b6ebff9679c2e75728ccb0700 Author: Matthieu Baerts (NGI0) Date: Fri Jul 10 20:04:42 2026 +0200 selftests: openvswitch: add config file [ Upstream commit 441a820ccef9af80a9ac5a4c85b9c396e595967c ] The kselftests doc mentions that a config file should be present "if a test needs specific kernel config options enabled". This selftest requires some kernel config, but no config file was provided. We could say that a sub-target could use the parent's config file, but the kselftests doc doesn't mention anything about that. Plus the net/openvswitch target is the only net target without a config file. Here is a new config file, which is a trimmed version of the net one, with hopefully the minimal required kconfig on top of 'make defconfig'. The Fixes tag points to the introduction of the net/openvswitch target, just to help validating this target on stable kernels. Fixes: 25f16c873fb1 ("selftests: add openvswitch selftest suite") Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Eelco Chaudron Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-2-a2915c294ef5@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 340c389fd3d5dd32f22f1413ba49d60450a60b53 Author: Matthieu Baerts (NGI0) Date: Fri Jul 10 20:04:41 2026 +0200 selftests: af_unix: add USER_NS config [ Upstream commit f8b1abed736111f914b2c567d9a3db1f71e788e8 ] This is required to use unshare(CLONE_NEWUSER). This has not been seen on NIPA before, because the 'af_unix' tests are executed with the 'net' ones, merging their config files. USER_NS is present in tools/testing/selftests/net/config. This issue is visible when only the af_unix config is used on top of the default one. This is the recommended way to execute selftest targets. Fixes: ac011361bd4f ("af_unix: Add test for sock_diag and UDIAG_SHOW_UID.") Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Kuniyuki Iwashima Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-1-a2915c294ef5@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fbd91910c5025dd99553fed1313fefd0d2e1c465 Author: Rishikesh Jethwani Date: Thu Jul 9 16:44:36 2026 -0600 tls: device: push pending open record on splice EOF [ Upstream commit eaa39f9f8ac8c1d032cd26b9cd572804e9d7683f ] On kTLS device-offload sockets, sendfile() with count > EOF can reach ->splice_eof() with a fully assembled but still-open TLS record left pending. tls_device_splice_eof() only flushes partially sent records, so an abrupt close() can drop the final record and the peer receives a short file. Fix tls_device_splice_eof() to also push pending open records. This matches the software path, where splice EOF already flushes pending open records. Fixes: d4c1e80b0d1b ("tls/device: Use splice_eof() to flush") Link: https://lore.kernel.org/netdev/CAMPsyauZ+jzG9AysO0FWv6ZY0kvCUpjX_U7o=oOjCuOQ87BCgg@mail.gmail.com/ Reported-by: Nils Juenemann Signed-off-by: Rishikesh Jethwani Tested-by: Nils Juenemann Link: https://patch.msgid.link/20260709224436.1608993-2-rjethwani@purestorage.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a8bd8c109da5a87f0c5db0c23cf550d039fde77c Author: Myeonghun Pak Date: Wed Jul 15 16:25:17 2026 +0900 net: mctp i3c: clean up notifier and buses if driver register fails [ Upstream commit 03d1057305ef17ac3f5936ac1580bc9a1a826e14 ] mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: c8755b29b58e ("mctp i3c: MCTP I3C driver") Co-developed-by: Ijae Kim Signed-off-by: Ijae Kim Signed-off-by: Myeonghun Pak Acked-by: Jeremy Kerr Link: https://patch.msgid.link/20260715072517.13216-1-mhun512@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1a10fe1aa9c01f41b389a31906a77d538637c9d9 Author: Cen Zhang (Microsoft) Date: Thu Jul 9 21:07:18 2026 -0400 sctp: validate stream count in sctp_process_strreset_inreq() [ Upstream commit 18ae07691d43183d270de8be9dc8e027906015d9 ] When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer. Fixes: 7f9d68ac944e ("sctp: implement sender-side procedures for SSN Reset Request Parameter") Reported-by: AutonomousCodeSecurity@microsoft.com Closes: https://lore.kernel.org/all/20260707203215.2752-1-blbllhy@gmail.com/ Suggested-by: Xin Long Signed-off-by: Cen Zhang (Microsoft) Acked-by: Xin Long Link: https://patch.msgid.link/20260710010718.20318-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c984a4184f81046622672f2a18d58df3b07a4e97 Author: Nikhil P. Rao Date: Tue Jul 14 21:27:13 2026 +0000 pds_core: check for workqueue allocation failure [ Upstream commit 3a660ca49e2c3807bffe0519db3cff677a5906e0 ] pdsc_init_pf() does not check whether create_singlethread_workqueue() succeeded. Fail probe on failure. The workqueue is set up before the timer and mutexes, so its failure path must unwind only the earlier setup. Fixes: c2dbb0904310 ("pds_core: health timer and workqueue") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2 Signed-off-by: Nikhil P. Rao Reviewed-by: Brett Creeley Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/20260714212713.1788438-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cf0ed2ba202f5c3b300ec1bf7ff0b5d555f7d518 Author: Nikhil P. Rao Date: Tue Jul 14 21:07:45 2026 +0000 pds_core: fix auxiliary device add/del races [ Upstream commit bfa33cd513c7ceb93c5a4c30e5662acd73c0a916 ] Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths. Fixes: b699bdc720c0 ("pds_core: specify auxiliary_device to be created") Reported-by: sashiko-bot@kernel.org # Running on a local machine Signed-off-by: Nikhil P. Rao Reviewed-by: Brett Creeley Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/20260714210745.1785625-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0e87fe52b560fd8a747fc60a4a7e5c27d5fea2b4 Author: Nikhil P. Rao Date: Tue Jul 14 20:41:45 2026 +0000 pds_core: order completion reads after the ownership check [ Upstream commit dd6b1cc748cd28147c113f9daa76393916ad9494 ] pdsc_process_adminq() and pdsc_process_notifyq() decide a completion is valid from its ownership field - the color bit for the adminq, the event id for the notifyq - then read the rest of the descriptor, with no barrier in between. On a weakly ordered architecture the CPU may read the payload first. Add dma_rmb() between the ownership read and the payload reads. Fixes: 7e82a8745b95 ("pds_core: Prevent race issues involving the adminq") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2 Signed-off-by: Nikhil P. Rao Reviewed-by: Eric Joyner Link: https://patch.msgid.link/20260714204145.1782390-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3a831f40e88d35cc099f28e4b2dc6f0bc502500a Author: Nikhil P. Rao Date: Tue Jul 14 20:14:56 2026 +0000 pds_core: yield the CPU while waiting for the adminq to drain [ Upstream commit a11f0b8a204296fe7db9eaec53441012222cb004 ] pdsc_adminq_wait_and_dec_once_unused() busy-waits for adminq_refcnt to drop to one: while (!refcount_dec_if_one(&pdsc->adminq_refcnt)) cpu_relax(); The refcount is held by pdsc_adminq_post() for the duration of an in-flight command, which can wait up to devcmd_timeout seconds (PDS_CORE_DEVCMD_TIMEOUT is 5) for the hardware to complete. cpu_relax() is not a reschedule point, so on a non-preemptible kernel this loop can spin on the CPU for several seconds, starving other tasks on that core. Add cond_resched() to the loop so the waiter yields to other runnable tasks while it polls, keeping cpu_relax() as the busy-wait hint between checks. Fixes: 7e82a8745b95 ("pds_core: Prevent race issues involving the adminq") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2 Signed-off-by: Nikhil P. Rao Reviewed-by: Eric Joyner Reviewed-by: Pavan Chebbi Link: https://patch.msgid.link/20260714201456.1776153-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9e0f80fac50ab95dd75537c8ecaf5051d01f19b5 Author: Nikhil P. Rao Date: Tue Jul 14 18:02:23 2026 +0000 pds_core: fix use-after-free on workqueue during remove [ Upstream commit 0ad134881508c36b65c1a8864f8bec53adbd3327 ] In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed. Fixes: 01ba61b55b20 ("pds_core: Add adminq processing and commands") Reported-by: sashiko-bot Closes: https://patchwork.kernel.org/comment/27002369/ Signed-off-by: Nikhil P. Rao Link: https://patch.msgid.link/20260714180223.1642792-3-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 19ef775c91c6bf4bd2b60f6616f4e28b621cdd6a Author: Nikhil P. Rao Date: Tue Jul 14 18:02:22 2026 +0000 pds_core: fix deadlock between reset thread and remove [ Upstream commit ab0eec0ff0a421737a37f510ceab5c6ea59cd05a ] pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence. Fixes: 81665adf25d2 ("pds_core: Fix pdsc_check_pci_health function to use work thread") Reported-by: sashiko-bot Closes: https://patchwork.kernel.org/comment/27002369/ Signed-off-by: Nikhil P. Rao Reviewed-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260714180223.1642792-2-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 11092d79eb2b7c0068382f72fc2416d1786bb2e0 Author: HanQuan Date: Mon Jul 13 03:20:21 2026 +0000 sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid [ Upstream commit ff04b26794a16a8a879eb4fd2c02c2d6b03850e9 ] sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity. Fixes: 1f485649f529 ("[SCTP]: Implement SCTP-AUTH internals") Signed-off-by: HanQuan Acked-by: Xin Long Link: https://patch.msgid.link/20260713032021.3491702-1-zhoujian.zja@antgroup.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2d34421bfa261f7e83bea2f2f75fa75e0c3037d1 Author: Chenguang Zhao Date: Mon Jul 13 17:19:11 2026 +0800 net: txgbe: fix FDIR filter leak on remove [ Upstream commit ecaa37826340520664a4e5522f803ff48fc3f564 ] Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well. Fixes: 4bdb441105dc ("net: txgbe: support Flow Director perfect filters") Signed-off-by: Chenguang Zhao Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260713091911.1614795-1-chenguang.zhao@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 245bfe72a5ad489f4ea4bb87425b661b0f306564 Author: Kuniyuki Iwashima Date: Thu Jul 9 18:31:40 2026 +0000 net: Call net_enable_timestamp() before failure in sk_clone(). [ Upstream commit d50557779257a00162411e3048d82971ff1f644c ] When sk_clone() fails, sk_destruct() is called for the new socket. If the parent socket has SK_FLAGS_TIMESTAMP in sk->sk_flags, net_disable_timestamp() is called for the child socket even though net_enable_timestamp() is not called for it. Let's call net_enable_timestamp() before any failure path in sk_clone(). Fixes: 704da560c0a0 ("tcp: update the netstamp_needed counter when cloning sockets") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260709032007.9E4D61F000E9@smtp.kernel.org/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Willem de Bruijn Reviewed-by: Jason Xing Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260709183315.965751-3-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4122792923312ee6cfda32f26f30597b85113181 Author: Kuniyuki Iwashima Date: Thu Jul 9 18:31:39 2026 +0000 soreuseport: Clear sk_reuseport_cb before failure in sk_clone(). [ Upstream commit 98da8ce87dd561f08fbe44f75865edc5d9b2ba5f ] When sk_clone() fails, sk_destruct() is called for the new socket. If the parent socket has sk->sk_reuseport_cb, the child will call reuseport_detach_sock() for the reuseport group. Let's clear sk->sk_reuseport_cb before any failure path in sk_clone(). Note that this was not a problem before the cited commit because reuseport_detach_sock() did nothing if the socket was not found in the reuseport array. Fixes: 5dc4c4b7d4e8 ("bpf: Introduce BPF_MAP_TYPE_REUSEPORT_SOCKARRAY") Reported-by: Sashiko Closes: https://lore.kernel.org/all/20260709032007.9E4D61F000E9@smtp.kernel.org/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Willem de Bruijn Reviewed-by: Jason Xing Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260709183315.965751-2-kuniyu@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f97d199287689d9af903488a9f9f989e28a63fa8 Author: Prashanth Kumar KR Date: Thu Jul 9 15:20:06 2026 +0530 amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN [ Upstream commit 4bf22afe53a1de4b44b04cf677fd5199089cbdff ] MAC_AUTO_SW (VR_MII_DIG_CTRL1 bit 9) enables automatic XPCS speed mode switching after CL37 auto-negotiation and is only meaningful in SGMII MAC mode. The original code unconditionally set this bit on every call to xgbe_an37_set(), including when called from xgbe_an37_disable() with enable=false. This left MAC_AUTO_SW=1 after AN was disabled, causing the XPCS to autonomously switch speed from stale AN state during subsequent mode changes, breaking SGMII speed negotiation on 1G copper SFP modules. Patrick: This was breaking negotiation for all 1G SFP modules, not just copper modules. Fixes: 42fd432fe6d3 ("amd-xgbe: align CL37 AN sequence as per databook") Reported-by: Patrick Oppenlander Link: https://lore.kernel.org/netdev/CAEg67GmFS0Q4oSZkz8zWdOzckSth9_vBPiOy6a7-d697C2w2Xg@mail.gmail.com Signed-off-by: Prashanth Kumar KR Tested-by: Patrick Oppenlander Link: https://patch.msgid.link/20260709095006.3683940-1-prashanthkumar.k.r@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e695cb9becbbb6fc6e6bf334c828f3fee37e69a6 Author: Steven Price Date: Fri Jul 3 14:48:35 2026 +0100 arm64: Correct value returned by ESR_ELx_FSC_ADDRSZ_nL() [ Upstream commit b877075d0baa22c225842c2f19e3ea0a9cbcbe39 ] Address size fault, level -1 is encoded as 0b101001 or 0x29 according to the Arm ARM. Correct the value to match the spec. This also matches the offset of "level -1 address size fault" in the fault_info array in fault.c. Fixes: fb8a3eba9c81 ("KVM: arm64: Only read HPFAR_EL2 when value is architecturally valid") Signed-off-by: Steven Price Reviewed-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f5b8b8ccf9a4a4386eba68155b17c45e441dff9c Author: Nikhil P. Rao Date: Wed Jul 8 16:36:49 2026 +0000 pds_core: reject component parameter in legacy firmware update [ Upstream commit 7be2552e601c247a328a5aba6fc06ac844b94a16 ] The legacy firmware update path does not support per-component updates. If a user specifies a component parameter with devlink flash, reject the request with -EOPNOTSUPP rather than silently ignoring the component parameter and flashing the entire firmware image. Fixes: 49ce92fbee0b ("pds_core: add FW update feature to devlink") Signed-off-by: Nikhil P. Rao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260708163649.128620-1-nikhil.rao@amd.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b5fcd1da05622d63ad33808525f334a2797c356a Author: Andrew Pope Date: Fri Jul 17 11:17:51 2026 +1000 wifi: mac80211: recalculate TIM when a station enters power save [ Upstream commit a007a384c9eb17610f53a53e2f59944c31f1565a ] When an AP buffers frames for a station on its per-station TXQs and the station subsequently enters power save, sta_ps_start() records the buffered TIDs in txq_buffered_tids but does not update the TIM. The station's TIM bit is only ever set when a further frame is buffered while the station is already asleep (ieee80211_tx_h_unicast_ps_buf() -> sta_info_recalc_tim()). If no further downlink frame arrives for that station the beacon TIM never advertises the buffered traffic. A station relying on the TIM then remains in doze indefinitely on top of a non-empty queue. Its TXQs were removed from the scheduler's active list at PS entry, nothing pages it, and the flow deadlocks until an unrelated event wakes the station. Recalculate the TIM at the end of sta_ps_start(), so traffic already buffered at PS entry is advertised immediately. sta_info_recalc_tim() already consults txq_buffered_tids, which is updated above, and is safe in this context (it is already called from equivalent paths such as the tx handlers and ieee80211_handle_filtered_frame()). Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation") Signed-off-by: Andrew Pope Link: https://patch.msgid.link/20260717011751.79524-1-andrew.pope@morsemicro.com [add wifi: subject prefix] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d06fea9b85f038690f55e72fe0c45e113715a85a Author: Li RongQing Date: Tue Jul 21 17:34:10 2026 +0800 iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() [ Upstream commit 754f8efe45f87e3a9c6871b645b2f9d46d1b407b ] dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry. Fixes: 55ee5e67a59a ("iommu/vt-d: Add common code for dmar latency performance monitors") Signed-off-by: Li RongQing Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e5ebe8544df1a1c3611739a8622156094fe470df Author: Pengpeng Hou Date: Mon Jul 20 19:46:13 2026 +0800 iommu/amd: Bound the early ACPI HID map [ Upstream commit fb80117fddb5b477218dc99bb53911b72c3847f8 ] The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry. Fixes: ca3bf5d47cec ("iommu/amd: Introduces ivrs_acpihid kernel parameter") Signed-off-by: Pengpeng Hou Reviewed-by: Ankit Soni Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit d21464d93f8ba464dc3d7b4b31c6e0adcd9f659c Author: HE WEI (ギカク) Date: Wed Jul 15 22:57:11 2026 +0900 wifi: mwifiex: bound uAP association event IEs to the event buffer [ Upstream commit f0858bfc7d3cab411a447b88e3ef970e575032c9 ] mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: sinfo->assoc_req_ies = &event->data[len]; len = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; sinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 ("wifi: mwifiex: Fix OOB and integer underflow when rx packets"). Fixes: e568634ae7ac ("mwifiex: add AP event handling framework") Signed-off-by: HE WEI (ギカク) Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260715135711.34688-1-skyexpoc@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a0980682d84d2466d916628f3d6694955b64e80d Author: Enrico Zanda Date: Wed Jul 8 16:22:42 2026 +0100 vhost-net: fix TX stall when vhost owns virtio-net header [ Upstream commit 3c0d10f233f19153f81fef685b5c6716776a5af3 ] When vhost owns the virtio-net header, i.e. when VHOST_NET_F_VIRTIO_NET_HDR is negotiated, sock_hlen is 0, meaning that no header will be forwarded to the TAP device. In the current vhost_net_build_xdp() implementation, when sock_hlen == 0, the gso pointer can point at the start of the Ethernet frame instead of a virtio-net header. This results in a wrong interpretation of the destination MAC address bytes as struct virtio_net_hdr fields. This can, for some MAC addresses, trigger -EINVAL and return early before the TX descriptor is completed, which can stall vhost-net TX. Before 97b2409f28e0, the gso pointer was set to the zeroed padding area, using it as a synthetic virtio-net header. Restore that behavior. Fixes: 97b2409f28e0 ("vhost-net: reduce one userspace copy when building XDP buff") Signed-off-by: Enrico Zanda Acked-by: Michael S. Tsirkin Link: https://patch.msgid.link/20260708152242.2268848-1-enrico.zanda@arm.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 59cbe6cfa0fa23c192351cc284e30707309f6741 Author: Ruoyu Wang Date: Wed Jul 8 22:34:15 2026 +0800 wan: wanxl: Only reset hardware after BAR mapping [ Upstream commit 91957b89da995607cb654b1f9a3c126ddbaee10f ] wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ruoyu Wang Link: https://patch.msgid.link/20260708143415.3169358-1-ruoyuw560@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3b1d4fc3b73ea6faf008a0996ce6190c6e43efc3 Author: Ruoyu Wang Date: Wed Jul 8 22:34:08 2026 +0800 nfp: Check resource mutex allocation [ Upstream commit a61b4db34a753bdf5c9e77a7f3d3dddd41dcfacc ] nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: f01a2161577d ("nfp: add support for resources") Signed-off-by: Ruoyu Wang Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260708143408.3168425-1-ruoyuw560@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0f7eaeb950adb77f71beb546e5ab30f90b41fe6f Author: Xiang Mei Date: Sat Jul 11 14:03:02 2026 -0700 wifi: mac80211: tear down new links on vif update error path [ Upstream commit 952c02b33f56207a160421bcd61e7ac53c9c59ae ] When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f ("wifi: mac80211: avoid weird state in error path") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception Fixes: 170cd6a66d9a ("wifi: mac80211: add netdev per-link debugfs data and driver hook") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260711210302.2098404-1-xmei5@asu.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d053eb7e09e10cbdca3fca8b35c1017d438091b2 Author: Guanghui Feng Date: Thu Jul 16 22:16:22 2026 +0800 iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() [ Upstream commit 1e75a8255f11c81fb07e81e5029cfd75804350a0 ] need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the "block until all previously queued commands have completed" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued. Signed-off-by: Guanghui Feng Fixes: 815b33fdc279 ("x86/amd-iommu: Cleanup completion-wait handling") Reviewed-by: Vasant Hegde Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 76fc5604308a109bf5838c2a0a0eb3ac6819f1ea Author: Wayen Yan Date: Wed Jul 8 19:35:29 2026 +0800 net: airoha: Fix DMA direction for NPU mailbox buffer [ Upstream commit 6f884eb87a79e0c482baef2ad96c96b81d024235 ] airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern. Fixes: c52918744ee1e49cea86622a2633b9782446428f ("net: airoha: npu: Move memory allocation in airoha_npu_send_msg() caller") Signed-off-by: Wayen Yan Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/178351055214.98729.11403147818632027428@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f112df0744e2d77baa68eeebb860021bbaaa022a Author: Guangshuo Li Date: Wed Jul 8 19:17:37 2026 +0800 dpaa2-eth: put MAC endpoint device on disconnect [ Upstream commit b4b201cc93ff70150853aba03e14d314d1980ca0 ] fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object. Fixes: 719479230893 ("dpaa2-eth: add MAC/PHY support through phylink") Signed-off-by: Guangshuo Li Reviewed-by: Ioana Ciornei Reviewed-by: Ioana Ciornei Link: https://patch.msgid.link/20260708111738.750391-1-lgs201920130244@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 46e3bed4b071095ecc9384a7b349e1908728531f Author: Wayen Yan Date: Wed Jul 8 19:16:16 2026 +0800 net: airoha: Fix potential use-after-free in airoha_ppe_deinit() [ Upstream commit 2484568a335cd7bda951c75b3a7d95ea36161ae7 ] airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 ("net: airoha: Fix schedule while atomic in airoha_ppe_deinit()") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released. Fixes: 6abcf751bc084804a9e5b3051442e8a2ce67f48a ("net: airoha: Fix schedule while atomic in airoha_ppe_deinit()") Signed-off-by: Wayen Yan Acked-by: Lorenzo Bianconi Link: https://patch.msgid.link/178351022574.97989.6880403520276841703@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 26ac2d3602347f0377fbcd5214bc28a9d735ae68 Author: Guangshuo Li Date: Wed Jul 8 19:10:25 2026 +0800 dpaa2-switch: put MAC endpoint device on disconnect [ Upstream commit 4c1eabbef7a1707635652e956e39db1269c3af2b ] fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object. Fixes: 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support") Signed-off-by: Guangshuo Li Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260708111025.749311-1-lgs201920130244@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c9165e199f56997f2f2deb5d3ec2dfab98dfa288 Author: Xuanqiang Luo Date: Wed Jul 8 17:35:34 2026 +0800 rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() [ Upstream commit 745fb794c3e933c023af9dbb5876a5e16ad2dc71 ] rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does. Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE") Signed-off-by: Xuanqiang Luo Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260708093534.53486-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b78547914bee5db4563b552abf736e5b0f4ab20a Author: Zhixing Chen Date: Wed Jul 8 12:22:44 2026 +0800 gtp: parse extension headers before reading inner protocol [ Upstream commit 96e37e2f618e931aa97af95e707dcdfb1ec41264 ] GTPv1-U packets may carry a chain of extension headers before the inner IP packet. The receive path already parses and skips these extension headers, but it currently reads the inner protocol before doing so. As a result, the first extension header byte is interpreted as the inner IP version. Packets with extension headers are then dropped before PDP lookup. Parse the extension header chain before calling gtp_inner_proto(), so the inner protocol is read from the actual inner IP header. Fixes: c75fc0b9e5be ("gtp: identify tunnel via GTP device + GTP version + TEID + family") Signed-off-by: Zhixing Chen Link: https://patch.msgid.link/20260708042244.120898-1-running910@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9591042533140dfe6608d9344806d567dcd39d02 Author: Aldo Ariel Panzardo Date: Tue Jul 7 19:43:14 2026 -0700 rds: drop incoming messages that cross network namespace boundaries [ Upstream commit 5521ae71e32a8069ed4ca6e792179dc57bc43ab2 ] rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison. Fixes: c809195f5523 ("rds: clean up loopback rds_connections on netns deletion") Signed-off-by: Aldo Ariel Panzardo Reviewed-by: Allison Henderson Tested-by: Allison Henderson Signed-off-by: Allison Henderson Link: https://patch.msgid.link/20260708024314.601139-1-achender@kernel.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 992dce02bdabbd9883255ea9b36494e34a7821d7 Author: Zhaolong Zhang Date: Tue Jul 7 09:06:22 2026 +0800 bonding: fix devconf_all NULL dereference when IPv6 is disabled [ Upstream commit 1c975de3343cdef506f2eecc833cc1f14b0401c4 ] When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller. Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets") Signed-off-by: Qianheng Peng Signed-off-by: Zhaolong Zhang Reviewed-by: Hangbin Liu Link: https://patch.msgid.link/20260707010622.487333-1-zhangzl2013@126.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1bc55c29cd85818e9052f17deb287d5a11fb817f Author: David Lee Date: Tue Jul 7 10:44:37 2026 +0000 net/packet: avoid fanout hook re-registration after unregister [ Upstream commit 50aff80475abd3533eef4320477037e6fcc6b56e ] packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket. Fixes: dc99f600698d ("packet: Add fanout support.") Link: https://lore.kernel.org/netdev/20260701113947.23180-1-david.lee@trailofbits.com/ Signed-off-by: David Lee Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20260707104440.833129-1-david.lee@trailofbits.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9f4f75df77c8949aae48a6ba73000a81362d0c65 Author: Danielle Ratson Date: Tue Jul 7 11:03:04 2026 +0300 netlink: specs: rt-link: convert bridge port flag attributes to u8 [ Upstream commit f6e3b21608e974c4aaa4cfd73a239dacf1d8a9a3 ] A number of IFLA_BRPORT_* attributes are documented in the rt-link spec as having the "flag" type, i.e. a payload-less NLA_FLAG attribute whose meaning is presence-only. This does not match the kernel, which emits these attributes with nla_put_u8() and validates them as NLA_U8 in br_port_policy[]. The values are not mere presence flags but carry a u8 payload (0/1). Convert these bridge port attributes from "flag" to "u8" so the spec reflects the actual wire format. Fixes: 077b6022d24b ("doc/netlink/specs: Add sub-message type to rt_link family") Reviewed-by: Petr Machata Acked-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Signed-off-by: Danielle Ratson Link: https://patch.msgid.link/a57cdfcfc4a6dcb92106c25b4dde5059fde2bd44.1783236731.git.danieller@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4264dbc84ca0ac9f78583b7775d66f11b2f4e722 Author: Michael Walle Date: Mon Jul 6 14:06:27 2026 +0200 net: phy: marvell: fix return code [ Upstream commit 7d8ca62d6a9ef593780161586b4efc811ac094fe ] Return the correct error code, not the value written to the register. Fixes: a219912e0fec ("net: phy: marvell: implement config_inband() method") Signed-off-by: Michael Walle Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260706120637.1947685-1-mwalle@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8881daaafadbe7fb2b7341d16a3949114409c90c Author: Pengpeng Hou Date: Mon Jul 20 19:47:17 2026 +0800 Bluetooth: btusb: validate Realtek vendor event length [ Upstream commit df541cd485ff80a5ddc579d99687bc7506df9851 ] btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation. Fixes: 044014ce85a1 ("Bluetooth: btrtl: Add Realtek devcoredump support") Signed-off-by: Pengpeng Hou Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 9d208de7a8f64d5efe1e6d6db0c7243da0584bdf Author: Daniel Golle Date: Sat Jul 18 02:05:59 2026 +0100 regulator: mt6358: use regmap helper to read fixed LDO calibration [ Upstream commit 1d26f125501f3fbe6c259ab75bf6516299a0bf0e ] The "fixed" LDOs with output voltage calibration use mt6358_get_buck_voltage_sel as their get_voltage_sel op, but the MT6358_REG_FIXED and MT6366_REG_FIXED entries do not populate da_vsel_reg/da_vsel_mask. The op therefore reads register 0x0 with a zero mask and shifts the result by ffs(0) - 1 = -1, which is undefined behaviour and gets flagged by UBSAN on every boot on MT6366 boards: UBSAN: shift-out-of-bounds in drivers/regulator/mt6358-regulator.c:384:38 shift exponent -1 is negative Call trace: mt6358_get_buck_voltage_sel+0xc8/0x120 regulator_get_voltage_rdev+0x70/0x170 set_machine_constraints+0x504/0xc38 regulator_register+0x324/0xc68 Besides the undefined shift, the returned selector is always 0, so the actual calibration offset programmed in _ANA_CON0 is never reported. The descriptor already carries the correct vsel_reg/vsel_mask (the ANA_CON0 calibration field), matching the regulator_set_voltage_sel_regmap op already in use. Read the selector back through regulator_get_voltage_sel_regmap instead. Fixes: cf08fa74c716 ("regulator: mt6358: Add output voltage fine tuning to fixed regulators") Signed-off-by: Daniel Golle Reviewed-by: Chen-Yu Tsai Tested-by: Chen-Yu Tsai Link: https://patch.msgid.link/dcd98d81dede338c9bbb9700a9613c848b702e49.1784336005.git.daniel@makrotopia.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 538d862cc0dbd5c732fe26d5aad98eae039e6676 Author: Pengpeng Hou Date: Mon Jul 20 19:58:26 2026 +0800 hwmon: occ: validate poll response sensor blocks [ Upstream commit 70e76e700fc6c46afb4e17aec099a1ea089b4a22 ] The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active. Fixes: aa195fe49b03 ("hwmon (occ): Parse OCC poll response") Signed-off-by: Pengpeng Hou Link: https://lore.kernel.org/r/20260720115826.14813-1-pengpeng@iscas.ac.cn Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 2f0f661998941a89ad41154b5320aed4d08d1b43 Author: Marco Baffo Date: Mon Jun 8 16:06:42 2026 +0200 ovpn: use monotonic clock for peer keepalive timeouts [ Upstream commit f7e6287ccd3abeed9e638b581dc3fdf742106ba3 ] Replace ktime_get_real_seconds() with the monotonic ktime_get_boottime_seconds() to ensure the keepalive mechanism is robust against system clock modifications. Right now, the driver uses ktime_get_real_seconds() to track peer timeouts, relying on the system wall-clock. An administrative time adjustment or an NTP sync that steps the clock forward can cause `now' to instantly exceed `last_recv + timeout'. When this occurs, the driver artificially expires healthy peers. Depending on the OpenVPN user-space configuration, this triggers a premature tunnel restart (if --keepalive or --ping-restart is used) or a complete disconnection of the client (if --ping-exit is used). Fixes: 3ecfd9349f40 ("ovpn: implement keepalive mechanism") Signed-off-by: Marco Baffo Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 5b96227c0e8b212b74838424c929fc889aedb555 Author: Marco Baffo Date: Mon Jun 8 16:04:46 2026 +0200 ovpn: fix use after free in unlock_ovpn() [ Upstream commit e1ad6fe5db719874efa45b2caf9934552e09fc43 ] unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body. Fixes: 80747caef33d ("ovpn: introduce the ovpn_peer object") Signed-off-by: Marco Baffo Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 47cd68e050a63cfbaeb1ea965f8caa14c9685fbb Author: longlong yan Date: Wed Jun 3 15:27:41 2026 +0800 selftests/net: ovpn: fix getaddrinfo memory leak in ovpn_parse_remote() [ Upstream commit 0bd9cfebc1c91e1066e56d6261b99691b9df6008 ] The ovpn_parse_remote() function has two memory management issues: 1. When both 'host' and 'vpnip' are non-NULL, the first getaddrinfo() allocation is leaked because 'result' is overwritten by the second getaddrinfo() call without freeing the first allocation. 2. When both 'host' and 'vpnip' are NULL, 'result' is an uninitialized stack variable passed to freeaddrinfo(), which is undefined behavior. Fix by initializing 'result' to NULL and calling freeaddrinfo() after the first getaddrinfo() result is consumed. Fixes: 959bc330a439 ("testing/selftests: add test tool and scripts for ovpn module") Signed-off-by: longlong yan Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit c5bf6b39be235ef578af4d39872f0c68cda3b937 Author: Qing Ming Date: Sat May 23 16:15:43 2026 +0800 ovpn: avoid putting unrelated P2P peer on socket release [ Upstream commit b52c5103f64ee825996ca1ab8df7283cde8c5f86 ] ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer. Fixes: f6226ae7a0cd ("ovpn: introduce the ovpn_socket object") Signed-off-by: Qing Ming Reviewed-by: Simon Horman Signed-off-by: Antonio Quartulli Signed-off-by: Sasha Levin commit 2fdd6d196c656b376cc251e1e9ff110b3ed522e1 Author: Yichong Chen Date: Thu Jul 16 13:25:23 2026 +0800 smb: client: validate DFS referral PathConsumed [ Upstream commit f6f5ee2aa33b350c671721b965251c42cebb962e ] parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral. Fixes: 4ecce920e13a ("CIFS: move DFS response parsing out of SMB1 code") Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Yichong Chen Signed-off-by: Steve French Signed-off-by: Sasha Levin commit d6959dd79088a08852258746bf66d8a6185aca01 Author: Eugene Shalygin Date: Sun Jul 12 15:05:05 2026 +0200 hwmon: (asus-ec-sensors) add missed handle for ENOMEM [ Upstream commit 9813c1f49efeadbcb17e4a41972350ac783f9cac ] Add missing return value check in the setup function. Fixes: d0ddfd241e57 ("hwmon: (asus-ec-sensors) add driver for ASUS EC") Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20260712130602.1256700-2-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit dd6f730be95b57f3e4d12d55d6922460dfc21964 Author: Eugene Shalygin Date: Sun Jul 12 13:05:03 2026 +0200 hwmon: (asus-ec-sensors) fix EC read intervals [ Upstream commit 60710b2af13b81da71b429d3f8b19dd70310729d ] Take INITIAL_JIFFIES into account when setting up next update time. Fixes: d0ddfd241e57 ("hwmon: (asus-ec-sensors) add driver for ASUS EC") Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20260712110650.1240071-2-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 22e449c1dd543ee5ebdc6f790bf8130b7d76a9cf Author: Eugene Shalygin Date: Sat Jul 11 09:42:07 2026 +0200 hwmon: (asus-ec-sensors) fix looping over banks while reading from EC [ Upstream commit e741d13cc2abfc6fccebe2008057aa52e285223e ] Do not assume there are only bank 0 and bank 1 available, just use '!=' for bank comparison. Fixes: d0ddfd241e57 ("hwmon: (asus-ec-sensors) add driver for ASUS EC") Signed-off-by: Eugene Shalygin Link: https://lore.kernel.org/r/20260711074217.554656-1-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit d5913f97b5b60364953e17c4d8e0626ea44a15d6 Author: Mostafa Saleh Date: Wed Jun 3 11:05:21 2026 +0000 drivers/virt: pkvm: Fix end calculation in mmio_guard_ioremap_hook() [ Upstream commit 62c740f823a8e47ffe56e45a7472c27cf988e2f6 ] Sashiko (locally) reports a logical issues in mmio_guard_ioremap_hook() mmio_guard_ioremap_hook() attempts to handle unaligned addresses and sizes. However, aligning the start address before adding the size, might shift the end to the page before. Fixes: 0f1269495800 ("drivers/virt: pkvm: Intercept ioremap using pKVM MMIO_GUARD hypercall") Signed-off-by: Mostafa Saleh Reviewed-by: Catalin Marinas Tested-by: Aneesh Kumar K.V (Arm) Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit d0a57f19fe2865b9747484f5f9c631f944ed9a0f Author: Diego Fernando Mancera Gomez Date: Fri Jul 17 02:07:04 2026 -0600 usb: atm: ueagle-atm: reject descriptors that confuse probe and disconnect [ Upstream commit 71132cedd1ecbc4032d76e9928c18a10f7e39b80 ] uea_probe() distinguishes a pre-firmware device from a post-firmware one using the USB id (UEA_IS_PREFIRM()), and stores a different object as the interface data in each case: a 'struct completion' for a pre-firmware device (to be waited on in .disconnect()), or a 'struct usbatm_data' for a post-firmware one. uea_disconnect() instead tells the two apart by the number of interfaces of the active configuration (a pre-firmware device exposes a single interface, ADI930 has 2 and eagle has 3), and casts the interface data accordingly. Because the two handlers use different criteria, a crafted device that advertises a pre-firmware id together with a multi-interface descriptor (or a post-firmware id with a single interface) makes them disagree: the small 'struct completion' stored by uea_probe() is then passed to usbatm_usb_disconnect(), which casts it to 'struct usbatm_data' and takes instance->serialize, reading past the end of the allocation: BUG: KASAN: slab-out-of-bounds in __mutex_lock+0x152a/0x1b80 Read of size 8 at addr ffff8880470e2c60 by task kworker/1:2/982 ... __mutex_lock+0x152a/0x1b80 usbatm_usb_disconnect+0x70/0x820 uea_disconnect+0x133/0x2c0 usb_unbind_interface+0x1dd/0x9e0 ... which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes to the right of allocated 96-byte region [ffff8880470e2c00, ffff8880470e2c60) Reject such inconsistent descriptors in uea_probe() so that both handlers always make the same pre/post-firmware decision. Reported-by: syzbot+e62a973f8322b3bbe3ac@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e62a973f8322b3bbe3ac Fixes: e2674dfbed8a ("usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()") Signed-off-by: Diego Fernando Mancera Gomez Acked-by: Stanislaw Gruszka Link: https://patch.msgid.link/20260717080704.1264-1-diegomancera.dev@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2d5dec517b5390d4825419044d39e0ac84e47d28 Author: Shahar Tzarfati Date: Wed Jul 15 21:57:08 2026 +0300 wifi: iwlwifi: mvm: fix read in wake packet notification handler [ Upstream commit 9d7657aae8c1579584c67b0b66114a6a98db8b2f ] In iwl_mvm_wowlan_store_wake_pkt(), packet_len was initialized from notif->wake_packet_length before the explicit check that len >= sizeof(*notif). Move the assignment of packet_len to after the size check so that notif->wake_packet_length is only accessed once the payload length has been validated. Fixes: 219ed58feda9 ("wifi: iwlwifi: mvm: Add support for wowlan wake packet notification") Signed-off-by: Shahar Tzarfati Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715215523.99d5cf85a528.Ic4aa736011d4fe88e0cd19723d1d48bb24642198@changeid Signed-off-by: Sasha Levin commit eae7fdf7d4469d8405925cb264580ce7e8c06524 Author: Emmanuel Grumbach Date: Wed Jul 15 21:57:07 2026 +0300 wifi: iwlwifi: validate payload length in iwl_pnvm_complete_fn [ Upstream commit daec24a5ed5da77a108e246ad77aa8b889911f93 ] iwl_pnvm_complete_fn() casts pkt->data directly to struct iwl_pnvm_init_complete_ntfy and reads the status field without first verifying that the firmware notification payload is large enough to contain that structure. Add a WARN_ON_ONCE check against sizeof(*pnvm_ntf) and return early without reading uninitialised memory if the payload is too short. Fixes: b3e4c0f34c17 ("iwlwifi: move PNVM implementation to common code") Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715215523.7f2a669e5c75.I00465dcfcbccb250ae9af2d9bb305e24de1ba394@changeid Signed-off-by: Sasha Levin commit 70a6de303c9b3aa0e57e57af1580a227577090bf Author: Emmanuel Grumbach Date: Wed Jul 15 21:57:06 2026 +0300 wifi: iwlwifi: fix pointer arithmetic in iwl_add_mcc_to_tas_block_list [ Upstream commit bc796f84ec9a95b356959ec7caf1d4fce33f3a76 ] The expression list[*size++] increments the pointer 'size' rather than the u8 value it points to (operator precedence: ++ binds to the pointer before the dereference). As a result the block-list entry is written at the correct index but *size is never incremented, so the caller's count stays at zero and subsequent calls overwrite slot 0 every time. Change to list[(*size)++] so that the value pointed to by size is incremented after use as the array index. Fixes: 5f4656610edb ("wifi: iwlwifi: extend TAS_CONFIG cmd support for v5") Assisted-by: GitHubCopilot:gpt-5.3-codex Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715215523.d2cd92242582.Ife4140a4e27be2a1cd9f886c5a9b376ce182a019@changeid Signed-off-by: Sasha Levin commit a076b0c457c71a5436706c11b9c2fe047e2ce650 Author: Pagadala Yesu Anjaneyulu Date: Wed Jul 15 21:57:04 2026 +0300 wifi: iwlwifi: mvm: validate SAR GEO response payload size [ Upstream commit 408d7da38272ce48e2db79b8a9895999f94d7655 ] The SAR GEO command response is cast to iwl_geo_tx_power_profiles_resp without verifying the payload length. A malformed or unexpected firmware response can lead to reading an invalid structure layout. Add an explicit size check before accessing the response data and return -EIO when the payload size is wrong. Fixes: f604324eefec ("iwlwifi: remove iwl_validate_sar_geo_profile() export") Signed-off-by: Pagadala Yesu Anjaneyulu Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260715215523.7e749b7d374a.I4ef54548bff6c6e7c7a57bee771ac12508aad677@changeid Signed-off-by: Sasha Levin commit cdf895bfd8035069169fa5723862381828f14924 Author: Richard Fitzgerald Date: Thu Jul 16 14:20:45 2026 +0100 ASoC: cs35l56: Use complete_all() to signal init_completion [ Upstream commit e0bffb63a2eda0af82ed7e6357ac67c2db990c21 ] In cs35l56_init() use complete_all() to signal init_completion instead of complete(). cs35l56_init() was signaling init_completion using the complete() function. This only releases ONE waiter. If cs35l56_component_probe() was called multiple times the first time would consume that one signal, then future calls would timeout waiting for the completion. This could happen if: - The component is probed, removed, then probed again without the cs35l56 module being removed. - A call to component_probe() returns an error and ASoC calls it again later. It should use complete_all() so that after it has been signaled it will allow any code that waits on it to continue immediately. The one case where the driver must wait for initialization to run again is when waiting for a reboot after firmware download, and here the code correctly calls reinit_completion() first. Fixes: e496112529006 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260716132045.1469156-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3c26e8bb14cc64c53843615394cb17b52e56dda1 Author: Richard Fitzgerald Date: Thu Jul 16 14:20:44 2026 +0100 ASoC: cs35l56: Fix potential probe() deadlock [ Upstream commit 93c2a8ea2454b7b14eb378a58cad8a83c0ffc903 ] On I2C/SPI call cs35l56_init() before calling snd_soc_register_component() to prevent the potential for a deadlock on init_completion. For most buses all the hardware would be ready when probe() returns, but on SoundWire, probe() must return before the SoundWire bus driver will enumerate the device. All access to the registers must be deferred until the driver receives an ATTACHED notification. But anything that could return -EPROBE_DEFER must be called during probe, and that includes snd_soc_register_component(). Because of that, on SoundWire the ASoC component can be created before the registers are accssible, so cs35l56_component_probe() waits for init_completion to signal that the registers are accessible. On I2C/SPI this 2-stage startup isn't required so their probe() functions simply called cs35l56_common_probe() and then cs35l56_init(). The problem with this was that snd_soc_register_component() was still called early. If this triggered ASoC to create the card, ASoC would call cs35l56_component_probe() which waits on init_completion - but this would be running inside the cs35l56 driver probe() so blocking it from reaching the code that signals init_completion, causing a deadlock. Fixes: e496112529006 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Reported-by: Salman S. Tahir Closes: https://lore.kernel.org/linux-sound/95c21574-97d5-4311-9263-9e174d22d22c@opensource.cirrus.com/T/#u Tested-by: Salman S. Tahir Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260716132045.1469156-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1ddb3e0e502a1fdc7a2a9a677561616cb12ed09c Author: Richard Fitzgerald Date: Tue May 5 17:11:23 2026 +0100 ASoC: cs35l56: Don't use devres to unregister component [ Upstream commit bee87cf0f1248c0f20710d7a79df41fe892d9f88 ] Manually call snd_soc_unregister_component() from cs35l56_remove() instead of using devres cleanup. This ensures that the component is destroyed before cs35l56_remove() starts cleanup of anything the component code could be using. Devres cleanup happens after the driver remove() callback, so if snd_soc_register_component() is used, it will not be destroyed until after cs35l56_remove() has returned. But there is some cleanup that must be done in cs35l56_remove(), or wrapped in a custom devres cleanup handler to ensure correct ordering. The simplest option is to call snd_soc_unregister_component() at the start of cs35l56_remove(). Fixes: e49611252900 ("ASoC: cs35l56: Add driver for Cirrus Logic CS35L56") Closes: https://sashiko.dev/#/patchset/20260501103002.2843735-1-rf%40opensource.cirrus.com Signed-off-by: Richard Fitzgerald Link: https://patch.msgid.link/20260505161124.3621000-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown Stable-dep-of: 93c2a8ea2454 ("ASoC: cs35l56: Fix potential probe() deadlock") Signed-off-by: Sasha Levin commit 9153fa1ee99bf1168bc8c864a66155ed1453fb9c Author: Shengjiu Wang Date: Wed Jul 15 18:06:20 2026 +0800 ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI [ Upstream commit 0b604e886ece11b71c4daaeccc512c784b89b014 ] The bt-sco-pcm-wb DAI uses the same stream_name strings as bt-sco-pcm ("Playback" and "Capture"). This causes duplicate DAPM AIF widget names within the same component, leading to debugfs warnings: debugfs: 'Playback' already exists in 'dapm' debugfs: 'Capture' already exists in 'dapm' Give the wideband DAI distinct stream names ("WB Playback" and "WB Capture") and add corresponding DAPM AIF widgets and routes for them. Fixes: 5947e1b4992e ("ASoC: bt-sco: extend rate and add a general compatible string") Assisted-by: VeroCoder:claude-sonnet-4-5 Signed-off-by: Shengjiu Wang Link: https://patch.msgid.link/20260715100620.1387159-1-shengjiu.wang@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 08433c71f15984ddd5f5a307cf3f0aa9b84583aa Author: Guangshuo Li Date: Wed Jul 8 19:36:25 2026 +0800 ALSA: hda: cs35l41: validate and free ACPI mute object [ Upstream commit 3b597d24dc0455ae926f1053f97c2725038fc3cd ] cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it. Fixes: 447106e92a0c ("ALSA: hda: cs35l41: Support mute notifications for CS35L41 HDA") Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260708113625.752913-1-lgs201920130244@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit eca9fcf9f5d893ed9ca0bc869baecf0692265c2e Author: Chen-Yu Tsai Date: Tue Jul 14 19:33:03 2026 +0800 ASoC: sun4i-codec: Set quirks.playback_only for H616 codec [ Upstream commit d9e96f859de3ea3e99bce927a988449a1816483c ] The H616 codec does not have capture capabilities. Set the .playback_only quirks flag to denote this. This was somehow missing from the original driver patch, even though the patch prior to it in the series added this quirk. Fixes: 9155c321a1d0 ("ASoC: sun4i-codec: support allwinner H616 codec") Signed-off-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260714113304.270224-1-wens@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 41ae2b7d37c3dd82302167496836cca9f0328374 Author: Pengpeng Hou Date: Mon Jul 6 22:45:39 2026 +0800 ASoC: tas2781: bound firmware description string parsing [ Upstream commit bc889dfcea9294a1eae7f8e2f3573a90764ae4d0 ] The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string. Fixes: 915f5eadebd2 ("ASoC: tas2781: firmware lib") Signed-off-by: Pengpeng Hou Link: https://patch.msgid.link/20260706144540.93929-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 797dc567146c7e3c4f8d9680e4fbc76e0a6d9151 Author: Guanghui Yang <3497809730@qq.com> Date: Sun Jul 12 03:17:28 2026 +0000 btrfs: free mapping node on duplicate reloc root insert [ Upstream commit 6a8269b6459ed870a8156c106a0f597383907872 ] __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released. Fixes: 57a304cfd43b ("btrfs: do not panic in __add_reloc_root") Reviewed-by: Qu Wenruo Signed-off-by: Guanghui Yang <3497809730@qq.com> Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 9304713b70e7e1450e3a76e758836fe5391bfa95 Author: Leo Martins Date: Tue Jun 30 12:58:05 2026 -0700 btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps [ Upstream commit 5eff4d5b17fa1950e80bfd1ba43dc0699e61a644 ] When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb ("btrfs: use the flags of an extent map to identify the compression type") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb. CC: Jeff Layton Link: https://lore.kernel.org/all/20260629-btrfs-skip-logging-v1-1-4e3a28c1acaf@kernel.org/ Fixes: f86f7a75e2fb ("btrfs: use the flags of an extent map to identify the compression type") Reviewed-by: Jeff Layton Reviewed-by: Filipe Manana Signed-off-by: Leo Martins Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 39f196f64bd3842898799745cd2e64c37bf38dff Author: Dave Chen Date: Mon Jun 29 15:08:43 2026 +0800 btrfs: fix u32 to s64 type conversion in dirty_metadata_bytes accounting [ Upstream commit 8b5a09ceb61b18b1f0797cd30a549d7dc85d8d50 ] The percpu_counter dirty_metadata_bytes is updated by negating eb->len and passing it to percpu_counter_add_batch(), whose amount parameter is s64. Since commit 84cda1a6087d ("btrfs: cache folio size and shift in extent_buffer"), eb->len is u32. The u32 result of -eb->len, when widened to the s64 parameter, becomes a large positive value instead of the intended negative value. For eb->len == 16384 the counter adds +4294950912 instead of subtracting 16384. The counter therefore grows on every metadata writeback instead of shrinking by the extent buffer size, permanently exceeding BTRFS_DIRTY_METADATA_THRESH and causing __btrfs_btree_balance_dirty() to trigger balance_dirty_pages_ratelimited() unconditionally, adding unnecessary writeback pressure. Cast eb->len to s64 before negation at both call sites so the subtraction is performed in signed 64-bit arithmetic. Reviewed-by: Filipe Manana Fixes: 84cda1a6087d ("btrfs: cache folio size and shift in extent_buffer") Signed-off-by: Dave Chen Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f49ff44831d525a4e26a60273cf50b59001cdf93 Author: You-Kai Zheng Date: Tue Jun 16 18:39:07 2026 +0800 btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8 [ Upstream commit b95181f3929ff98949fa9460ca93eccebbf2d7fc ] The variable-sized buffer buf in struct btrfs_ioctl_search_args_v2 is declared as __u64[], but it holds a packed byte stream of search results, where all offsets into the buffer are in bytes. Declaring buf as __u64[] makes it easy for user space to write incorrect pointer arithmetic: adding a byte offset directly to a __u64 pointer scales the offset by 8, landing at byte position offset*8 instead of offset. This recently caused an infinite loop in btrfs-progs: the accessor read all-zero data from misaddressed items, which fed zeroed search keys back into the ioctl loop and spun forever. The issue was worked around at the time by disabling TREE_SEARCH_V2 entirely in btrfs-progs (d73e69824854: "btrfs-progs: temporarily disable usage of v2 of search tree ioctl"). The kernel side already treats buf as a byte buffer, so change the declaration to __u8[] to match the actual semantics and prevent similar misuse in user space. The change is ABI compatible: both the structure size and alignment are unchanged. Fixes: cc68a8a5a433 ("btrfs: new ioctl TREE_SEARCH_V2") Reviewed-by: Qu Wenruo Signed-off-by: You-Kai Zheng Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4503829843353dbb18b879c35be1cdfc9af677b7 Author: Tristan Madani Date: Tue Apr 21 13:49:28 2026 +0000 wifi: carl9170: fix buffer overflow in rx_stream failover path [ Upstream commit a1a21995c2e1cc2ca6b2226cfe4f5f018370182a ] The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Tristan Madani Acked-by: Christian Lamparter Closes: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac Link: https://patch.msgid.link/20260421134929.325662-4-tristmd@gmail.com [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT] Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit fab6ff91d5b8c4af62e2ced42fb357fa3eb9fd59 Author: Tristan Madani Date: Tue Apr 21 13:49:27 2026 +0000 wifi: carl9170: fix OOB read from off-by-two in TX status handler [ Upstream commit a3f42f1049ad80c65560d2b078ad426c3134f78d ] The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`. Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Tristan Madani Acked-by: Christian Lamparter Closes: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac Link: https://patch.msgid.link/20260421134929.325662-3-tristmd@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 9aee949c68dc6dccbc54333537b109c53fe2079f Author: Tristan Madani Date: Tue Apr 21 13:49:26 2026 +0000 wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read [ Upstream commit 4cde55b2feff9504d1f993ab80e84e7ccb62791c ] When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer. Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Tristan Madani Acked-by: Christian Lamparter Closes: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac Link: https://patch.msgid.link/20260421134929.325662-2-tristmd@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 33b5342d2080657054ddf89ef1199b426a37dae8 Author: Tristan Madani Date: Tue Apr 21 13:50:08 2026 +0000 wifi: ath6kl: fix OOB read from firmware IE lengths in connect event [ Upstream commit 6b47b29730de3232b919d8362749f6814c5f2a33 ] The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Signed-off-by: Tristan Madani Reviewed-by: Vasanthakumar Thiagarajan Link: https://patch.msgid.link/20260421135009.348084-3-tristmd@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit eb636fbc443149b3501c3f97e26225ddcb314a0f Author: Tristan Madani Date: Thu Jun 25 23:29:07 2026 +0000 wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler [ Upstream commit 3a21c89215cc18f1a97c5e5bfd1da6d4f3d44495 ] The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Signed-off-by: Tristan Madani Link: https://patch.msgid.link/20260625232907.3620746-1-tristmd@gmail.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 0177e578d7a885037b0fb82286c12e9d0360cc10 Author: Ruoyu Wang Date: Tue Jul 7 23:04:54 2026 +0800 firewire: net: Fix fragmented datagram reassembly [ Upstream commit d52a13adbb8ccbab99cd3bad36804e87d8b5c052 ] fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: c76acec6d551 ("firewire: add IPv4 support") Signed-off-by: Ruoyu Wang Link: https://lore.kernel.org/r/20260707150454.2265951-1-ruoyuw560@gmail.com Signed-off-by: Takashi Sakamoto Signed-off-by: Sasha Levin commit 51516fda914cce2b50139f446332d551c97cafdf Author: Manivannan Sadhasivam Date: Tue Jun 23 16:16:49 2026 +0200 wifi: ath12k: Flush the posted write after writing to PCIE_SOC_GLOBAL_RESET [ Upstream commit 55f3aa06951cac78b0206bde961c8cf11929a27a ] ath12k_pci_soc_global_reset() tries to reset the device by writing to the PCIE_SOC_GLOBAL_RESET register. But it doesn't do a read-back to ensure that the write gets flushed to the device before the delay. This may lead to the delay on the host to be insufficient, if the posted write doesn't reach the device before the delay. So add a read-back after writing to the PCIE_SOC_GLOBAL_RESET register and before the delay. Compile tested only. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Reported-by: Alex Williamson Closes: https://lore.kernel.org/linux-pci/20260622160822.09350246@shazbot.org Signed-off-by: Manivannan Sadhasivam Reviewed-by: Baochen Qiang Reviewed-by: Raj Kumar Bhagat Tested-by: Raj Kumar Bhagat Link: https://patch.msgid.link/20260623141649.41087-2-manivannan.sadhasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 9a9b0ea72d8b9504c7bd410be85d57451c9b485c Author: Manivannan Sadhasivam Date: Tue Jun 23 16:16:48 2026 +0200 wifi: ath11k: Flush the posted write after writing to PCIE_SOC_GLOBAL_RESET [ Upstream commit 0fe8010fc5b147607fc19ba010ba469afc95f35f ] ath11k_pci_soc_global_reset() tries to reset the device by writing to the PCIE_SOC_GLOBAL_RESET register. But it doesn't do a read-back to ensure that the write gets flushed to the device before the delay. This may lead to the delay on the host to be insufficient, if the posted write doesn't reach the device before the delay. So add a read-back after writing to the PCIE_SOC_GLOBAL_RESET register and before the delay. Compile tested only. Fixes: f3c603d412b3 ("ath11k: reset MHI during power down and power up") Reported-by: Alex Williamson Closes: https://lore.kernel.org/linux-pci/20260622160822.09350246@shazbot.org Signed-off-by: Manivannan Sadhasivam Reviewed-by: Baochen Qiang Reviewed-by: Raj Kumar Bhagat Link: https://patch.msgid.link/20260623141649.41087-1-manivannan.sadhasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit a154ca3c441a67d36b3a9ea63a4f11b06abe6223 Author: Dmitry Morgun Date: Sat May 30 11:42:52 2026 +0000 wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() [ Upstream commit 7f11e70629650ff6ea140984e5ce188b775b2683 ] When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Dmitry Morgun Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260530114252.42615-1-d.morgun@ispras.ru Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 8681e5addf7171602616e256a09057697dcc75ca Author: Wayen Yan Date: Wed Jul 8 10:41:54 2026 +0800 watchdog: airoha: Prevent division by zero when clock frequency is zero [ Upstream commit bcfcd7619f277842430d197556463b401b839ee9 ] clk_get_rate() can return 0 when the clock provider is not properly configured or the clock is unmanaged. The driver uses wdt_freq as a divisor directly in airoha_wdt_probe() to compute max_timeout and in airoha_wdt_get_timeleft() to compute the remaining time, which results in a division by zero. Add a check for wdt_freq == 0 in probe and return -EINVAL with dev_err_probe() to prevent the division by zero and provide a diagnostic message. Fixes: 3cf67f3769b8 ("watchdog: Add support for Airoha EN7851 watchdog") Signed-off-by: Wayen Yan Link: https://lore.kernel.org/r/178347932594.81327.4834644880399144119@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 7d1658b066de30f4b23afc14814d22416a971e6e Author: Tzung-Bi Shih Date: Tue Jul 7 10:18:03 2026 +0000 watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() [ Upstream commit 7362ba0f9c96ac3ad6a2ca3995bd9fc9a28a8661 ] When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered. Fixes: da0d12ff2b82 ("watchdog: pretimeout: add panic pretimeout governor") Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20260707101803.3598173-1-tzungbi@kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 305c23993e43db9a3681978691b1f9f2a1b26299 Author: Guenter Roeck Date: Tue Jul 7 18:01:58 2026 -0700 hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop [ Upstream commit f151d0143ac4e086f92f52328ebdbdc50933d8ef ] Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after "io start" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). Reported-by: Sashiko Fixes: f3b4b146eb107 ("hwmon: Add driver for NZXT Kraken X and Z series AIO CPU coolers") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 205cff797a94757ec88ba299c8e2bf2e1e3f4bbf Author: Guenter Roeck Date: Tue Jul 7 18:00:32 2026 -0700 hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop [ Upstream commit 59d104b54b0b42e30fd2a68d24ee5c49dcc54d1e ] Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after "io start" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). Reported-by: Sashiko Fixes: 53e68c20aeb1e ("hwmon: add driver for NZXT RGB&Fan Controller/Smart Device v2") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit f36e12cc8cfe996d627b8a82bd9df9e43270f6e2 Author: Guenter Roeck Date: Tue Jul 7 17:59:10 2026 -0700 hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop [ Upstream commit ff0c5c53d08274e200b48a4d53aa078265e873cb ] Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after "io start" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). Reported-by: Sashiko Fixes: 42ac68e3d4ba0 ("hwmon: Add driver for Gigabyte AORUS Waterforce AIO coolers") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 56d2deb6448378118dbe68c4fbb3fbae5f65b18c Author: Guenter Roeck Date: Tue Jul 7 17:52:54 2026 -0700 hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop [ Upstream commit 94c87871b051d7ad758828a805215a2ec194512a ] Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after "io start" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). Reported-by: Sashiko Fixes: 40c3a44542257 ("hwmon: add Corsair Commander Pro driver") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ec477af3a7e8d3964e62fd24ef01cdebb96b8e4e Author: Edward Adam Davis Date: Tue Apr 28 12:12:26 2026 +0800 hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop [ Upstream commit 9ab8656548cd737b98d0b19c4253aff8d68e97f4 ] hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after "io start" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0 CPU1 ==== ==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw) __hid_input_report() ... acquire driver_input_lock hid_report_raw_event() hidraw_report_event() ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). Fixes: d115b51e0e56 ("hwmon: add Corsair PSU HID controller driver") Reported-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9eebf5f6544c5e873858 Tested-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Link: https://lore.kernel.org/r/tencent_BB7C33EB9EA41B7B4B5F1B8B25C0BA13BB08@qq.com [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit e5394605f9a985cc3a8263e610ba84b33cbe7b0c Author: Gaole Zhang Date: Tue Jun 9 17:06:09 2026 +0800 wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin [ Upstream commit e8d85672dd7e2523f774caafba8f858384e18df7 ] In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1 Fixes: 6fe62a8cec51c ("wifi: ath11k: Add cold boot calibration support on WCN6750") Signed-off-by: Gaole Zhang Reviewed-by: Baochen Qiang Reviewed-by: Rameshkumar Sundaram Link: https://patch.msgid.link/20260609090609.4041009-1-gaole.zhang@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 48a69cedde7388294e4ea6fd804156cd62bc04fc Author: Cheng Yongkang Date: Fri Jun 5 08:32:10 2026 -0700 wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request [ Upstream commit dad9f96945d77ecd4708f730c06ef54dcd8cc057 ] ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: dev_info(&hif_dev->udev->dev, "ath9k_htc: Firmware %s requested\n", hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the "events" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened. Fixes: e904cf6fe230 ("ath9k_htc: introduce support for different fw versions") Reported-by: syzbot+50122cbc2874b1eb25b0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=50122cbc2874b1eb25b0 Signed-off-by: Cheng Yongkang Acked-by: Toke Høiland-Jørgensen Link: https://patch.msgid.link/20260605153210.20471-1-1020691186@qq.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin commit 593072aae7fc82189adf832c8b54c61d19702188 Author: Daniel Borkmann Date: Tue Jul 28 15:25:09 2026 +0800 selftests/bpf: Keep verifier_map_ptr exercising ops pointer access commit 082c412097716b93ff1365689fc4ddcd1ce8296f upstream. sashiko complained that 38498c0ebacd ("selftests/bpf: Adjust verifier_map_ptr for the map's excl field") would slightly decrease the test coverage given before the test was against the verifier rejecting the ops pointer. Recover the old test with the right offsets and add the existing one as an additional test case. # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t verifier_map_ptr [ 1.672932] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel #637/1 verifier_map_ptr/bpf_map_ptr: read with negative offset rejected:OK #637/2 verifier_map_ptr/bpf_map_ptr: read with negative offset rejected @unpriv:OK #637/3 verifier_map_ptr/bpf_map_ptr: write rejected:OK #637/4 verifier_map_ptr/bpf_map_ptr: write rejected @unpriv:OK #637/5 verifier_map_ptr/bpf_map_ptr: read non-existent field rejected:OK #637/6 verifier_map_ptr/bpf_map_ptr: read non-existent field rejected @unpriv:OK #637/7 verifier_map_ptr/bpf_map_ptr: read beyond excl field rejected:OK #637/8 verifier_map_ptr/bpf_map_ptr: read beyond excl field rejected @unpriv:OK #637/9 verifier_map_ptr/bpf_map_ptr: read ops field accepted:OK #637/10 verifier_map_ptr/bpf_map_ptr: read ops field accepted @unpriv:OK #637/11 verifier_map_ptr/bpf_map_ptr: r = 0, map_ptr = map_ptr + r:OK #637/12 verifier_map_ptr/bpf_map_ptr: r = 0, map_ptr = map_ptr + r @unpriv:OK #637/13 verifier_map_ptr/bpf_map_ptr: r = 0, r = r + map_ptr:OK #637/14 verifier_map_ptr/bpf_map_ptr: r = 0, r = r + map_ptr @unpriv:OK #637 verifier_map_ptr:OK [...] Summary: 2/20 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260602133052.423725-4-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Shung-Hsi Yu Signed-off-by: Sasha Levin commit 938bcf99f53e808a3f0f432b8453d2f1e3ffeeea Author: KP Singh Date: Tue Jul 28 15:25:08 2026 +0800 selftests/bpf: Adjust verifier_map_ptr for the map's excl field commit 38498c0ebacd54dbaac3513a548a13f1a8455c4e upstream. Adding the u32 excl field at offset 32 of struct bpf_map right after the sha[SHA256_DIGEST_SIZE] hash shifts the ops pointer from offset 32 to 40. Therefore, fix up the test case. # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t verifier_map_ptr [...] #637/1 verifier_map_ptr/bpf_map_ptr: read with negative offset rejected:OK #637/2 verifier_map_ptr/bpf_map_ptr: read with negative offset rejected @unpriv:OK #637/3 verifier_map_ptr/bpf_map_ptr: write rejected:OK #637/4 verifier_map_ptr/bpf_map_ptr: write rejected @unpriv:OK #637/5 verifier_map_ptr/bpf_map_ptr: read non-existent field rejected:OK #637/6 verifier_map_ptr/bpf_map_ptr: read non-existent field rejected @unpriv:OK #637/7 verifier_map_ptr/bpf_map_ptr: read ops field accepted:OK #637/8 verifier_map_ptr/bpf_map_ptr: read ops field accepted @unpriv:OK [...] Summary: 2/18 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: KP Singh Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260601150248.394863-7-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Shung-Hsi Yu Signed-off-by: Sasha Levin commit fe7892d46921ee56b135779d32c40cb462e6c6c5 Author: Xincheng Zhang Date: Tue Jul 28 13:43:41 2026 +0800 usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits commit 1fc50f1ecde39feb4fccdaf4bc71aa6c0eb25c49 upstream. The VIA VL805/806 xHCI controller advertises AC64, but fails to handle DMA addresses at or above 0x1000000000. On systems with large amounts of RAM, this can cause USB device failures when the controller is given DMA addresses beyond its usable address width. Do not use XHCI_NO_64BIT_SUPPORT for this controller. That quirk clears the cached AC64 capability and limits DMA to 32 bits, causing unnecessary bouncing for addresses between 4GiB and 64GiB and hiding the controller's real AC64 capability from code that may need to distinguish register access width from usable DMA address width. Track the usable DMA address width separately from the AC64 capability. Initialize the generic xhci->dma_mask_bits field to 64 and let PCI quirks reduce it for controllers with narrower DMA support. Set VIA VL805/806 to 36 bits so the DMA API only hands it addresses in the range it can handle while keeping HCCPARAMS1.AC64 visible. Cc: stable@kernel.org Signed-off-by: Xincheng Zhang Link: https://patch.msgid.link/20260630-xhci-via-dma-fix-v3-1-690dcb8cf75a@ultrarisc.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 958624d6386036d966805def6250972947201817 Author: Sasha Levin Date: Mon Jul 27 14:07:33 2026 -0400 Revert "drm/amd/display: Add missing kdoc for ALLM parameters" This reverts commit 038a0f01dda595dceda8f0c9c5172b1297281929. Signed-off-by: Sasha Levin commit 03eb7a8099474c49915a62f2efee577816b306e6 Author: Xie Bo Date: Mon Jul 27 10:42:22 2026 +0800 RISC-V: KVM: Serialize virtual interrupt pending state updates commit d024a0a7879e6f37c0152aacf6d8e37b214a1738 upstream. KVM RISC-V tracks guest local interrupt state with two bitmaps: - irqs_pending: interrupts that should be visible to the guest - irqs_pending_mask: interrupts whose pending state changed The current code updates those bitmaps with independent atomic bitops and assumes a multiple-producer, single-consumer protocol. That model does not actually hold. kvm_riscv_vcpu_sync_interrupts() is not a pure consumer. When the guest changes guest-visible HVIP state, sync_interrupts() writes both irqs_pending and irqs_pending_mask to reflect the new guest state back into KVM state. As a result, irqs_pending and irqs_pending_mask form a single logical state transition, but they are not updated atomically as a pair. This allows a race where a newly injected interrupt is lost. For example: CPU0 CPU1 ---- ---- kvm_riscv_vcpu_set_interrupt(VS_SOFT) set_bit(VS_SOFT, irqs_pending) kvm_riscv_vcpu_sync_interrupts() sees guest-cleared HVIP.VSSIP sets irqs_pending_mask clear_bit(IRQ_VS_SOFT, irqs_pending) set_bit(VS_SOFT, irqs_pending_mask) kvm_vcpu_kick() After that interleaving, a later flush can update HVIP without VSSIP even though a new virtual interrupt was injected. In practice, the guest can remain blocked in WFI with work pending. The same pending/mask protocol is shared by VS soft interrupts, PMU overflow delivery, and AIA high interrupt synchronization, so the race is not limited to one interrupt source. Fix this by serializing all updates to irqs_pending and irqs_pending_mask with a per-vCPU raw spinlock. This keeps the pending bit and the dirty mask as one state transition across: - set/unset interrupt - guest HVIP sync - interrupt flush to guest CSR state - vCPU reset - AIA CSR writes that clear dirty state Use non-atomic bitmap operations while holding the lock. Hold the lock across the AIA sync, flush, and pending checks as well, so both bitmap words share the same serialization domain. This intentionally replaces the existing lockless protocol instead of trying to repair it with additional barriers. The problem is not memory ordering on a single field; it is that two separate bitmaps encode one shared state machine while both producers and sync paths can modify them. A per-vCPU raw spinlock keeps the fix small, local, and suitable for backporting. Fixes: cce69aff689e ("RISC-V: KVM: Implement VCPU interrupts and requests handling") Cc: stable@vger.kernel.org Signed-off-by: Xie Bo Reviewed-by: Anup Patel Link: https://lore.kernel.org/r/20260715020359.1521354-2-xb@ultrarisc.com Signed-off-by: Anup Patel [ bo: Adapt the AIA and general CSR helpers to their 6.18.y layout. ] Signed-off-by: Sasha Levin commit 731acda5ba777240d51c3f027add0712537107fe Author: Georgi Valkov Date: Mon Jul 13 01:17:09 2026 +0300 wifi: mwifiex: fix freeze for 60 seconds caused by request_firmware [ Upstream commit 121a96c5a0db8d18e2ba2cb89660cca8a40508fe ] Fix regression in rgpower table loading, caused by using request_firmware(): when the requested firmware does not exist, e.g. nxp/rgpower_WW.bin does not exist on OpenWRT builds for WRT3200ACM, request_firmware() falls back to firmware_fallback_sysfs(), which expects the firmware to be provided by user space using SYSFS. No such utility is provided in this configuration, so the entire system locks up for 60 seconds, until the request times out. During this time, no other log messages are observed, and the device does not respond to commands over UART. The request_firmware() call is performed in the following context: current->comm kworker/1:2 in_task 1 irqs_disabled 0 in_atomic 0 Fixed by using request_firmware_direct(). This prevents fallback to SYSFS, and avoids delay. The rgpower table is optional. The driver falls back to the device tree power table if the firmware is not present. The error code is printed for debugging and returned to the caller, which only cares for success or failure, so there are no side effects. Fixes: 7b6f16a25806 ("wifi: mwifiex: add rgpower table loading support") Signed-off-by: Georgi Valkov Reviewed-by: Francesco Dolcini Link: https://patch.msgid.link/20260712221709.7099-1-gvalkov@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0905b3ce1deb7228c779388fa8a8ea811821833c Author: Chia-Lin Kao (AceLan) Date: Mon Jul 13 16:43:22 2026 +0800 usb: typec: ucsi: Add duplicate detection to nvidia registration path commit f1aa17f72f9b9589bd724dc826c5b17d164193d1 upstream. Extend the duplicate altmode detection to ucsi_register_altmodes_nvidia() which is used when a driver provides the update_altmodes() callback. This ensures all drivers benefit from duplicate detection, whether they use the standard registration path or the nvidia path with update_altmodes callback. Without this fix, drivers using the nvidia path (like yoga_c630) would still encounter duplicate altmode registration errors from buggy firmware. Fixes: a79f16efcd00 ("usb: typec: ucsi: Add support for the partner USB Modes") Cc: stable Signed-off-by: Chia-Lin Kao (AceLan) Link: https://patch.msgid.link/20260713084323.287516-2-acelan.kao@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit fe8cde072293cfbe484135398a8ffddda722aca6 Author: Chia-Lin Kao (AceLan) Date: Mon Jul 13 16:43:21 2026 +0800 usb: typec: ucsi: Detect and skip duplicate altmodes from buggy firmware commit 67c92c6419ea6dbc5b1f3e9691aecea956e3e81c upstream. Some firmware implementations incorrectly return the same altmode multiple times at different offsets when queried via UCSI_GET_ALTERNATE_MODES. This causes sysfs duplicate filename errors and kernel call traces when the driver attempts to register the same altmode twice: sysfs: cannot create duplicate filename '/devices/.../typec/port0/port0.0/partner' typec-thunderbolt port0-partner.1: failed to create symlinks typec-thunderbolt port0-partner.1: probe with driver typec-thunderbolt failed with error -17 The matching rules differ by recipient: - UCSI_RECIPIENT_CON (port) and UCSI_RECIPIENT_SOP_P (plug): Two altmodes with identical SVID and VDO are byte-for-byte duplicates and the second has no observable function, so drop it. - UCSI_RECIPIENT_SOP (partner): The typec class binds each partner altmode to a port altmode of the same SVID via altmode_match()/device_find_child(), which returns the first port altmode with a matching SVID. If the partner advertises more altmodes for SVID X than the port advertises, the surplus partner altmode(s) collapse onto an already-paired port altmode and trigger the "duplicate filename .../partner" sysfs error during typec_altmode_create_links(). Use the port-side altmode count for SVID X as the authoritative cap and reject any partner altmode that would exceed it. This preserves legitimate multi-Mode partner altmodes (vendor SVIDs that the port really does advertise more than once) while filtering the firmware-generated duplicates that have no port counterpart, and is therefore stricter than a plain SVID+VDO comparison (which still admits the Thunderbolt case where firmware reports the same SVID twice with different VDOs) without being over-broad like a plain SVID match (which would falsely drop legitimate vendor multi-Mode entries). If a duplicate is detected, skip it and emit a clean warning instead of generating a kernel call trace: ucsi_acpi USBC000:00: con2: Firmware bug: duplicate partner altmode SVID 0x8087 at offset 1, ignoring. ucsi_acpi USBC000:00: con2: VDO mismatch: 0x8087a043 vs 0x00000001 The duplicate detection logic lives in a reusable helper ucsi_altmode_is_duplicate() and is invoked from ucsi_register_altmodes(). It applies to all three recipient types: partner (SOP), port (CON), and plug (SOP_P) altmodes. Fixes: a79f16efcd00 ("usb: typec: ucsi: Add support for the partner USB Modes") Cc: stable Signed-off-by: Chia-Lin Kao (AceLan) unchanged: still SVID+VDO exact-dup match. Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260713084323.287516-1-acelan.kao@canonical.com Signed-off-by: Greg Kroah-Hartman commit 67d2626827e3c2f1c0c79c5b35076b9fa2cbd36b Author: Chukun Pan Date: Wed Jul 8 18:00:01 2026 +0800 USB: serial: option: add TDTECH MT5710-CN commit 55645e4f3c6022ffb160ad3617d2b624eaa38501 upstream. Add support for the TDTECH MT5710-CN (5G redcap) module based on the Huawei HiSilicon Balong chip. T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=3466 ProdID=3301 Rev=ff.ff S: Manufacturer=TD Tech Ltd. S: Product=TDTECH MT571X S: SerialNumber=0123456789ABCDEF C:* #Ifs= 6 Cfg#= 1 Atr=c0 MxPwr= 0mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0d Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_ncm E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=13 Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=12 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=1c Driver=option E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=14 Driver=option E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Interface: ECM / NCM + DIAG + AT + SERIAL + GPS Signed-off-by: Chukun Pan Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 601f75671b8fb4d4ee540e91f17fe0208c83b63a Author: Johan Hovold Date: Wed Jul 8 16:31:35 2026 +0200 USB: serial: keyspan_pda: fix data loss on receive throttling commit 42a97c0480f96a2977e6d51ce512adc780f1ef5d upstream. Killing the interrupt-in urb when the line disciple requests throttling may lead to data loss if an ongoing transfer is cancelled. Instead set a flag to prevent the completion handler from resubmitting the urb until the port is unthrottled. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit cbe00048b69d67c8a78293cb7681b4c9963b26c7 Author: Sunho Park Date: Tue Jul 14 19:42:30 2026 +0900 USB: serial: io_edgeport: cap received transmit credits commit faaddd811c5099f11a5f52e68a6b31a5898cda4f upstream. The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Sunho Park Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit c1611c6744e3aa95f40ce6a21bca5037ab01a349 Author: Tim Pambor Date: Sat Jul 11 17:36:30 2026 +0000 USB: serial: ftdi_sio: add support for E+H FXA291 commit fad0fd120e29041b3e6cdf41bb12e3184fb524a2 upstream. The Commubox FXA291 by Endress+Hauser AG is a USB serial converter based on FT232B which is used to communicate with field devices. It enumerates using the FTDI vendor ID and a custom PID. usb 1-9: New USB device found, idVendor=0403, idProduct=e510, bcdDevice= 4.00 usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-9: Product: FXA291 usb 1-9: Manufacturer: Endress+Hauser usb 1-9: SerialNumber: 00000000 ftdi_sio 1-9:1.0: FTDI USB Serial Device converter detected usb 1-9: Detected FT232B usb 1-9: FTDI USB Serial Device converter now attached to ttyUSB0 Signed-off-by: Tim Pambor Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 1f03658f3e9b2f8fd1d1003ba389a0390b49a350 Author: Muhammad Bilal Date: Tue Jun 30 00:50:04 2026 +0500 usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer commit b70dc75e85ba968b7b76eebfe5d63000080b875b upstream. uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: req->length = min_t(unsigned int, uvc->event_length, data->length); ... memcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well. Fixes: a5eaaa1f33e7 ("usb: gadget: uvc: use capped length value") Cc: stable Signed-off-by: Muhammad Bilal Link: https://patch.msgid.link/20260629195004.148405-1-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit dcf3e2f164435b5844706cb8eefef29ebee0eedb Author: Fan Wu Date: Thu Jul 9 02:09:04 2026 +0000 usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown commit 0583f2fbf8f86ae3a0ce054f96783dd83e65d9bb upstream. The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool. Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC") Cc: stable Assisted-by: Codex:gpt-5.5 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260709020904.502611-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 40c706a0224bde194667e3378c689b542fec4b44 Author: Sonali Pradhan Date: Fri Jul 3 08:37:24 2026 +0000 usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() commit 1febec7e47cdcd01f43fb0211094e3010474666e upstream. When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary. Fixes: 427694cfaafa ("usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call") Fixes: 2b74b0a04d3e ("USB: gadget: f_ncm: add bounds checks to ncm_unwrap_ntb()") Cc: stable Assisted-by: Jetski:Gemini-2.5-Pro Signed-off-by: Sonali Pradhan Link: https://patch.msgid.link/20260703083725.1903850-1-sonalipradhan@google.com Signed-off-by: Greg Kroah-Hartman commit 12b3edca90d4dea345e2ae5382b364a3f3c5f587 Author: Johan Hovold Date: Thu Jul 2 16:15:35 2026 +0200 USB: gadget: fsl-udc: fix dev_printk() device commit c4dd150fceab281496acb3a643ae712aacb74864 upstream. A change replacing custom printk() macros with dev_printk() incorrectly used the gadget struct device instead of the controller struct device (including for messages printed before the gadget device name has been initialised). Switch to using the controller platform device with dev_printk() so that the controller device and driver names are included in log messages as expected. Fixes: 6025f20f16c2 ("usb: gadget: fsl-udc: Replace custom log wrappers by dev_{err,warn,dbg,vdbg}") Cc: stable Cc: Uwe Kleine-König Signed-off-by: Johan Hovold Acked-by: Uwe Kleine-König Link: https://patch.msgid.link/20260702141536.90887-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 66956a5a4258c5032d7b88743baa0033114a2820 Author: Johan Hovold Date: Thu Jul 2 16:15:33 2026 +0200 USB: gadget: fsl-udc: fix device name leak on probe failure commit 6b874d00c466e73c6448a89856407fe46b2f50e4 upstream. The gadget device name is set by UDC core when registering the gadget and must not be set before to avoid leaking the name in intermediate error paths (e.g. on dma pool creation failure). Fixes: eab35c4e6d95 ("usb: gadget: fsl_udc_core: let udc-core manage gadget->dev") Cc: stable Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260702141536.90887-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit e5ecfb776752616fe93809d5db619cd3b239e721 Author: Johan Hovold Date: Thu Jul 2 16:15:34 2026 +0200 USB: gadget: snps-udc: fix device name leak on probe failure commit 29a142d3e8b35ebc9e0bcc78f4bc26c9b6a9ac0b upstream. The gadget device name is set by UDC core when registering the gadget and must not be set before to avoid leaking the name in intermediate error paths (e.g. when detecting an older chip revision). Fixes: 12ad0fcaf2fb ("usb: gadget: amd5536udc: let udc-core manage gadget->dev") Cc: stable Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260702141536.90887-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 4cde0b38cc0cb8b7dc17295801015148de37d1d2 Author: Melbin K Mathew Date: Thu Jul 9 21:56:22 2026 +0100 usb: gadget: printer: fix infinite loop in printer_read() commit c2e819be6a5c7f34344926b4bd7e3dfca58cf48a upstream. printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress. Fixes: b185f01a9ab7 ("usb: gadget: printer: factor out f_printer") Cc: stable Reviewed-by: Peter Chen Signed-off-by: Melbin K Mathew Link: https://patch.msgid.link/20260709205622.55700-1-mlbnkm1@gmail.com Signed-off-by: Greg Kroah-Hartman commit f45089eaad0a083d71d84ff175741d7e157d9b69 Author: Fan Wu Date: Thu Jul 9 15:07:17 2026 +0000 usb: gadget: f_midi: cancel pending IN work before freeing the midi object commit 5650c18d93a1db7e27cb5a40b394747eb4686d5b upstream. The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool. Fixes: 8653d71ce3763 ("usb/gadget: f_midi: Replace tasklet with work") Cc: stable Assisted-by: Codex:gpt-5.5 Signed-off-by: Fan Wu Link: https://patch.msgid.link/20260709150717.399083-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit e239ea91b48180ed48a86ac25643832a02c88456 Author: Jinchao Wang Date: Thu Jul 16 06:42:17 2026 -0400 usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback commit d5e5cd3654d2b5359a12ea6586120f05b28634ee upstream. dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the "emulated single-request FIFO" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as "the slot is free". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished. Reported-by: syzbot+faf3a6cf579fc65591ca@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=faf3a6cf579fc65591ca Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Jinchao Wang Reviewed-by: Alan Stern Link: https://patch.msgid.link/5db8bba5b3499a86cd2e776f9918126b68b2508b.1784198306.git.wangjinchao600@gmail.com Signed-off-by: Greg Kroah-Hartman commit ace1a0adfc7866410263b624c69545033647467f Author: Xu Yang Date: Thu Jul 16 18:41:26 2026 +0800 usb: chipidea: fix usage_count leak when autosuspend_delay is negative commit fc3afb5728e297994863f8a2a01b88a920bbf53e upstream. The probe() calls pm_runtime_use_autosuspend(), but remove() does not call pm_runtime_dont_use_autosuspend(). This can lead to a usage_count leak if autosuspend_delay is set to a negative value. The pm_runtime_use_autosuspend() also notes that it's important to undo this with pm_runtime_dont_use_autosuspend() at driver exit time. Fixes: 1f874edcb731 ("usb: chipidea: add runtime power management support") Cc: stable Assisted-by: Claude:claude-sonnet-4.6 Signed-off-by: Xu Yang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260716104126.2763454-1-xu.yang_2@oss.nxp.com Signed-off-by: Greg Kroah-Hartman commit 8eca14198c2020e4cb105f46126b48dd7c936b20 Author: Huang Wei Date: Thu Jul 16 11:33:41 2026 +0800 USB: storage: add NO_ATA_1X quirk for Longmai USB Key commit 3b4ca2e01c1dd8c00b675b794732945f460a471b upstream. The Longmai Technologies USB Key (0x04b4:0xb708) advertises itself as a SCSI/Bulk-only mass storage device but does not correctly handle ATA pass-through commands. When such a command (ATA_12 or ATA_16) is sent to the device it fails to respond and the transfer eventually times out, leaving the device unusable. Add an unusual_devs entry for this device that sets the US_FL_NO_ATA_1X flag, so usb-storage short-circuits ATA pass-through commands and returns INVALID COMMAND OPERATION CODE (0x20 0x05 0x24 0x00) instead of forwarding them to the device. Information about the device in /sys/kernel/debug/usb/devices: T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 12 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=06 Prot=50 MxPS=64 #Cfgs= 1 P: Vendor=04b4 ProdID=b708 Rev= 1.00 S: Manufacturer=Longmai Technologies S: Product=USB Key C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Reported-by: Ai Chao Cc: stable Signed-off-by: Huang Wei Acked-by: Alan Stern Link: https://patch.msgid.link/20260716033341.2830872-1-huangwei@kylinos.cn Signed-off-by: Greg Kroah-Hartman commit 0950ac52426b0ab32d3b8cf4afe1711668b19cb8 Author: Guangshuo Li Date: Mon Jul 13 19:47:11 2026 +0800 usb: musb: omap2430: Do not put borrowed of_node in probe commit c947360ae63eee1c9eacc030dd6f5a53f717addf upstream. omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately. Fixes: ffbe2feac59b ("usb: musb: omap2430: Fix probe regression for missing resources") Cc: stable Reviewed-by: Johan Hovold Signed-off-by: Guangshuo Li Link: https://patch.msgid.link/20260713114711.955253-1-lgs201920130244@gmail.com Signed-off-by: Greg Kroah-Hartman commit 7714fb896ed308cf13d32d317040adc4f200b8e4 Author: Chia-Lin Kao (AceLan) Date: Thu Jun 11 15:12:01 2026 +0800 usb: core: port: Deattach Type-C connector on component unbind commit e0b291fe117964037e0ba382eff4bb365d531c3a upstream. connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising ("PCIe link lost"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path. Fixes: 11110783f5ea ("usb: Inform the USB Type-C class about enumerated devices") Cc: stable Signed-off-by: Chia-Lin Kao (AceLan) Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20260611071201.1235545-1-acelan.kao@canonical.com Signed-off-by: Greg Kroah-Hartman commit fb1b50ab699211e777dca5ccfb648788b6a6e519 Author: Huihui Huang Date: Wed Jul 15 22:08:10 2026 +0800 wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() commit 61a799ffd1e5a4fd3702d547828b7ff3d161468e upstream. at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: len -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off. Fixes: 1264b951463a ("at76c50x-usb: add driver") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Huihui Huang Link: https://patch.msgid.link/20260715140815.1242033-1-hhhuang@smu.edu.sg Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 217774e143d7b5a88739193284b6421be3978601 Author: Griffin Kroah-Hartman Date: Wed Jul 15 16:59:05 2026 +0200 usb: core: sysfs: add lock to bos_descriptors_read() commit 4e0197fbb0eec588795d5431716a244d9ac8fa93 upstream. Add a lock to the function bos_descriptors_read(). This function accesses udev->bos, which could be simultaneously freed in usb_reset_and_verify_device(), a function that is commonly called in drivers all over the kernel. Assisted-by: gkh_clanker_t1000 Signed-off-by: Griffin Kroah-Hartman Acked-by: Alan Stern Cc: stable Link: https://patch.msgid.link/20260715-usb_core_patches_3-v1-1-53021f5576fd@kroah.com Signed-off-by: Greg Kroah-Hartman commit 5f6e7b32bd1fbde10fd31a4143260735ea535b8a Author: Weiming Shi Date: Sat Jul 11 04:50:00 2026 -0700 mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n [ Upstream commit 56d96fededd61192cd7cc8d2b0f36adfd59036c3 ] On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does. Fixes: 196cfebf8972 ("net/mpls: Handle kernel side filtering of route dumps") Assisted-by: Claude:claude-opus-4-8 Reported-by: Xiang Mei Signed-off-by: Weiming Shi Reviewed-by: David Ahern Link: https://patch.msgid.link/20260711114958.1009619-3-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a8d20ba0ab518c9ccbcde258f25fc1ee6e51d5db Author: Xin Long Date: Fri Jul 10 14:12:35 2026 -0400 sctp: fix auth_hmacs array size in struct sctp_cookie [ Upstream commit e0b5252a59383b77d1b8dbeda00b7184dd95f4d3 ] The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size. Fixes: 1f485649f529 ("[SCTP]: Implement SCTP-AUTH internals") Reported-by: Yuan Tan Reported-by: Xin Liu Reported-by: Zihan Xi Reported-by: Ren Wei Signed-off-by: Xin Long Link: https://patch.msgid.link/634a0de0d5de29532915e6d47c92a0cbc206e03f.1783707155.git.lucien.xin@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit fed1b1ddab41a0e7a462ac690a0c8af6ff793624 Author: Jamal Hadi Salim Date: Sat Jul 11 11:05:37 2026 -0400 net/sched: act_tunnel_key: Defer dst_release to RCU callback [ Upstream commit f1f5c8a3955f8fda3f84ed883ac8daa1847e724c ] Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x4fff00000000240(workingset|head|node=1|zone=1|lastcpupid=0x7ff) page_type: f5(slab) raw: 04fff00000000240 ffff88801c841b40 ffffea0001856290 ffffea0001856190 raw: ffff88806158d600 0000000800100009 00000000f5000000 0000000000000000 head: 04fff00000000240 ffff88801c841b40 ffffea0001856290 ffffea0001856190 head: ffff88806158d600 0000000800100009 00000000f5000000 0000000000000000 head: 04fff00000000001 ffffffffffffff81 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000002 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 1, migratetype Unmovable, gfp_mask 0xd2820(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 9391, tgid 9378 (poc), ts 123227323196, free_ts 0 set_page_owner include/linux/page_owner.h:32 post_alloc_hook+0xfe/0x140 mm/page_alloc.c:1853 prep_new_page mm/page_alloc.c:1861 get_page_from_freelist+0x110c/0x2fc0 mm/page_alloc.c:3941 __alloc_frozen_pages_noprof+0x263/0x2bc0 mm/page_alloc.c:5221 alloc_slab_page mm/slub.c:3278 allocate_slab mm/slub.c:3467 new_slab+0xa6/0x690 mm/slub.c:3525 refill_objects+0x271/0x420 mm/slub.c:7272 refill_sheaf mm/slub.c:2816 __pcs_replace_empty_main+0x373/0x630 mm/slub.c:4652 alloc_from_pcs mm/slub.c:4750 slab_alloc_node mm/slub.c:4884 __do_kmalloc_node mm/slub.c:5295 __kmalloc_noprof+0x66d/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 metadata_dst_alloc+0x26/0x90 net/core/dst.c:298 tun_rx_dst include/net/dst_metadata.h:144 __ip_tun_set_dst include/net/dst_metadata.h:208 tunnel_key_init+0xb01/0x1b90 net/sched/act_tunnel_key.c:451 tcf_action_init_1+0x46b/0x6c0 net/sched/act_api.c:1428 tcf_action_init+0x448/0xa20 net/sched/act_api.c:1503 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] ================================================================== Fix by moving dst_release() into a custom RCU callback that runs after the grace period, matching the lifetime of the containing params struct. Readers in the datapath therefore always find a live rcuref when calling dst_clone(). Fixes: 9174c3df1cd18 ("net/sched: act_tunnel_key: fix memory leak in case of action replace") Reported-by: zdi-disclosures@trendmicro.com Tested-by: Victor Nogueira Signed-off-by: Jamal Hadi Salim Reviewed-by: Davide Caratti Link: https://patch.msgid.link/20260711150537.7946-1-jhs@mojatatu.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 51c2fcc4cd2e4c52bd1970558f6e5356fdc51154 Author: Ivan Vecera Date: Fri Jul 10 21:36:25 2026 +0200 dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() [ Upstream commit d2e914a4a0d0f753dbae830264850d044026167c ] When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device. Fixes: 58256a26bfb3 ("dpll: add reference sync get/set") Signed-off-by: Ivan Vecera Reviewed-by: Vadim Fedorenko Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20260710193625.1378822-1-ivecera@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e666af5dcc905ba694745963174d232deb478c55 Author: Eric Dumazet Date: Fri Jul 10 18:13:17 2026 +0000 tcp: fix TIME_WAIT socket reference leak on PSP policy failure [ Upstream commit 2c1931a81122c3cdc4c89448fe0442c69e21c0d5 ] Release the TIME_WAIT socket reference and jump to discard_it upon PSP policy failure in both IPv4 and IPv6 receive paths. This prevents a memory leak of tcp_tw_bucket structures. Fixes: 659a2899a57d ("tcp: add datapath logic for PSP with inline key exchange") Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Reviewed-by: Daniel Zahka Link: https://patch.msgid.link/20260710181317.4060230-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6875ee2bef48f5d9f045d81a8a4d68893f768a8a Author: Lizhi Hou Date: Thu Jul 16 08:13:05 2026 -0700 accel/amdxdna: Fix use-after-free of mm_struct in job scheduler [ Upstream commit faebb7ba1ac65fa5810b640df02ce04e509fdc11 ] amdxdna_cmd_submit() stores current->mm in job->mm without holding any reference. aie2_sched_job_run() later access job->mm from the DRM scheduler worker thread. With only a raw pointer and no structural reference, the mm_struct can be freed before the scheduler runs the job. Fix this by calling mmgrab() to hold a structural mm_count reference for the lifetime of the job, paired with mmdrop() in every cleanup path. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Max Zhen Signed-off-by: Lizhi Hou Link: https://patch.msgid.link/20260716151305.1595780-1-lizhi.hou@amd.com Signed-off-by: Sasha Levin commit f6b522033bc830d804a26aeaa5c800bfdf218876 Author: Emre Cecanpunar Date: Wed Jul 15 01:04:30 2026 +0300 drm/i915/selftests: Fix GT PM sort comparators [ Upstream commit 612978b83f45bf7018815209db5395d759db6f26 ] Compare the sampled clock values instead of their addresses. Comparing addresses leaves the samples unsorted, preventing the code from discarding the minimum and maximum samples. Fixes: 1a5392479207 ("drm/i915/selftests: Measure CS_TIMESTAMP") Signed-off-by: Emre Cecanpunar Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260714220430.238433-1-emreleno@gmail.com (cherry picked from commit 682ea2d28d18bb06f9fc663cb5ab7e80dc0e606a) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit c23abdb922c398601bdf6c8fc8b164582d97c60b Author: Vinod Govindapillai Date: Mon Jun 15 23:33:49 2026 +0300 drm/i915/wm: clear the plane ddb_y entries on plane disable [ Upstream commit e89978c1cff54e265345c66e1177d19ea5a8bc00 ] The UV/Y plane DDB entriess are never cleared on sk_wm_plane_disable_noatomic() and can leave stale DDB state for NV12 planes on pre-Gen11 devices Fixes: d34b59d5ba41 ("drm/i915: Add skl_wm_plane_disable_noatomic()") Assisted-by: Copilot:claude-sonnet-4.6 Signed-off-by: Vinod Govindapillai Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/20260615203355.218578-2-vinod.govindapillai@intel.com (cherry picked from commit 60f68a6ba298fd1e971a2d91576304bee89a16fc) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit f0e337e7db67cc1c832958bbb6c4026bdceacfdb Author: Xiang Mei (Microsoft) Date: Mon Jul 13 21:55:10 2026 +0000 ksmbd: validate compound request size before reading StructureSize2 [ Upstream commit 15b38176fd1530372905c602fde51fe89ec8c877 ] When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 6ecb252efa0b413ac3d9979fb4eec247f8fc1258 Author: Qihang Date: Thu Jul 9 22:49:55 2026 +0800 ksmbd: pin conn during async oplock break notification [ Upstream commit aa5d8f3f96aa11a4a54ce993c11ce8af11c546f9 ] smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern. Fixes: 3aa660c05924 ("ksmbd: prevent connection release during oplock break notification") Signed-off-by: Qihang Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 5e5f298d0af6416af87b2dbb0faff80141deb9a9 Author: Daniele Ceraolo Spurio Date: Mon Jul 13 15:17:59 2026 -0700 drm/xe/wopcm: fix WOPCM size for LNL+ [ Upstream commit ad87e2476b3b246580f407afc8ffa91d621bc849 ] Starting on LNL the WOPCM size is 8MB instead of 4, so we need to avoid using the [0, 8MB) range of the GGTT as that can be unaccessible from the microcontrollers. Note that the proper long-term fix here is to read the WOPCM size from the HW, but that is a more serious rework that would be difficult to backport, so we can do that as a follow-up. Fixes: 9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement") Signed-off-by: Daniele Ceraolo Spurio Cc: Rodrigo Vivi Cc: Shuicheng Lin Cc: Matt Roper Reviewed-by: Shuicheng Lin Link: https://patch.msgid.link/20260713221758.3285744-2-daniele.ceraolospurio@intel.com (cherry picked from commit 3033b0b24ed0e2f5e56bdd4d9c183417c365a45b) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 35ba43b541117bfb595e4b807ba447cf4335cc7d Author: Matthew Brost Date: Mon Jul 13 23:24:40 2026 -0700 drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves [ Upstream commit 56441f9e08ad68697295b8835266d2bc48ab59b5 ] xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO after it transitions NULL/SYSTEM -> TT, and detaches them after it transitions TT -> SYSTEM. Both operations were done synchronously on the CPU immediately after building the move's copy/clear fence, without waiting for that fence to signal. This creates two races with VF migration: - Attach happens too late relative to the copy job it is meant to protect. If the copy job is submitted before the CCS BBs are attached, a VF migration event that pauses execution mid-copy can observe partially copied CCS metadata without the attach state needed to correctly save/restore it. - Detach happens too early relative to the copy job that moves data out of TT. The CCS BBs are torn down right after the copy fence is obtained, while the actual blit may still be in flight. A VF migration event that pauses execution mid-copy can then race the save/restore path against the still-running blit, and the CCS BBs it would need to make sense of the paused state have already been removed. Fix both races: - Move the attach call to before the copy/clear job is submitted, so the CCS BBs are already registered by the time the copy runs. On attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy() now takes the destination resource explicitly, since bo->ttm.resource is not updated to the new resource until after the move commits. - Detach only after explicitly waiting for the copy fence to signal, instead of tearing down the CCS BBs immediately after obtaining it. While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and propagate errors: the per-context loop previously never broke out on error, silently discarding earlier failures. Unwind by clearing each attached context directly via xe_migrate_ccs_rw_copy_clear() instead of reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be attached before it will clean up either one. Fixes: 864690cf4dd6 ("drm/xe/vf: Attach and detach CCS copy commands with BO") Cc: Michal Wajdeczko Cc: Matthew Auld Cc: Michał Winiarski Cc: Satyanarayana K V P Assisted-by: GitHub_Copilot:claude-sonnet-5 Signed-off-by: Matthew Brost Acked-by: Satyanarayana K V P Reviewed-by: Matthew Auld Link: https://patch.msgid.link/20260714062440.3421225-1-matthew.brost@intel.com (cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit c1b19d8556265f6098f68855d48e1a40d5d69f7f Author: Satyanarayana K V P Date: Tue Nov 18 12:07:45 2025 +0000 drm/xe/vf: Shadow buffer management for CCS read/write operations [ Upstream commit fa18290bf0723b02bfa8d30d2e14722f0d096c2c ] CCS copy command consist of 5-dword sequence. If vCPU halts during save/restore operations while these sequences are being programmed, incomplete writes can cause page faults during IGPU CCS metadata saving. Use shadow buffer management to prevent partial write issues during CCS operations. Signed-off-by: Satyanarayana K V P Suggested-by: Matthew Brost Cc: Michal Wajdeczko Cc: Matthew Auld Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20251118120745.3460172-3-satyanarayana.k.v.p@intel.com Stable-dep-of: 56441f9e08ad ("drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves") Signed-off-by: Sasha Levin commit bf293b5bcff41217dacc86b9aea96fa7bd20447e Author: Satyanarayana K V P Date: Tue Nov 18 12:07:44 2025 +0000 drm/xe/sa: Shadow buffer support in the sub-allocator pool [ Upstream commit 1f2cf5295cdba71818288c9e495b4ef5097565ed ] The existing sub-allocator is limited to managing a single buffer object. This enhancement introduces shadow buffer functionality to support scenarios requiring dual buffer management. The changes include added shadow buffer object creation capability, Management for both primary and shadow buffers, and appropriate locking mechanisms for thread-safe operations. This enables more flexible buffer allocation strategies in scenarios where shadow buffering is required. Signed-off-by: Satyanarayana K V P Suggested-by: Matthew Brost Cc: Michal Wajdeczko Cc: Matthew Auld Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20251118120745.3460172-2-satyanarayana.k.v.p@intel.com Stable-dep-of: 56441f9e08ad ("drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves") Signed-off-by: Sasha Levin commit 65129a03a80185e8b34b55d0a1d27d62130223ab Author: Michał Winiarski Date: Wed Nov 12 14:22:07 2025 +0100 drm/xe: Allow the caller to pass guc_buf_cache size [ Upstream commit dca2701a6277399f9d255f09b4c34d9a7171c09b ] An upcoming change will use GuC buffer cache as a place where GuC migration data will be stored, and the memory requirement for that is larger than indirect data. Allow the caller to pass the size based on the intended usecase. Reviewed-by: Michal Wajdeczko Link: https://patch.msgid.link/20251112132220.516975-12-michal.winiarski@intel.com Signed-off-by: Michał Winiarski Stable-dep-of: 56441f9e08ad ("drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves") Signed-off-by: Sasha Levin commit cfb66ad4aa8e584abe02998560c274cbb3795776 Author: Shuhao Fu Date: Thu May 7 10:22:26 2026 +0200 can: j1939: fix lockless local-destination check [ Upstream commit e4e8af62adab2fdcca230006f829407a953070cd ] j1939_priv.ents[].nusers is documented as protected by priv->lock, and its updates already happen under that lock. j1939_can_recv() also reads it under read_lock_bh(). However, j1939_session_skb_queue() and j1939_tp_send() still read priv->ents[da].nusers without taking the lock. Those transport-side checks decide whether to set J1939_ECU_LOCAL_DST, so they can race with j1939_local_ecu_get() and j1939_local_ecu_put() while userspace is binding or releasing sockets concurrently with TP traffic. This can misclassify TP/ETP sessions as local or remote and take the wrong transport path. Fix both transport paths by routing the destination-locality check through a helper that reads ents[].nusers under read_lock_bh(&priv->lock). Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Shuhao Fu Tested-by: Oleksij Rempel Acked-by: Oleksij Rempel Link: https://patch.msgid.link/20260419140614.GA4041240@chcpu16 Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 3f398d45f3c75a4bf424339843bb2db18da9d8f4 Author: Mark Harris Date: Mon Jul 13 17:30:56 2026 -0700 riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus() [ Upstream commit 5caae1deee89a6582c761d5dcd4b924b744426cc ] When cpusetsize < cpumask_size(), hwprobe_get_cpus() did not fully initialize its copy of the cpu mask, which could cause non-deterministic results from the riscv_hwprobe syscall on a system with more than 8 CPUs when the supplied cpu mask is empty. Address this by fully initializing the cpu mask. Fixes: e178bf146e4b ("RISC-V: hwprobe: Introduce which-cpus flag") Signed-off-by: Mark Harris Reviewed-by: Nam Cao Reviewed-by: Michael Ellerman Link: https://patch.msgid.link/20260714003056.73707-1-mark.hsj@gmail.com Signed-off-by: Paul Walmsley Signed-off-by: Sasha Levin commit 1d9a2f01b3c4e5c88e06b2db4b5460c2ec884722 Author: Vasily Gorbik Date: Wed Jul 8 12:02:14 2026 +0200 s390/checksum: Fix csum_partial() without vector facility [ Upstream commit 4bb06b60d982355e22647b3d12d6619419f8c1fa ] Currently csum_partial() calls csum_copy() with copy=false and dst=NULL. On machines without the vector facility, csum_copy() falls back to cksm(dst, ...), causing the checksum to be calculated from address zero instead of the source buffer. The VX implementation already checksums data loaded from src. Make the fallback do the same by passing src to cksm(). Fixes: dcd3e1de9d17 ("s390/checksum: provide csum_partial_copy_nocheck()") Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 5b06cf93341fe17fc16a01036ac7e25496e8048c Author: Linmao Li Date: Mon Jul 13 16:29:12 2026 +0800 drm/panthor: Check debugfs GEM lock initialization [ Upstream commit 022e901333c3054656a640794e842bab7af5a75c ] drmm_mutex_init() can fail while registering the managed cleanup action. When that happens, drmm_add_action_or_reset() destroys the mutex before returning the error. Continuing initialization would therefore leave the debugfs GEM object list with an unusable lock. Propagate the error as is already done for the other managed mutexes in panthor_device_init(). Fixes: a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS") Signed-off-by: Linmao Li Reviewed-by: Liviu Dudau Link: https://patch.msgid.link/20260713082912.321021-1-lilinmao@kylinos.cn Signed-off-by: Liviu Dudau Signed-off-by: Sasha Levin commit 250474c69bc3fc48a5fc21d7c349f279caad947a Author: Michal Luczaj Date: Tue Jul 7 06:23:57 2026 +0200 bpf, sockmap: Reject unhashed UDP sockets on sockmap update [ Upstream commit 66efd3368ae10d05e08fbe6425b50fdec7186ac7 ] UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm "test_progs", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff ("bpf, sockmap: Remove unhash handler for BPF sockmap usage"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 ("bpf: reject unhashed sockets in bpf_sk_assign"). Fixes: 0c48eefae712 ("sock_map: Lift socket state restriction for datagram sockets") Suggested-by: Kuniyuki Iwashima Signed-off-by: Michal Luczaj Reviewed-by: Kuniyuki Iwashima Reviewed-by: Jakub Sitnicki Reviewed-by: John Fastabend Link: https://lore.kernel.org/bpf/20260707-sockmap-lookup-udp-leak-v4-2-f878346f27ab@rbox.co Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Sasha Levin commit c3e61df6fabca9eb092c76994a6006c45741c231 Author: Shrikanth Hegde Date: Fri Jun 5 18:13:29 2026 +0530 powerpc/vtime: Initialize starttime at boot for native accounting [ Upstream commit c1c1ffa490fc33591e90852ed0d38804dd20bc36 ] It was observed that /proc/stat had very large value for one ore more CPUs. It was more visible after recent code simplifications around cpustats. System has 240 CPUs. cat /proc/uptime; 194.18 46500.55 cat /proc/stat cpu 5966 39 837032887 4650070 164 185 100 0 0 0 cpu0 108 0 837030890 19109 24 4 23 0 0 0 Since uptime is 194s, system time of each CPU can't be more than 19400. Sum of system time of all CPUs can't be more than 19400*240 4656000. In fact huge value is close to mftb(). Note mftb doesn't reset on powerVM when the LPAR restart. It only resets when whole system resets. The same issue exists for kexec too. This happens since starttime is not setup at init time. Once it is set then subsequent vtime_delta will return the right delta. Fix it by initializing the starttime during CPU initialization. This fixes the large times seen. cat /proc/uptime; cat /proc/stat 15.78 3694.63 cpu 6035 35 1347 369479 23 144 49 0 0 0 cpu0 19 0 38 1508 0 1 14 0 0 0 Now, system time is reported as expected. Fixes: cf9efce0ce31 ("powerpc: Account time using timebase rather than PURR") Reviewed-by: Christophe Leroy (CS GROUP) Suggested-by: Christophe Leroy (CS GROUP) Signed-off-by: Shrikanth Hegde Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260605124329.377533-1-sshegde@linux.ibm.com Signed-off-by: Sasha Levin commit 5c3a1cede86fdcc6e7c45176f26cd1eb990e6703 Author: Frederic Weisbecker Date: Fri May 8 15:16:37 2026 +0200 powerpc/time: Prepare to stop elapsing in dynticks-idle [ Upstream commit c8ba971cf8567d49eb5f43ee90c4e50424331c18 ] Currently the tick subsystem stores the idle cputime accounting in private fields, allowing cohabitation with architecture idle vtime accounting. The former is fetched on online CPUs, the latter on offline CPUs. For consolidation purpose, architecture vtime accounting will continue to account the cputime but will make a break when the idle tick is stopped. The dyntick cputime accounting will then be relayed by the tick subsystem so that the idle cputime is still seen advancing coherently even when the tick isn't there to flush the idle vtime. Prepare for that and introduce three new APIs which will be used in subsequent patches: - vtime_dynticks_start() is deemed to be called when idle enters in dyntick mode. The idle cputime that elapsed so far is accumulated. - vtime_dynticks_stop() is deemed to be called when idle exits from dyntick mode. The vtime entry clocks are fast-forward to current time so that idle accounting restarts elapsing from now. - vtime_reset() is deemed to be called from dynticks idle IRQ entry to fast-forward the clock to current time so that the IRQ time is still accounted by vtime while nohz cputime is paused. Also accumulated vtime won't be flushed from dyntick-idle ticks to avoid accounting twice the idle cputime, along with nohz accounting. Signed-off-by: Frederic Weisbecker Signed-off-by: Thomas Gleixner Tested-by: Shrikanth Hegde Reviewed-by: Shrikanth Hegde Link: https://patch.msgid.link/20260508131647.43868-6-frederic@kernel.org Stable-dep-of: c1c1ffa490fc ("powerpc/vtime: Initialize starttime at boot for native accounting") Signed-off-by: Sasha Levin commit c1bbd0a6906b8d06f1f28a5e1b6d243c81c1f8fa Author: Rosen Penev Date: Wed Jun 3 21:33:09 2026 -0700 powerpc/85xx: Add fsl,ifc to common device ids [ Upstream commit 25957f7c3dac3265332d766b71233e3622f17e14 ] Add fsl,ifc to mpc85xx_common_ids so that of_platform_bus_probe creates a platform device for the IFC node even without 'simple-bus' in its compatible property. On P1010 and similar platforms the IFC node is a direct child of the root, so it must be explicitly matched to be populated. Fixes: 0bf51cc9e9e5 ("powerpc: dts: mpc85xx: remove "simple-bus" compatible from ifc node") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Madhavan Srinivasan Link: https://patch.msgid.link/20260604043309.91280-1-rosenp@gmail.com Signed-off-by: Sasha Levin commit 00ba4bf8798242253fefc1fa6a78db1d445fd024 Author: Oliver Hartkopp Date: Thu May 7 10:22:23 2026 +0200 can: raw: add locking for raw flags bitfield [ Upstream commit 1e5185c090589f4146d728ab36417d8a5419f127 ] With commit 890e5198a6e5 ("can: raw: use bitfields to store flags in struct raw_sock") the formerly separate integer values have been integrated into a single bitfield. This led to a read-modify-write operation when changing a flag in raw_setsockopt() which now needs a locking to prevent concurrent access. Instead of adding a lock/unlock hell in each of the flag manipulations this patch introduces a wrapper for a new raw_setsockopt_locked() function analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c Fixes: 890e5198a6e5 ("can: raw: use bitfields to store flags in struct raw_sock") Reported-by: Eulgyu Kim Closes: https://lore.kernel.org/linux-can/20260503112200.22727-1-eulgyukim@snu.ac.kr/ Tested-by: Eulgyu Kim Signed-off-by: Oliver Hartkopp Reviewed-by: Vincent Mailhol Tested-by: Vincent Mailhol Link: https://patch.msgid.link/20260504111928.41856-1-socketcan@hartkopp.net [mkl: use Closes tag instead of Link] Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 479425744b21927a5e5e82a2fac8cd604f2aba5d Author: Pengpeng Hou Date: Sun Jul 5 16:02:25 2026 +0800 drm/i915/gt: use correct selftest config symbol [ Upstream commit a82f1bb8191aec98a971a2196136016ef70c0880 ] intel_engine_user.c checks CONFIG_DRM_I915_SELFTESTS before running the engine UABI isolation check. Kconfig defines DRM_I915_SELFTEST, without the trailing "S", and the rest of i915 uses CONFIG_DRM_I915_SELFTEST. Because CONFIG_DRM_I915_SELFTESTS is not backed by any Kconfig symbol, the IS_ENABLED() test is always false. Use the existing selftest symbol so the debug/selftest guarded path can be reached when selftests are enabled. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the Kconfig definition and the inconsistent guard in intel_engine_user.c. Fixes: 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT") Signed-off-by: Pengpeng Hou Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260705080225.436-1-pengpeng@iscas.ac.cn (cherry picked from commit 14a2012a490258f3f93857bc4f1b203405964be7) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 7e08ab7a061b17ac1989a225c6afb53f44a86808 Author: Huiwen He Date: Fri Jul 3 13:32:56 2026 +0800 smb/client: handle overlapping allocated ranges in fallocate [ Upstream commit b09ae45d85dc816987a71db9eebc54b0ae288e94 ] smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read. Fixes: 966a3cb7c7db ("cifs: improve fallocate emulation") Signed-off-by: Huiwen He Reviewed-by: ChenXiaoSong Signed-off-by: Steve French Signed-off-by: Sasha Levin commit cefb44c367b2b52e50f97bc8526d39df9bcf5e60 Author: Ruoyu Wang Date: Thu Jul 9 14:22:50 2026 +0800 Bluetooth: hci_qca: Clear memdump state on invalid dump size [ Upstream commit bf587a10c33e5571a299742e45bc18960b9912e7 ] qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path. Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support") Signed-off-by: Ruoyu Wang Reviewed-by: Paul Menzel Reviewed-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d5b3b484b62bb0f4542e7622789d28871626cdf0 Author: Pauli Virtanen Date: Fri Jul 10 11:23:42 2026 +0300 Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds [ Upstream commit da55f570191d5d72f10c607a7043b947eb05ea46 ] Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race. Fixes: 7b445e220db9 ("Bluetooth: MGMT: Fix holding hci_conn reference while command is queued") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ca58ad287bfc5b9d31a72ecb8650289df2b57250 Author: Pauli Virtanen Date: Fri Jul 10 11:23:41 2026 +0300 Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync [ Upstream commit 16cd66443957e4ad42155c6fec401012f600c6f8 ] Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point. Fixes: 227a0cdf4a028 ("Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 83b7e67698d0b93f685875ce82c8d335436834f7 Author: Pauli Virtanen Date: Fri Jul 10 11:23:40 2026 +0300 Bluetooth: hci_sync: extend conn_hash lookup critical sections [ Upstream commit d5efd6e4b8b0634af6843178fe1a7dd2b2178a3d ] Using RCU-protected pointers outside the critical sections without refcount is incorrect and may result to UAF. Extend critical section to cover both hci_conn_hash lookup and use of the returned conn. Add surrounding rcu_read_lock() also when return value is not used, in preparation for RCU lockdep requirement to hci_lookup_le_connect(). This avoids concurrent deletion of the conn before we are done dereferencing it. Also, make sure to hold hdev->lock when accessing hdev->accept_list. Fixes: 6d0417e4e1cf ("Bluetooth: hci_conn: Fix not setting conn_timeout for Broadcast Receiver") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 57059ff14d81df4a970b2ea8d8f54431bb91a025 Author: Cen Zhang Date: Tue Jul 7 12:15:18 2026 +0800 Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update [ Upstream commit 2bf282f8f715f5d05d6f4c49ffb3bd241c5e667e ] MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter update changes an existing LE central connection. The queued work currently stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later LOAD_CONN_PARAM request can clear disabled parameters and free that entry before hci_cmd_sync_work() runs the queued callback. Do not keep the borrowed hci_conn_params pointer in queued work. Queue the hci_conn instead and hold a reference until the queued callback completes. When the work runs, revalidate that the connection is still present, look up the current hci_conn_params entry, and cancel the update if userspace removed that entry while the work was pending. Copy the interval values from the current params entry under hdev->lock, then drop the lock and keep using hci_le_conn_update_sync() to issue the update. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth] Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 kasan_report+0xe0/0x110 conn_update_sync+0x2a/0xf0 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30 Allocated by task 466: hci_conn_params_add+0xa6/0x240 [bluetooth] load_conn_param+0x4e1/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Freed by task 474: kfree+0x313/0x590 hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth] load_conn_param+0x4bf/0x850 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] Fixes: 0ece498c27d8c ("Bluetooth: MGMT: Make MGMT_OP_LOAD_CONN_PARAM update existing connection") Suggested-by: Luiz Augusto von Dentz Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a087ed960fce54e9302796229e9d545bbc9bcd4a Author: Xiang Mei Date: Sat Jul 4 16:10:30 2026 -0700 Bluetooth: qca: fix NVM tag length underflow in TLV parser [ Upstream commit c90164ca0f7036942ba088eb7ea8d3f6c2352020 ] In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is "while (idx < length - sizeof(struct tlv_type_nvm))". "length" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so "length" is converted to size_t and any firmware-supplied "length" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as "idx + sizeof(struct tlv_type_nvm) <= length"; both operands are non-negative, so it no longer underflows and a "length" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Fixes: 2e4edfa1e2bd ("Bluetooth: qca: add missing firmware sanity checks") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Reported-by: Weiming Shi Reviewed-by: Johan Hovold Acked-by: Bartosz Golaszewski Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f4e23e661a259975d1c5ddbc40df9521ad33a540 Author: Takashi Iwai Date: Thu Jul 9 11:56:06 2026 +0200 ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC [ Upstream commit 93b47e66cc6d6c6382d44b44f5e7f6fc3a7b38c3 ] Salvador reported that the recent fix for applying the DSD quirk to Musical Fidelity devices broke for his M6s DAC model (2772:0502). Although this is basically a firmware bug, the model in question is fairly old, and no further firmware update can be expected, so it'd be better to address in the driver side. As an ad hoc workaround, skip the DSD quirk for this device by adding an empty quirk entry of 2772:0502; this essentially skips the later DSD quirk entry by the match with the vendor 2772. Fixes: da3a7efff64e ("ALSA: usb-audio: Update for native DSD support quirks") Reported-by: Salvador Blaya Closes: https://lore.kernel.org/CAOdyq+qFaqCh=tK_wNnA64hv5pQuA1Y09ANxQ=xK8yR-t4mf9Q@mail.gmail.com Tested-by: Salvador Blaya Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20260709095614.1418838-1-tiwai@suse.de Signed-off-by: Sasha Levin commit b133f007ba02ce7f4d4972108e62c91d4e6232b9 Author: Karol Wachowski Date: Fri Jul 10 12:13:31 2026 +0200 accel/ivpu: Fix wrong register read in LNL failure diagnostics [ Upstream commit e4159045c2704dfe146f0ccb0445d9d074cd6882 ] diagnose_failure_lnl() read VPU_HW_BTRS_MTL_INTERRUPT_STAT instead of VPU_HW_BTRS_LNL_INTERRUPT_STAT, which on LNL and newer parts is a different register with a different bit layout, so failure diagnostics decoded the wrong register and reported a bogus error cause. Read the LNL interrupt status register instead. Fixes: 8a27ad81f7d3 ("accel/ivpu: Split IP and buttress code") Reviewed-by: Andrzej Kacprowski Signed-off-by: Karol Wachowski Link: https://patch.msgid.link/20260710101331.1899505-1-karol.wachowski@linux.intel.com Signed-off-by: Sasha Levin commit 1842d45f461a78988254631893329bdf4596e954 Author: Rosen Penev Date: Sun Jul 12 14:37:28 2026 -0700 ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning [ Upstream commit c2130f6553f4a5cbdc259de069600117a995f197 ] The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument. Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit d28920db56960115985fed43b5aec90f74cc56c2 Author: Rosen Penev Date: Sun Jul 12 14:37:27 2026 -0700 ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending interrupts [ Upstream commit 66c4e310ad71f41e41736d33dd8a1fb5eaaec7f3 ] clear_interrupt_bit() ignores the bit argument and performs a read-write-back of the entire INTPR register. If INTPR uses standard Write-1-to-Clear semantics, this clears every pending interrupt bit, not just the intended one. Coalesced interrupts (e.g. DMAT + NEWFP) would be cleared together, silently losing the second event. Write only the specific bit to clear so that other pending interrupts are preserved. Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 678d874e6ae1134e3cc78b4de8cb745e42ca417a Author: Rosen Penev Date: Sun Jul 12 14:37:25 2026 -0700 ata: sata_dwc_460ex: use platform_get_irq() [ Upstream commit a4af122106f73ea510bb35a9ea1dedd980fc0db7 ] Replace irq_of_parse_and_map() with platform_get_irq() in both sata_dwc_dma_init_old() and sata_dwc_probe(). This is the preferred way to obtain IRQs for platform devices and provides better error reporting. Remove the now-unnecessary #include . irq_of_parse_and_map() requires irq_dispose_mapping(), which is missing. Also fix unused variable when CONFIG_SATA_DWC_OLD_DMA is disabled. Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit daa80b422ed920a3c0c45153020b0ad7af7fb5a5 Author: Rosen Penev Date: Sun Jul 12 14:37:26 2026 -0700 ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered [ Upstream commit 4bbc16a353a98023e5ddfca7c1fc0e49971cf4d0 ] sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized. Fixes: 62936009f35a ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit c7a15091237205770bd9bd4d14eb1f3029d97a34 Author: David Jeffery Date: Mon Jun 15 13:46:30 2026 -0400 scsi: core: wake eh reliably when using scsi_schedule_eh [ Upstream commit dccf3b1798b70f94e958b3d00b83010399e6fb05 ] Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers. Fixes: 6eb045e092ef ("scsi: core: avoid host-wide host_busy counter for scsi_mq") Signed-off-by: David Jeffery Link: https://patch.msgid.link/20260615174630.11492-1-djeffery@redhat.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2c77ed279c4bb58f3e63579659c46f09356a4124 Author: Robert Mader Date: Sat Jun 27 12:57:25 2026 +0200 udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf() [ Upstream commit 1d0e25c1ddf2063c499264fb2ba0fa6a3e4f8a00 ] The message of commit 504e2b4ab97a ("dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning") says: > The CPU sync at map/unmap time is also redundant for udmabuf: > begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit > cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU > access is requested through the dma-buf interface. This, however, does not apply to the first time begin_cpu_udmabuf() is called on an udmabuf, in which case the implementation previously relied on get_sg_table() to perform the cache synchronisation. Ensure to call dma_sync_sgtable_for_cpu() in that case as well. Fixes: 504e2b4ab97a ("dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning") Signed-off-by: Robert Mader Reviewed-by: Mikhail Gavrilov Signed-off-by: Vivek Kasireddy Link: https://patch.msgid.link/20260627105725.9083-1-robert.mader@collabora.com Signed-off-by: Sasha Levin commit c75a950e77356e526672cba4584080c6c8b793b6 Author: Bryam Vargas Date: Sun Jul 5 22:24:36 2026 -0500 net/iucv: take a reference on the socket found in afiucv_hs_rcv() [ Upstream commit 4fa349156043dc119721d067329714179f501749 ] afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run. Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport") Signed-off-by: Bryam Vargas Reviewed-by: Hidayath Khan Link: https://patch.msgid.link/20260705-b4-disp-fc79c0dc-v1-1-d2cdcb57afa9@proton.me Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit cb8be318b4432abd88d3172ec157330f27a5f7a7 Author: Weiming Shi Date: Sat Jul 4 10:14:21 2026 -0700 ipv4: fib: free fib_alias with kfree_rcu() on insert error path [ Upstream commit f2f152e94a67bc746afaf05a1b2702c195553112 ] fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie. Fixes: a6c76c17df02 ("ipv4: Notify route after insertion to the routing table") Reported-by: Xiang Mei Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260704171421.1786806-1-bestswngs@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c9574b8a8edeb4edd3ac6472c27ef7184bdb2baa Author: Norbert Szetei Date: Mon Jul 6 11:01:59 2026 +0200 ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF [ Upstream commit ec4215683e47424c9c4762fd3c60f552a3119142 ] pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path. Fixes: ee40fb2e1eb5 ("l2tp: protect sock pointer of struct pppol2tp_session with RCU") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Norbert Szetei Reviewed-by: Qingfang Deng Link: https://patch.msgid.link/E793FCF2-58DE-4387-A983-C7B4BC3158BD@doyensec.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 88f87cb4b52ed7a1595fd3420d0d9c236ce40824 Author: Rafael J. Wysocki Date: Tue Jul 7 19:25:39 2026 +0200 cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq [ Upstream commit d2d5c129d07ea8eb91cd8a8633b5774116c4d171 ] If arch_scale_freq_ref() is not defined for a given arch (like x86, for example), cpufreq_update_pressure() will always set cpufreq_pressure to zero for all CPUs in the system, which is generally problematic on systems with asymmetric capacity [1]. However, in the absence of arch_scale_freq_ref(), it is reasonable to assume that cpuinfo.max_freq is the maximum sustainable frequency for the given cpufreq policy. Moreover, there are cases in which arch_scale_freq_ref() would need to be defined to return essentially the cpuinfo.max_freq value anyway (for example, intel_pstate on hybrid platforms). For the above reasons, update cpufreq_update_pressure() to fall back to using cpuinfo.max_freq as the reference frequency if zero is returned by arch_scale_freq_ref(). Fixes: 75d659317bb1 ("cpufreq: Add a cpufreq pressure feedback for the scheduler") Link: https://lore.kernel.org/lkml/CAKfTPtBuRLfYNnR4w--cFZYZy-R8gaPEgVwCcaMmbCcJ2H-muQ@mail.gmail.com/ [1] Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar Reviewed-by: Zhongqiu Han Tested-by: Ricardo Neri # cluster scheduling Acked-by: Vincent Guittot Link: https://patch.msgid.link/5086499.GXAFRqVoOG@rafael.j.wysocki Signed-off-by: Sasha Levin commit 640a33e77f91bb72125a662376d824adcc6b15e0 Author: Pushpendra Singh Date: Wed Jul 8 12:53:39 2026 +0530 firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context [ Upstream commit a4447c0693830d5ecadd6e755cb7fdc55d86aacc ] The scmi_notify() function is called from interrupt context to queue received notification events onto a per-protocol kfifo. When the kfifo is full, it logs a warning via dev_warn() for every dropped event. Under conditions where the platform sends a burst of SCMI notifications faster than the deferred worker can drain the queue, this results in a flood of dev_warn() calls from IRQ context. Each call acquires the console lock and may execute blocking console writes, causing the CPU to be held in interrupt context for an extended period and leading to observable system stalls. Fix this by switching to dev_warn_ratelimited() to limit the frequency of log messages when the notification queue is full. This reduces console overhead in interrupt context and prevents CPU stalls caused by excessive logging, while still preserving diagnostic visibility. Fixes: bd31b249692e ("firmware: arm_scmi: Add notification dispatch and delivery") Signed-off-by: Pushpendra Singh Link: https://patch.msgid.link/20260708072339.3021140-1-pushpendra.singh@oss.qualcomm.com Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit fb343716fad469bdbdbde2a923baa72a124e4250 Author: Uday Khare Date: Mon Jul 6 21:01:09 2026 +0530 ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after lookup [ Upstream commit 3238c634725afbb2a137fdda762208510828f71d ] In tas2562_parse_dt(), the fallback lookup for the deprecated "shut-down" GPIO property is broken due to a missing pair of braces. The code intends to reset sdz_gpio to NULL only when the lookup returns an error that is not -EPROBE_DEFER (so the driver gracefully continues without a GPIO). However, without braces the statement: tas2562->sdz_gpio = NULL; falls outside the IS_ERR() check and is executed unconditionally for every path through the if block, including a successful GPIO lookup. This means any device using the deprecated 'shut-down' DT property will always have sdz_gpio == NULL after probe, making the GPIO completely non-functional. Fix this by adding the missing braces to scope the NULL assignment inside the IS_ERR() branch, matching the pattern already used for the primary 'shutdown' GPIO lookup above. Fixes: f78a97003b8b ("ASoC: tas2562: Update shutdown GPIO property") Signed-off-by: Uday Khare Link: https://patch.msgid.link/20260706153109.10953-1-udaykhare77@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7f2cb99eaf53c5f88931a3001b252301633a582e Author: Charles Keepax Date: Wed Jul 8 11:34:30 2026 +0100 ASoC: cs42l43: Correct report for forced microphone jack [ Upstream commit f74e6e15485b68b92b2807071e822db6309b7e38 ] Currently if the jack is forced to the microphone mode, it will report as line in. Correct the report to microphone. Fixes: fc918cbe874e ("ASoC: cs42l43: Add support for the cs42l43") Signed-off-by: Charles Keepax Link: https://patch.msgid.link/20260708103430.1395207-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9f393d8160435a303db4aec7685c9aeff9b1aa94 Author: Vijendar Mukunda Date: Tue Jul 7 11:29:38 2026 +0530 ASoC: amd: ps: replace bitwise OR with logical OR in IRQ return check [ Upstream commit dec5aaa27603e1d7b426ce3504af6d1a62e4d444 ] The condition 'irq_flag | wake_irq_flag' uses bitwise OR to combine two integer flags that are used as booleans. Replace with logical OR '||' to correctly express the intended boolean check. Signed-off-by: Vijendar Mukunda Reviewed-by: Mario Limonciello (AMD) Fixes: 7f91f012c1df0 ("ASoC: amd: ps: fix for irq handler return status") Link: https://patch.msgid.link/20260707060130.2514138-4-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3b2d32f528152037d15d0afd1b654af0058ab7d8 Author: Vijendar Mukunda Date: Tue Jul 7 11:29:37 2026 +0530 ASoC: amd: ps: fix wrong ACP version string in pci_request_regions() [ Upstream commit f7697ecf6eab9d4887dd731038b3dc405c7e755e ] The driver handles ACP6.3/7.0/7.1/7.2 platforms but the region was claimed with the stale name "AMD ACP6.2 audio" left over from the original ACP6.2 driver. Correct it to "AMD ACP6.3 audio". Fixes: 95e43a170bb1 ("ASoC: amd: add Pink Sardine ACP PCI driver") Signed-off-by: Vijendar Mukunda Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260707060130.2514138-3-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f33ad19e3e3d63c0d43b8be96754aae156c8c5af Author: Vijendar Mukunda Date: Tue Jul 7 11:29:36 2026 +0530 ASoC: amd: ps: disable MSI on resume in ACP PCI driver [ Upstream commit 5893013efabb056399a01e267f410cf76eba25eb ] BIOS/firmware may re-enable MSI in PCI config space during system level resume even though this driver only uses legacy INTx interrupts. If MSI is left enabled with stale address/data registers, the device will write interrupts to a bogus address causing IOMMU IO_PAGE_FAULT and interrupt delivery failure. Clear the MSI Enable bit before reinitializing the ACP hardware on system level resume. Fixes: 491628388005 ("ASoC: amd: ps: add callback functions for acp pci driver pm ops") Signed-off-by: Vijendar Mukunda Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/20260707060130.2514138-2-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4801f6690f9846e7ffde8c694c3b4b305ebefbf7 Author: Christian Hewitt Date: Sat Jun 27 13:12:05 2026 +0000 ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop [ Upstream commit 6b59c53c8adc2b522327407af5e1793a65b67e4b ] The I2S FIFO soft-resets its fast domain on start (AIU_RST_SOFT bit 0 + AIU_I2S_SYNC read in aiu_fifo_i2s_trigger), mirroring the downstream vendor driver's audio_out_i2s_enable(). The S/PDIF FIFO has no equivalent: it only toggles the IEC958 DCU, so a stale datapath FIFO can be replayed, producing the "machine gun noise" buffer underrun - on start when switching outputs, and on stop when playback ends. The latter is audible on devices with an always-on S/PDIF-fed DAC (e.g. the ES7144 on the WeTek Play2). The vendor driver resets the IEC958 fast domain (AIU_RST_SOFT bit 2) on both enable and disable (audio_hw_958_enable), and when reconfiguring (audio_hw_958_reset clears AIU_958_DCU_FF_CTRL then resets). Do the same: reset before enabling the DCU on start, and before disabling on stop. Fixes: 6ae9ca9ce986bf ("ASoC: meson: aiu: add i2s and spdif support") Signed-off-by: Christian Hewitt Reviewed-by: Martin Blumenstingl Link: https://patch.msgid.link/20260627131205.808800-1-christianshewitt@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b39b08e6bee812514b449dc874076890e6b871a0 Author: Sebastian Ene Date: Thu Jul 2 10:38:39 2026 +0000 firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation [ Upstream commit b4d961351aa84fdf0148783fb1f3a1391b8a0adb ] Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint memory access array and to comply with the FF-A spec instead of defaulting to `sizeof(struct ffa_mem_region)`. This requires moving `ffa_mem_region_additional_setup()` earlier in the setup flow. Also, add sanity checks to ensure the calculated descriptor offsets do not exceed `max_fragsize`. Fixes: 113580530ee7 ("firmware: arm_ffa: Update memory descriptor to support v1.1 format") Reviewed-by: Sudeep Holla Signed-off-by: Mostafa Saleh Signed-off-by: Sebastian Ene Link: https://patch.msgid.link/20260702103848.1647249-3-sebastianene@google.com Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit cf5708c9d78c98214c62b1e5d049cd527a543b8e Author: Mostafa Saleh Date: Thu Jul 2 10:38:38 2026 +0000 firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() [ Upstream commit 3383ffb7ef937317361713ffcc21921a7848511a ] Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case while reserved has an offset of 24. Instead of zeroing fields, memset the struct to zero first based on the FFA version. 2) Make sure there is enough size to write constituents. While at it, convert the only sizeof() in the driver that uses a type instead of variable. Reviewed-by: Sudeep Holla Fixes: 111a833dc5cb ("firmware: arm_ffa: Set reserved/MBZ fields to zero in the memory descriptors") Signed-off-by: Mostafa Saleh Signed-off-by: Sebastian Ene Link: https://patch.msgid.link/20260702103848.1647249-2-sebastianene@google.com Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 11ac7a5e75f5132f1778e0c60981d30dc29fb869 Author: HE WEI (ギカク) Date: Tue Jul 7 18:48:28 2026 +0900 wifi: cfg80211: bound element ID read when checking non-inheritance [ Upstream commit cb8afea4655ff004fa7feee825d5c79783525383 ] cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN. Fixes: f7dacfb11475 ("cfg80211: support non-inheritance element") Signed-off-by: HE WEI (ギカク) Link: https://patch.msgid.link/20260707094828.16465-1-skyexpoc@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5c342437ea44bb829680ca9e4f683dd5b325b219 Author: Runyu Xiao Date: Fri Jun 19 14:44:01 2026 +0800 wifi: brcmfmac: initialize SDIO data work before cleanup [ Upstream commit 2a665946e0407a05a3f81bd56a08553c446498e0 ] brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack. Fixes: 9982464379e8 ("brcmfmac: make sdio suspend wait for threads to freeze") Signed-off-by: Runyu Xiao Acked-by: Arend van Spriel Link: https://patch.msgid.link/20260619064401.1048976-1-runyu.xiao@seu.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a424985c3ef2a87ce6057a853e18d0c441a86be8 Author: Cen Zhang Date: Mon Jul 6 22:08:41 2026 +0800 wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock [ Upstream commit f3858d5b1432098c1936e03d6e03dd0e33facf60 ] ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip Fixes: 397a7a24ef8c ("mac80211: free ps->bc_buf skbs on vlan device stop") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Link: https://patch.msgid.link/20260706140841.581566-1-zzzccc427@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 44eda4a8d1dcda72d357d97311a96b4f01fc83f6 Author: Zhao Li Date: Fri Jun 12 23:24:41 2026 +0800 wifi: mac80211: avoid non-S1G AID fallback for S1G assoc [ Upstream commit 035ed430ce6a2c35b01e211844a9f0a7643e57a4 ] When assoc_data->s1g is set and no AID Response element is present, falling back to mgmt->u.assoc_resp.aid reads the non-S1G association-response layout. Keep the fallback for non-S1G only. If a successful S1G association response omits the AID Response element, abandon the association instead of proceeding with AID 0. Initialize aid to 0 for other S1G responses so the later mask and logging flow keeps a defined value without reading the non-S1G layout. Fixes: 2a8a6b7c4cb0 ("wifi: mac80211: handle station association response with S1G") Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260612152440.25955-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit fbaa8c31ef940e32d66544117e7c9093ddd28877 Author: Zhao Li Date: Fri Jun 12 21:37:11 2026 +0800 wifi: cfg80211: reject unsupported PMSR FTM location requests [ Upstream commit 69ef6a7ec277f16d216be8da2b3cbe872786c999 ] PMSR FTM location request flags are syntactically valid, but they must be rejected when the device capability does not advertise support for them. Return an error immediately after rejecting unsupported LCI or civic location request bits so the request cannot reach the driver. Fixes: 9bb7e0f24e7e7 ("cfg80211: add peer measurement with FTM initiator API") Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260612133710.93544-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit cfbda103aeae61071a122a6fc2bfe98cffbd7165 Author: Zhao Li Date: Fri Jun 12 21:37:04 2026 +0800 wifi: cfg80211: validate PMSR FTM preamble range [ Upstream commit 36230936468f0ba4930e94aef496fc229d4bb951 ] PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. Fixes: 9bb7e0f24e7e7 ("cfg80211: add peer measurement with FTM initiator API") Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260612133703.93274-2-enderaoelyther@gmail.com [drop unnecessary check] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0caf6416bfbb3ee4c6b780115fb05b4f41979b13 Author: Zhao Li Date: Fri Jun 12 21:36:57 2026 +0800 wifi: cfg80211: validate PMSR measurement type data [ Upstream commit 41aa973eb05922848dded26875c55ef982ac1c49 ] PMSR request parsing accepts missing or duplicated measurement type entries in NL80211_PMSR_REQ_ATTR_DATA. Track whether one measurement type was already provided, reject a second one immediately, and return an error if the request data block contains no measurement type at all. Fixes: 9bb7e0f24e7e7 ("cfg80211: add peer measurement with FTM initiator API") Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260612133656.92900-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0b6efde0ed9707303ce14a938d919eb54fcc329d Author: Zhao Li Date: Fri Jun 12 21:18:56 2026 +0800 wifi: nl80211: constrain MBSSID TX link ID range [ Upstream commit 172f06023669f0a96d32511669ff45c600731380 ] MBSSID transmitted-profile link IDs are valid only in the range 0..IEEE80211_MLD_MAX_NUM_LINKS - 1. Constrain the nl80211 policy to reject out-of-range values during attribute validation. Fixes: 37523c3c47b3 ("wifi: nl80211: add link id of transmitted profile for MLO MBSSID") Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260612131854.43575-4-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f8c547e543e12b6d9202cd36193c051670107071 Author: Zhao Li Date: Fri Jun 12 21:18:55 2026 +0800 wifi: nl80211: validate nested MBSSID IE blobs [ Upstream commit 7f4b01812323443b55e4c65381c9dc851ff009e3 ] Validate each nested NL80211_ATTR_MBSSID_ELEMS entry as a well-formed information-element stream before storing it for beacon construction. RNR parsing already validates each nested blob with validate_ie_attr() before storing it. Apply the same syntactic IE validation to MBSSID entries before counting and copying their data and length pointers. Fixes: dc1e3cb8da8b ("nl80211: MBSSID and EMA support in AP mode") Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4.8 Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260612131854.43575-3-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f649dc9c5e657dbacb58f149cbe5e1fc98b12871 Author: Zhao Li Date: Fri Jun 12 00:19:46 2026 +0800 wifi: cfg80211: derive S1G beacon TSF from S1G fields [ Upstream commit 4e5a4641e7b4763656336b7891d01359aaf363cd ] cfg80211_inform_bss_frame_data() parses S1G beacons with the extension frame layout, but still reads the TSF from the regular probe response layout after the S1G branch. For S1G beacons that reads bytes at the regular management-frame timestamp offset instead of the S1G timestamp. Use the 32-bit S1G beacon timestamp and the S1G Beacon Compatibility element's TSF completion field when informing an S1G BSS. Keep the regular management-frame timestamp read in the non-S1G branch. Fixes: 9eaffe5078ca ("cfg80211: convert S1G beacon to scan results") Signed-off-by: Zhao Li Tested-by: Lachlan Hodges Reviewed-by: Lachlan Hodges Link: https://patch.msgid.link/20260611161943.91069-6-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit fb052a6e2fa866384d8edc237746583ec94c15af Author: Zhao Li Date: Wed Jun 10 19:22:09 2026 +0800 wifi: nl80211: free RNR data on MBSSID mismatch [ Upstream commit 07a95ec2b54774201fdf4ef7ffb0ca2ab19ed29c ] nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error. Fixes: dbbb27e183b1 ("cfg80211: support RNR for EMA AP") Signed-off-by: Zhao Li Link: https://patch.msgid.link/20260610112208.1308-2-enderaoelyther@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 133684982dd0c24359fcc641d19d89cc17d6e5ef Author: Peddolla Harshavardhan Reddy Date: Fri Jul 3 13:55:23 2026 +0530 wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock [ Upstream commit 2b0eab425e1f658d8fe1df7590e3b9af5959505e ] When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down(). Fixes: 6dccbc9f3e1d ("wifi: cfg80211: cancel pmsr_free_wk in cfg80211_pmsr_wdev_down") Signed-off-by: Peddolla Harshavardhan Reddy Link: https://patch.msgid.link/20260703082523.2629324-1-peddolla.reddy@oss.qualcomm.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d38f5d868a0a4770e3bcd0925e16c46acdbc9509 Author: Xiang Mei Date: Sat Jun 27 17:05:10 2026 -0700 wifi: p54: validate RX frame length in p54_rx_eeprom_readback() [ Upstream commit ebd6d37fa94bee929e0b4c9ca19fdf9b1dcf6cea ] p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 ("wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying. Fixes: 7cb770729ba8 ("p54: move eeprom code into common library") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Acked-by: Christian Lamparter Link: https://patch.msgid.link/20260628000510.4152481-1-xmei5@asu.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2aa1789880fa5e41049b0f6a74a4fc2fa1997610 Author: Maoyi Xie Date: Sat Jun 27 16:30:28 2026 +0800 wifi: mac80211: defer link RX stats percpu free to RCU [ Upstream commit aa2eb62525188269cdd402a583b9a8ed94657ff0 ] sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU: sta_info_free_link(&alloc->info); kfree_rcu(alloc, rcu_head); The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists. The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU. Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain. Fixes: c71420db653a ("wifi: mac80211: RCU-ify link STA pointers") Link: https://lore.kernel.org/r/20260626080158.3589711-1-maoyixie.tju@gmail.com Suggested-by: Johannes Berg Co-developed-by: Kaixuan Li Signed-off-by: Kaixuan Li Signed-off-by: Maoyi Xie Link: https://patch.msgid.link/20260627083028.3826810-1-maoyixie.tju@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6cda91bbb8dc3d22ef0323008a12dcf73a5129da Author: Dawei Feng Date: Wed Jun 24 16:53:43 2026 +0800 wifi: libertas: fix memory leak in helper_firmware_cb() [ Upstream commit 63c2391deefb31e1b801b7f32bd502ca4808639b ] helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. 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 the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed. Fixes: 1dfba3060fe7 ("libertas: move firmware lifetime handling to firmware.c") Signed-off-by: Dawei Feng Link: https://patch.msgid.link/20260624085343.575508-1-dawei.feng@seu.edu.cn Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 5baaa1042f71dd4b8e418f2cdd516808702d229b Author: Xiang Mei Date: Sun Jun 21 02:35:32 2026 -0700 wifi: mac80211: fix fils_discovery double free on alloc failure [ Upstream commit 286e52a799fa158bdbd77da1426c4d93f9a6e7ad ] ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon(). Fixes: 3b1c256eb4ae ("wifi: mac80211: fixes in FILS discovery updates") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260621093532.884188-2-xmei5@asu.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d62b55b7c7dc62887d7fd5648fb38f0bfaef53ae Author: Xiang Mei Date: Sun Jun 21 02:35:31 2026 -0700 wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure [ Upstream commit 1d067abcd37062426c59ec73dbc4e87a63f33fea ] ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon(). Fixes: 3b1c256eb4ae ("wifi: mac80211: fixes in FILS discovery updates") Reported-by: Weiming Shi Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei Link: https://patch.msgid.link/20260621093532.884188-1-xmei5@asu.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6dc76371a9a360c29de00df5b11563102d9d675a Author: Bryam Vargas Date: Sat Jun 20 21:45:18 2026 -0500 wifi: mac80211_hwsim: clamp virtio RX length before skb_put [ Upstream commit 10a2b430f8f06ae14b9590b6f6faa6b588ef0654 ] hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem. Fixes: 5d44fe7c9808 ("mac80211_hwsim: add frame transmission support over virtio") Signed-off-by: Bryam Vargas Link: https://patch.msgid.link/20260620-b4-disp-474bee37-v1-1-1a4d37f3e2d4@proton.me Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit e67dc2b8d5ac4bb804000b6732768a9ae678912f Author: Christophe JAILLET Date: Sat Jun 20 21:48:56 2026 +0200 wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan() [ Upstream commit c6659f66d4ee4841aafae5659d2ef5e4c5c63cb6 ] If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it. Fixes: 2a5193119269 ("cfg80211/nl80211: scanning (and mac80211 update to use it)") Signed-off-by: Christophe JAILLET Link: https://patch.msgid.link/a1be7eea4da0da18f90589af252bb76a18a61978.1781984889.git.christophe.jaillet@wanadoo.fr Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit f442e581a88937671a22ceb3806c186265ef6254 Author: Abdun Nihaal Date: Sat Jun 20 12:22:39 2026 +0530 wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() [ Upstream commit 0d388f62031dbabcba0f44bb91b59f10e88cac17 ] The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline. Fixes: 2c86c275015c ("Add ipw2100 wireless driver.") Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20260620065242.93798-1-nihaal@cse.iitm.ac.in Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9293574ac208d18c11073538851fb69355beb3b5 Author: Cen Zhang Date: Sat Jun 20 00:25:42 2026 +0800 wifi: cfg80211: cancel sched scan results work on unregister [ Upstream commit edf0730be33696a1bd142792830d392129e495cc ] cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30 Fixes: 807f8a8c3004 ("cfg80211/nl80211: add support for scheduled scans") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Link: https://patch.msgid.link/20260619162542.3878296-1-zzzccc427@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7acc5ed2f33608a3d83b64f50a5766843b6e2485 Author: Xiang Mei (Microsoft) Date: Fri Jul 3 05:19:32 2026 +0000 xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert [ Upstream commit f38f8cce2f7e79775b3db7e8a5eacda04ac908e4 ] xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt Fixes: 24969facd704 ("xfrm: policy: store inexact policies in an rhashtable") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Reviewed-by: Florian Westphal Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit ff636d7b7cba6dea82ecf580415ea57f2c1a11b6 Author: Xiang Mei (Microsoft) Date: Thu Jul 2 01:05:16 2026 +0000 xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() [ Upstream commit 136992de9bb91871084ae52d172610541c76e4d2 ] On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + "unregister_netdevice: waiting for to become free"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ... Fixes: 84c4a9dfbf43 ("xfrm6: release dev before returning error") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit d8aaf06b29f5a0b6186cf68d21c7d63678ee3891 Author: Chen YanJun Date: Wed Jul 1 11:31:52 2026 +0800 xfrm: iptfs: propagate SKBFL_SHARED_FRAG in iptfs_skb_add_frags() [ Upstream commit 430ea57d6daf765e88f90046afbfd1e071cb7200 ] When iptfs_skb_add_frags() copies frag references from the source frag walk into a new SKB, it increments the page reference count via __skb_frag_ref() but does not propagate SKBFL_SHARED_FRAG to the destination SKB's skb_shinfo->flags. If the source SKB carries shared frags (e.g. from a page-pool backed receive path), the new inner SKB will appear to ESP as having privately owned frags. A subsequent esp_input() call for a nested transport-mode SA then takes the no-COW fast path and decrypts in place, writing over pages that are still referenced by the outer IPTFS SKB. This causes kernel-visible memory corruption and can trigger a panic. All other frag-transfer helpers in the kernel (skb_try_coalesce, skb_gro_receive, __pskb_copy_fclone, skb_shift, skb_segment) correctly propagate SKBFL_SHARED_FRAG; align iptfs_skb_add_frags() with this convention by setting the flag inside the loop immediately after __skb_frag_ref() and nr_frags++, so every exit path that attaches a frag unconditionally propagates SKBFL_SHARED_FRAG. Fixes: 5f2b6a909574 ("xfrm: iptfs: add skb-fragment sharing code") Signed-off-by: Chen YanJun Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 9845a35986a658816f7752f7ebd7c455a4c7dfdf Author: Cen Zhang Date: Sat Jun 27 11:01:17 2026 +0800 xfrm: clear mode callbacks after failed mode setup [ Upstream commit 2538bd3cd1ff5af655908469544ac7b7ae259386 ] xfrm_state_gc_task can run long after a failed IPTFS state setup. In the reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup returned -ENOMEM before publishing mode_data, and the temporary module reference from xfrm_get_mode_cbs() was dropped immediately. The dead state then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been unloaded. Clear x->mode_cbs when mode init or clone fails before publishing mode_data. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference. The buggy scenario involves two paths, with each column showing the order within that path: failed setup path: 1. cache x->mode_cbs 2. mode setup fails before mode_data 3. drop the temporary module ref 4. dead state keeps x->mode_cbs cached GC/unload path: 1. xfrm_state_put() queues GC work 2. xfrm_iptfs unloads later 3. xfrm_state_gc_task runs 4. GC dereferences stale x->mode_cbs This also covers the failed clone path where clone_state() returns before publishing mode_data. Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y failslab_stacktrace_filter matched xfrm_iptfs frames ack_error=-12 FAULT_INJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrm_state_gc_task RIP: xfrm_state_gc_task+0x142/0x650 Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs] Kernel panic - not syncing: Fatal exception Fixes: 4b3faf610cc6 ("xfrm: iptfs: add new iptfs xfrm mode impl") Assisted-by: Codex:gpt-5.5 Signed-off-by: Cen Zhang Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 9e632a70f20449f34b158d617c3b751fc9181226 Author: Aleksandrova Alyona Date: Wed Jun 24 17:48:46 2026 +0300 RDMA/irdma: Prevent overflows in memory contiguity checks [ Upstream commit 3cda0dfe8c651dcbb9e38977905d3d3b1750c4ab ] irdma_check_mem_contiguous() and irdma_check_mr_contiguous() verify that PBL entries describe physically contiguous memory ranges. Both functions calculate byte offsets using 32-bit operands. For example, with 4 KiB pages, pg_size * pg_idx overflows 32-bit arithmetic when pg_idx reaches 1048576. In the level-2 check, PBLE_PER_PAGE is 512, so i * pg_size * PBLE_PER_PAGE overflows when i reaches 2048. These values are reachable in the driver. For MRs, palloc->total_cnt comes from iwmr->page_cnt, which is calculated by ib_umem_num_dma_blocks(). The MR size is limited by IRDMA_MAX_MR_SIZE, so a 4 GiB MR with 4 KiB pages can reach page_cnt of 1048576. PBLE resources do not exclude this value either: for gen3, the limit is based on avail_sds * MAX_PBLE_PER_SD, and MAX_PBLE_PER_SD is 0x40000, so 4 SDs are enough for 1048576 PBLEs. Cast one operand to u64 before the multiplications so that the offset calculations are performed in 64-bit arithmetic. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Aleksandrova Alyona Link: https://patch.msgid.link/20260624144846.61242-1-aga@itb.spb.ru Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 124382a2a9756678f9c9db9a4ff369ecfac17a95 Author: Malaya Kumar Rout Date: Sat Jul 4 16:27:36 2026 +0530 selftests/alsa: Fix memory leak in find_controls error path [ Upstream commit cb89f0c1aed02eb233c4271f76f830b37e222ff6 ] In find_controls(), card_data is allocated with malloc() but when snd_ctl_open_lconf() fails, the code jumps to next_card without freeing the allocated memory. This results in a memory leak for each card where snd_ctl_open_lconf() fails. Add free(card_data) before goto next_card to ensure proper cleanup of the allocated memory in the error path. Fixes: 5aaf9efffc57 ("kselftest: alsa: Add simplistic test for ALSA mixer controls kselftest") Signed-off-by: Malaya Kumar Rout Link: https://patch.msgid.link/20260704105736.94874-1-malayarout91@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f98ae09c727dcf34f745c875661c64b642e4abfa Author: Xue Lei Date: Wed Jul 1 20:10:42 2026 +0800 mtd: fix double free and WARN_ON in add_mtd_device() error paths [ Upstream commit 9d4af746af8ce27eefc2338b2feaa1e01f28b6c3 ] When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case. Reported-by: syzbot+e9c76b56dc05023b8117@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e9c76b56dc05023b8117 Fixes: 19bfa9ebebb5 ("mtd: use refcount to prevent corruption") Signed-off-by: Xue Lei Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit fcc9d50022bcdb1f9f7ed04955c72b4a7355af3d Author: Ruoyu Wang Date: Tue Jun 30 14:00:40 2026 +0800 RDMA/siw: publish QP after initialization [ Upstream commit bb27fcc67c429d97f785c92c35a6c5adebb05d7f ] siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list. Fixes: f29dd55b0236 ("rdma/siw: queue pair methods") Link: https://patch.msgid.link/r/20260630060040.966461-1-ruoyuw560@gmail.com Suggested-by: Bernard Metzler Signed-off-by: Ruoyu Wang Acked-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e221dde026af207ff38aff17046266bda23c5d9e Author: Danila Chernetsov Date: Sat Jun 27 09:59:51 2026 +0000 RDMA/hns: Fix potential integer overflow in mhop hem cleanup [ Upstream commit 9f0f2d2121f16d420199a82ac5bbc242269133b3 ] In hns_roce_cleanup_mhop_hem_table(), the expression: obj = i * buf_chunk_size / table->obj_size; is evaluated using 32-bit unsigned arithmetic because 'buf_chunk_size' is u32 and the usual arithmetic conversions convert 'i' to unsigned int. The result is assigned to a u64 variable, but the multiplication may overflow before the assignment. For sufficiently large HEM tables, this produces an incorrect object index passed to hns_roce_table_mhop_put(). Cast 'i' to u64 before the multiplication so that the intermediate calculation is performed with 64-bit arithmetic. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a25d13cbe816 ("RDMA/hns: Add the interfaces to support multi hop addressing for the contexts in hip08") Link: https://patch.msgid.link/r/20260627095951.51378-1-listdansp@mail.ru Signed-off-by: Danila Chernetsov Reviewed-by: Junxian Huang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d842ef03d91458a52dc74cb98c747e10f7bfd633 Author: Ruoyu Wang Date: Thu Jun 18 12:17:52 2026 +0800 RDMA/mana_ib: initialize err for empty send WR lists [ Upstream commit 155fd5ce2382b0ffbec0d7ee7b3a6818a27a5aed ] mana_ib_post_send() returns err after walking the send work request list. If the caller passes an empty list, the loop is skipped and err is not assigned. Initialize err to 0 so an empty send work request list returns success instead of stack data. Fixes: c8017f5b4856 ("RDMA/mana_ib: UD/GSI work requests") Link: https://patch.msgid.link/r/20260618041752.481193-2-ruoyuw560@gmail.com Signed-off-by: Ruoyu Wang Reviewed-by: Long Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 14e519f93a48cc217afea2a7096c866dda8ab785 Author: Ruoyu Wang Date: Thu Jun 18 12:17:51 2026 +0800 RDMA/erdma: initialize ret for empty receive WR lists [ Upstream commit 2815a277c53e9a84784d6410cd55a9da5b33068d ] erdma_post_recv() returns ret after walking the receive work request list. If the caller passes an empty list, the loop is skipped and ret is not assigned. Initialize ret to 0 so an empty receive work request list returns success instead of stack data. Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation") Link: https://patch.msgid.link/r/20260618041752.481193-1-ruoyuw560@gmail.com Signed-off-by: Ruoyu Wang Reviewed-by: Cheng Xu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ec675b4cdfd378d8c9dd8c93126c024f2469bd79 Author: Jacob Moroni Date: Wed Jun 17 16:40:13 2026 +0000 RDMA/irdma: Prevent user-triggered null deref on QP create [ Upstream commit b9b0889071569d43623c260074e159cd8f26adb1 ] Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp. While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref. Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Link: https://patch.msgid.link/r/20260617164013.280790-1-jmoroni@google.com Signed-off-by: Jacob Moroni Reviewed-by: David Hu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1cd56258fe1a0b13a6eb9458cbe4c82ad3caf332 Author: Jacob Moroni Date: Tue Jun 2 21:44:22 2026 +0000 RDMA/irdma: Remove redundant legacy_mode checks [ Upstream commit ed8621be482bf18dcd217aa024e95758bf9d28f2 ] The driver has the following invariants: 1. legacy_mode is only allowed on GEN_1 hardware (enforced in irdma_alloc_ucontext). 2. GEN_1 hardware does not set IRDMA_FEATURE_CQ_RESIZE or IRDMA_FEATURE_RTS_AE. These feature flags are only set for GEN_2 and GEN_3 hardware. Therefore, legacy_mode is always false if IRDMA_FEATURE_CQ_RESIZE or IRDMA_FEATURE_RTS_AE is set, so remove the redundant checks. Link: https://patch.msgid.link/r/20260602214423.1315105-1-jmoroni@google.com Signed-off-by: Jacob Moroni Signed-off-by: Jason Gunthorpe Stable-dep-of: b9b088907156 ("RDMA/irdma: Prevent user-triggered null deref on QP create") Signed-off-by: Sasha Levin commit ca1c29f05274b737dc964e28b97803750d7cf7ec Author: Jacob Moroni Date: Wed Jun 17 14:19:36 2026 +0000 RDMA/irdma: Prevent rereg_mr for non-mem regions [ Upstream commit a846aecb931b4d65d5eafa92a0623545af46d4f2 ] When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions. Fixes: 5ac388db27c4 ("RDMA/irdma: Add support to re-register a memory region") Signed-off-by: Jacob Moroni Reviewed-by: David Hu Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit dbb945b80a3a4a21a80292c7bebdd0d674209507 Author: Jacob Moroni Date: Thu Mar 5 17:08:24 2026 +0000 RDMA/umem: Add pinned revocable dmabuf import interface [ Upstream commit ff85a2ebacbdaec9f28c4660c991295ace93cd1c ] Added an interface for importing a pinned but revocable dmabuf. This interface can be used by drivers that are capable of revocation so that they can import dmabufs from exporters that may require it, such as VFIO. This interface implements a two step process, where drivers will first call ib_umem_dmabuf_get_pinned_revocable_and_lock() which will pin and map the dmabuf (and provide a functional move_notify/invalidate_mappings callback), but will return with the lock still held so that the driver can then populate the callback via ib_umem_dmabuf_set_revoke_locked() without races from concurrent revocations. This scheme also allows for easier integration with drivers that may not have actually allocated their internal MR objects at the time of the get_pinned_revocable* call. Signed-off-by: Jacob Moroni Link: https://patch.msgid.link/20260305170826.3803155-4-jmoroni@google.com Signed-off-by: Leon Romanovsky Stable-dep-of: a846aecb931b ("RDMA/irdma: Prevent rereg_mr for non-mem regions") Signed-off-by: Sasha Levin commit c4ef25de94d7338bcd39f5dbfc6d3b415e0a1516 Author: Or Gerlitz Date: Wed Jun 17 14:21:05 2026 +0300 RDMA/cma: Fix hardware address comparison length in netevent callback [ Upstream commit 18313833e2c6de222a4f6c072da759d0d5888528 ] The cited commit hardcoded the hardware address comparison len to ETH_ALEN. This breaks IPoIB, which uses 20-byte addresses. By truncating the memcmp, the CMA may incorrectly assume the target address is unchanged and fails to abort the stalled connection. Fix this by replacing ETH_ALEN with the dynamic neigh->dev->addr_len to correctly evaluate the full address regardless of the link layer. Fixes: 925d046e7e52 ("RDMA/core: Add a netevent notifier to cma") Signed-off-by: Or Gerlitz Link: https://patch.msgid.link/20260617-fix-cma-ipoib-v1-1-03f869344304@ddn.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d7fc6f351c478586980a521d63b0214d9c055e78 Author: Antony Antony Date: Sat Jun 27 10:23:43 2026 +0200 xfrm: reject optional IPTFS templates in outbound policies [ Upstream commit ea528f18231ec0f33317be57f8866913b19aba6e ] syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 ("xfrm: Reject optional tunnel/BEET mode templates in outbound policies") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency_start+0x1f/0x70 [ 64.169977] ? fd_install+0x7e/0x150 [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __sys_socket+0xdf/0x130 [ 64.169977] ? __pfx___sys_socket+0x10/0x10 [ 64.169977] ? vma_refcount_put+0x43/0xa0 [ 64.169977] __x64_sys_connect+0x7e/0x90 [ 64.169977] do_syscall_64+0x11b/0x2b0 [ 64.169977] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] RIP: 0033:0x7f4851ecb570 [ 64.169977] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 80 3d f9 ca 0d 00 00 74 17 b8 2a 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 54 [ 64.169977] RSP: 002b:00007ffc830e3498 EFLAGS: 00000202 ORIG_RAX: 000000000000002a [ 64.169977] RAX: ffffffffffffffda RBX: 00007ffc830e34d0 RCX: 00007f4851ecb570 [ 64.169977] RDX: 0000000000000010 RSI: 00007ffc830e34d0 RDI: 0000000000000005 [ 64.169977] RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000000 [ 64.169977] R10: 0000000000000006 R11: 0000000000000202 R12: 0000000000000005 [ 64.169977] R13: 0000000000000000 R14: 00005619a863f340 R15: 0000000000000000 [ 64.169977] [ 64.169977] The buggy address belongs to stack of task ping/2844 [ 64.169977] and is located at offset 88 in frame: [ 64.169977] ip4_datagram_release_cb+0x0/0x530 [ 64.169977] This frame has 1 object: [ 64.169977] [32, 88) 'fl4' [ 64.169977] The buggy address belongs to the physical page: [ 64.169977] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xe1ff [ 64.169977] flags: 0x4000000000000000(zone=1) [ 64.169977] raw: 4000000000000000 0000000000000000 ffffea0000387fc8 0000000000000000 [ 64.169977] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 64.169977] page dumped because: kasan: bad access detected [ 64.169977] Memory state around the buggy address: [ 64.169977] ffff88800e1ffc00: f2 f2 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 [ 64.169977] ffff88800e1ffc80: 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 [ 64.169977] >ffff88800e1ffd00: 00 00 00 00 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 [ 64.169977] ^ [ 64.169977] ffff88800e1ffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 [ 64.169977] ffff88800e1ffe00: f1 f1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 64.169977] ================================================================== [ 64.245153] Disabling lock debugging due to kernel taint After the fix: ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl \ src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs \ level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 \ mode transport Error: Mode in optional template not allowed in outbound policy. Fixes: d1716d5a44c3 ("xfrm: add generic iptfs defines and functionality") Reported-by: syzbot+0ac4d84afe1066a1f3e9@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6a3ceb94.43b4ff68.30a095.0004.GAE@google.com/T/ Signed-off-by: Antony Antony Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 2907e9d0f05b506dfd58aec589a23042a56ef36b Author: Tejun Heo Date: Mon Jun 29 12:55:48 2026 -1000 sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx() [ Upstream commit b7d9c359e5cf867f7eb23df3bb1c6b9e58af24da ] put_prev_task_scx() warns when a runnable task drops to a lower sched_class without SCX_OPS_ENQ_LAST, on the assumption that balance_one() would have kept it running. Core scheduling breaks that: a forced-idle SMT sibling reschedules through the core_pick fast path in pick_next_task(), which skips pick_task_scx() and thus balance_one(), so a runnable task can drop to idle with ENQ_LAST unset. Gate the warning on sched_cpu_cookie_match(): a cookie mismatch means core scheduling forced the idle, while a match (or core scheduling off) still catches a genuine missing-ENQ_LAST drop. Fixes: 7c65ae81ea86 ("sched_ext: Don't call put_prev_task_scx() before picking the next task") Signed-off-by: Tejun Heo Reviewed-by: Andrea Righi Signed-off-by: Sasha Levin commit 57acd519283333fa5b7a809a42a01222ac1faabe Author: John Stultz Date: Sat Dec 6 02:22:03 2025 +0000 sched/ext: Avoid null ptr traversal when ->put_prev_task() is called with NULL next [ Upstream commit 12b5cd99a05f7cbc2ceb88b3b9601d404ef2236a ] Early when trying to get sched_ext and proxy-exe working together, I kept tripping over NULL ptr in put_prev_task_scx() on the line: if (sched_class_above(&ext_sched_class, next->sched_class)) { Which was due to put_prev_task() passes a NULL next, calling: prev->sched_class->put_prev_task(rq, prev, NULL); put_prev_task_scx() already guards for a NULL next in the switch_class case, but doesn't seem to have a guard for sched_class_above() check. I can't say I understand why this doesn't trip usually without proxy-exec. And in newer kernels there are way fewer put_prev_task(), and I can't easily reproduce the issue now even with proxy-exec. But we still have one put_prev_task() call left in core.c that seems like it could trip this, so I wanted to send this out for consideration. tj: put_prev_task() can be called with NULL @next; however, when @p is queued, that doesn't happen, so this condition shouldn't currently be triggerable. The connection isn't straightforward or necessarily reliable, so add the NULL check even if it can't currently be triggered. Link: http://lkml.kernel.org/r/20251206022218.1541878-1-jstultz@google.com Signed-off-by: John Stultz Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Stable-dep-of: b7d9c359e5cf ("sched_ext: Don't warn on core-sched forced idle in put_prev_task_scx()") Signed-off-by: Sasha Levin commit 996c5c19d5b5ac5b98a7b5a406b548305841c301 Author: Unnathi Chalicheemala Date: Wed Jun 17 16:35:00 2026 -0700 firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() [ Upstream commit 8ae5f8e4836667fcaffdf2e3c6068b0a8b364dd8 ] ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input. Fixes: d0c0bce83122 ("firmware: arm_ffa: Setup in-kernel users of FFA partitions") Signed-off-by: Unnathi Chalicheemala Link: https://patch.msgid.link/20260617-ffa_partition_nullptr_fix-v2-1-bc801b4ce34c@oss.qualcomm.com Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 8edc9252517808b87b53311da688a5a365b0b70c Author: Boris Burkov Date: Thu Jun 11 14:40:17 2026 -0700 btrfs: fallback to transaction csum tree on a commit root csum miss [ Upstream commit 3dcd50730814e5220072d2b26d0587af6bfb6dbe ] We have been running with commit root csums enabled for some time and have noticed a slight uptick in zero csum errors. Investigating those revealed that they were same transaction reads of extents that were just relocated, but the extent map generation was long ago. It turns out that relocation intentionally does not update the extent generation (replace_file_extents()), but must write a new csum since the data has moved, so we must account for this with commit root csum reading. Luckily this is a short lived condition: after the relocation transaction the commit root will once again have the csum. So we can add a generic fallback to the lookup to try again with the transaction csum root. Fixes: f07b855c56b1 ("btrfs: try to search for data csums in commit root") Reviewed-by: Filipe Manana Signed-off-by: Boris Burkov Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit a84ca16ce07e749bdf32d36d0939560523e3bd42 Author: Filipe Manana Date: Fri Nov 14 16:00:04 2025 +0000 btrfs: use bool type for btrfs_path members used as booleans [ Upstream commit d7fe41044b3ac8f9b5965de499a13ac9ae947e79 ] Many fields of struct btrfs_path are used as booleans but their type is an unsigned int (of one 1 bit width to save space). Change the type to bool keeping the :1 suffix so that they combine with the previous u8 fields in order to save space. This makes the code more clear by using explicit true/false and more in line with the preferred style, preserving the size of the structure. Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Stable-dep-of: 3dcd50730814 ("btrfs: fallback to transaction csum tree on a commit root csum miss") Signed-off-by: Sasha Levin commit 60a23d4ea169e27403f3bb023bb98036797c0206 Author: Filipe Manana Date: Thu Jun 11 15:16:21 2026 +0100 btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() [ Upstream commit ce6050bafb4e33377dc17fcc357736bfc351180c ] If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call. Fixes: 24213fa46c70 ("btrfs: do proper error handling in merge_reloc_roots") Reviewed-by: Qu Wenruo Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5e1b2ca6b34939e70fb0785e8222b53cf060016f Author: Xiang Mei Date: Wed Jun 10 10:29:26 2026 -0700 btrfs: reject free space cache with more entries than pages [ Upstream commit a2d8d5647ed854e38f941741aea45b9eb15a6350 ] When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: num_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); io_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected. Reported-by: Weiming Shi Fixes: 5b0e95bf607d ("Btrfs: inline checksums into the disk free space cache") Link: https://lore.kernel.org/linux-btrfs/CAPpSM+RMPByMCKXvM5QFKToxsyNccfuFLWMdD0mfd0wh2Ja62w@mail.gmail.com/ Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Qu Wenruo Signed-off-by: Xiang Mei Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 0ac9c7d9ccfd775c7033cf79a095f335d60214c5 Author: Pengpeng Hou Date: Tue Jun 23 21:57:29 2026 +0800 mtd: nand: mtk-ecc: stop on ECC idle timeouts [ Upstream commit 16f7ec8d5dc100eafd2c8e06cd30340a30b104a1 ] mtk_ecc_wait_idle() logs when the encoder or decoder does not become idle, but returns void. Callers can therefore configure a non-idle ECC engine or read parity bytes after an unconfirmed encoder idle state. Return the idle poll result and propagate it from the enable and encode paths that require the engine to be idle before continuing. Fixes: 1d6b1e464950 ("mtd: mediatek: driver for MTK Smart Device") Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit fdb53a9b260718000a242fdabb05873749f46fbb Author: Pengpeng Hou Date: Tue Jun 23 09:53:17 2026 +0800 mtd: mtdswap: remove debugfs stats file on teardown [ Upstream commit 66fb31358108d10245b9e4ef0eef3e7d9747055e ] mtdswap_add_debugfs() creates an mtdswap_stats debugfs file under the per-MTD debugfs directory, but mtdswap_remove_dev() never removes it before freeing the mtdswap_dev. Store the returned dentry and remove it during device teardown before the driver-private state is freed. Fixes: a32159024620 ("mtd: Add mtdswap block driver") Signed-off-by: Pengpeng Hou Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 98d2d468b4faa1fdc68c0c6c238389906ee3490c Author: Michael Bommarito Date: Sat Jun 6 16:01:55 2026 -0400 IB/mad: Drop unmatched RMPP responses before reassembly [ Upstream commit d2e52d610b9b09694261632340b801a421e0b0c5 ] Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request. Fixes: fa619a77046b ("[PATCH] IB: Add RMPP implementation") Assisted-by: Codex:gpt-5-5-xhigh Signed-off-by: Michael Bommarito Link: https://patch.msgid.link/3170ff3bc389a930bb1641f2caa394a0b2241579.1780774907.git.michael.bommarito@gmail.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 59114e0ff6e3a61efcd80d20b91d0761b7a34866 Author: Seth Forshee Date: Tue Jun 2 21:54:06 2026 +0000 firmware: arm_ffa: Respect firmware advertised RX/TX buffer size limits [ Upstream commit 53716a4d745f1dac7aff33f3d1494b701eb2f888 ] FFA_FEATURES reports the minimum size and alignment boundary required for RXTX_MAP. In FF-A v1.2 and later it can also report a maximum buffer size, with zero meaning that no maximum is enforced. The driver only used the minimum value and then rounded it up to PAGE_SIZE before invoking RXTX_MAP after commit 83210251fd70 ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP"). On systems where PAGE_SIZE is larger than the advertised minimum, this can exceed a non-zero maximum reported by firmware. Older implementations do not advertise a maximum and may also reject the rounded-up size. Decode the maximum size and clamp the page-aligned minimum to it when it is present. If no maximum is advertised and RXTX_MAP rejects the rounded size with INVALID_PARAMETERS, retry with the advertised minimum size. Record drv_info->rxtx_bufsz only after RXTX_MAP succeeds so it reflects the size registered with firmware. While there, also update RXTX_MAP_MIN_BUFSZ() to use FIELD_GET() for consistency. Fixes: 83210251fd70 ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP") Suggested-by: Sudeep Holla Signed-off-by: Seth Forshee Link: https://patch.msgid.link/20260602-b4-ffa-rxtx-map-fixes-v2-1-7cb06508da84@nvidia.com (sudeep.holla: Minor rewording subject and commit message) Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 33e1b0d25ca0d2818c635ff80e6aa0d295e08a98 Author: Petr Wozniak Date: Sun Jun 21 12:03:27 2026 +0200 xfrm: fix stale skb->prev after async crypto steals a GSO segment [ Upstream commit 3f4c3919baf0944ad96580467c302bc6c7758b00 ] skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev). When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free. Repoint skb->prev at the last retained segment before returning. Fixes: f53c723902d1 ("net: Add asynchronous callbacks for xfrm on layer 2.") Signed-off-by: Petr Wozniak Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit eae16fbc7ce20246b46e349e7ec0043a0f181b71 Author: Petr Wozniak Date: Sun Jun 21 12:03:26 2026 +0200 xfrm: propagate -EINPROGRESS from validate_xmit_xfrm() [ Upstream commit 6860b467f569f732b11cbc588ae7e195e90e7e23 ] validate_xmit_xfrm() returns NULL both when a packet is dropped and when it is stolen by async crypto (-EINPROGRESS from ->xmit()). Callers cannot distinguish the two cases. f53c723902d1 ("net: Add asynchronous callbacks for xfrm on layer 2.") changed the semantics of a NULL return from "dropped" to "stolen or dropped", but __dev_queue_xmit() was not updated. On virtual/bridge interfaces (noqueue qdisc) __dev_queue_xmit() initialises rc=-ENOMEM and jumps to out: when skb is NULL, returning -ENOMEM to the caller even though the packet will be delivered correctly via xfrm_dev_resume(). Return ERR_PTR(-EINPROGRESS) from validate_xmit_xfrm() for the async case so callers can tell it apart from a real drop. Update __dev_queue_xmit() to handle ERR_PTR(-EINPROGRESS) from validate_xmit_skb() correctly. Update validate_xmit_skb_list() to use IS_ERR_OR_NULL() so that ERR_PTR(-EINPROGRESS) is not mistakenly added to the transmitted list. Fixes: f53c723902d1 ("net: Add asynchronous callbacks for xfrm on layer 2.") Suggested-by: Sabrina Dubroca Signed-off-by: Petr Wozniak Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 23bbb9eafec7a49197d7a1be1919480d25add1cd Author: Eric Dumazet Date: Thu Mar 12 20:18:24 2026 +0000 net: plumb drop reasons to __dev_queue_xmit() [ Upstream commit 045f977dd4ebdd3ad8e96cf684917adfc5805adb ] Add drop reasons to __dev_queue_xmit(): - SKB_DROP_REASON_DEV_READY : device is not UP. - SKB_DROP_REASON_RECURSION_LIMIT : recursion limit on virtual device is hit. Also add an unlikely() for the SKB_DROP_REASON_DEV_READY case, and reduce indentation level. Signed-off-by: Eric Dumazet Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260312201824.203093-3-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 6860b467f569 ("xfrm: propagate -EINPROGRESS from validate_xmit_xfrm()") Signed-off-by: Sasha Levin commit 4cc4d6fb08e75725df5577cf44b66099a4851ab8 Author: Eric Dumazet Date: Thu Mar 12 20:18:23 2026 +0000 net: dropreason: add SKB_DROP_REASON_RECURSION_LIMIT [ Upstream commit d15d3de94a4766fb43d7fe7a72ed0479fb268131 ] ip[6]tunnel_xmit() can drop packets if a too deep recursion level is detected. Add SKB_DROP_REASON_RECURSION_LIMIT drop reason. We will use this reason later in __dev_queue_xmit(). Signed-off-by: Eric Dumazet Reviewed-by: Joe Damato Link: https://patch.msgid.link/20260312201824.203093-2-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 6860b467f569 ("xfrm: propagate -EINPROGRESS from validate_xmit_xfrm()") Signed-off-by: Sasha Levin commit 4c22b4e3ff5025055c58e1b526ecdfdd16d0d6cf Author: Sumit Gupta Date: Wed Jan 21 16:15:34 2026 +0530 arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234 [ Upstream commit 0dfa1e960f86e032007882b032c5cc7d14ebe73e ] The Tegra234 SoC uses Cortex-A78AE cores, not Cortex-A78. Update the compatible string for all CPU nodes to match the actual hardware. Tegra234 hardware reports: # head /proc/cpuinfo | egrep 'implementer|part' CPU implementer : 0x41 CPU part : 0xd42 Which maps to (from arch/arm64/include/asm/cputype.h): #define ARM_CPU_IMP_ARM 0x41 #define ARM_CPU_PART_CORTEX_A78AE 0xD42 Fixes: a12cf5c339b08 ("arm64: tegra: Describe Tegra234 CPU hierarchy") Signed-off-by: Sumit Gupta Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 0b9858484d09687519a9129b0f70f73c8dc7ffc2 Author: Akhil R Date: Tue Mar 31 15:52:55 2026 +0530 arm64: tegra: Remove fallback compatible for GPCDMA [ Upstream commit ee7863e43228a3143398dc5bbb943c9a735a8fca ] Remove the fallback compatible string "nvidia,tegra186-gpcdma" for GPCDMA in Tegra264. Tegra186 compatible cannot work on Tegra264 because of the register offset changes and absence of the reset property. Fixes: 65ef237e4810 ("arm64: tegra: Add Tegra264 support") Signed-off-by: Akhil R Reviewed-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 903f2edc0477025dbb8363187a60fec06cee65bb Author: Junxi Qian Date: Sat Jul 25 17:04:08 2026 +0800 fuse: fix writeback array overflow when max_pages is one [ Upstream commit c3880a7b10e487e033dc6f388bda118436566f7a ] fuse_iomap_writeback_range() appends one folio pointer and one fuse_folio_desc for every dirty range that is merged into the current writeback request. The merge decision checks the byte budget against fc->max_pages and fc->max_write, but it does not check whether the folio and descriptor arrays still have another free slot. This is not sufficient for fuseblk, where the filesystem block size can be smaller than PAGE_SIZE. With writeback cache enabled and max_pages negotiated as one, contiguous sub-page dirty ranges can fit within the byte budget while spanning more than one folio. The next append can then write past the one-slot folios and descs arrays. Split the request when the number of already attached folios has reached fc->max_pages. This keeps the folio/descriptor slot accounting in sync with the send decision. Fixes: ef7e7cbb323f ("fuse: use iomap for writeback") Cc: stable@vger.kernel.org Reviewed-by: Joanne Koong Signed-off-by: Junxi Qian Link: https://patch.msgid.link/20260506122415.205340-1-qjx1298677004@gmail.com Acked-by: Miklos Szeredi Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit afe9cda0862aa82b5d1d5152d7193319d7c18137 Author: Dmitry Torokhov Date: Fri May 22 10:29:41 2026 -0700 Input: ims-pcu - fix logic error in packet reset [ Upstream commit 2c9b85a14abb4811e8d4773ccd13559e59792efb ] ims_pcu_reset_packet() incorrectly sets have_stx to true, which implies that the start-of-packet delimiter has already been received. This causes the protocol parser to skip waiting for the next STX byte and potentially process garbage data. Correctly set have_stx to false when resetting the packet state. Fixes: 875115b82c29 ("Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()") Cc: stable@vger.kernel.org Reported-by: Sashiko bot Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit d03a740e087de7dcb2a26dc1123377bd3d1d84ca Author: Seungjin Bae Date: Wed Apr 8 09:03:59 2026 -0700 Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() [ Upstream commit 875115b82c295277b81b6dfee7debc725f44e854 ] The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. Fixes: 628329d524743 ("Input: add IMS Passenger Control Unit driver") Co-developed-by: Sanghoon Choi Signed-off-by: Sanghoon Choi Signed-off-by: Seungjin Bae Link: https://patch.msgid.link/20251221211442.841549-2-eeodqql09@gmail.com [dtor: factor out resetting packet state, reset checksum as well] Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 6cbed4be9a6ca391f8dca3cf8f285d144e29b747 Author: Chuck Lever Date: Tue May 26 10:14:04 2026 -0400 xprtrdma: Clear receive-side ownership pointers on release [ Upstream commit 2ae8e7afbc63bf84243367f89eb43571f0345a74 ] Three small ownership-state cleanups land the transport in a state that lets future reviewers reason about each pointer locally rather than tracing the whole reply path: rpcrdma_rep_put() clears rep->rr_rqst before the rep enters rb_free_reps so that no rep on the free list still carries a stale rqst pointer. rpcrdma_reply_handler() and rpcrdma_unpin_rqst() are the only sites that set rr_rqst; rpcrdma_reply_handler() hands the rep through rpcrdma_rep_put(), and rpcrdma_unpin_rqst() NULLs rr_rqst directly because its error path abandons the rep for teardown cleanup rather than returning it to rb_free_reps. rpcrdma_reply_put() NULLs req->rl_reply before calling rpcrdma_rep_put(). The previous order placed the rep on rb_free_reps while req->rl_reply still pointed at it; the window was harmless because xprt_rdma_free_slot() holds the req exclusively across the pair, but closing it makes the invariant 'rep on rb_free_reps implies no req references it' strictly checkable. rpcrdma_sendctx_unmap() and rpcrdma_sendctx_cancel() clear req->rl_sendctx after dropping the sendctx pointer in the sendctx ring. Without this, req->rl_sendctx survives across Send completion and points at a sendctx that may already have been reassigned by rpcrdma_sendctx_get_locked() to a different req. No caller dereferences the stale pointer today -- rpcrdma_prepare_send_sges() overwrites it before the next Send -- but a NULL is a more honest representation of 'the Send is no longer outstanding' and lets the assertion patch that follows trip on any future regression. Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 0892b427c4b8b7b416467f50b74305e416f4235c Author: Mikko Perttunen Date: Fri May 15 11:34:52 2026 +0900 crypto: tegra - Don't touch bo refcount in host1x bo pin/unpin [ Upstream commit f8c9c57d750346abd213ffed2ae3cacb0268e9f1 ] Since commit "gpu: host1x: Allow entries in BO caches to be freed", host1x_bo_pin() and host1x_bo_unpin() handle the bo's refcount themselves. .pin/.unpin callbacks should not adjust it. Signed-off-by: Mikko Perttunen Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5f4de3c717d34a24d555af581947742980778c02 Author: Mikko Perttunen Date: Wed Jun 3 17:37:49 2026 +0900 gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings [ Upstream commit 266cddf7bd0f6c79b6c0633aef742a22bf70265b ] __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead. Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-tegra/ah6ErK6f4kVudVIA@stanley.mountain/T/#u Signed-off-by: Mikko Perttunen Signed-off-by: Thierry Reding Link: https://patch.msgid.link/20260603-host1x-bocache-leak-fix-v1-1-494101dbfd30@nvidia.com Signed-off-by: Sasha Levin commit ec9f66c91bffdb69d309bae6dfb387562db7ebc8 Author: Claudiu Beznea Date: Fri Jul 24 14:59:09 2026 +0200 dmaengine: sh: rz-dmac: Move interrupt request after everything is set up commit 731712403ddb39d1a76a11abf339a0615bc85de7 upstream. Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent(). Fixes: 5000d37042a6 ("dmaengine: sh: Add DMAC driver for RZ/G2L SoC") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Tested-by: John Madieu Signed-off-by: Claudiu Beznea Tested-by: Tommaso Merciai Link: https://patch.msgid.link/20260526084710.3491480-2-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul [tm: Kept the channel->irq field in rz_dmac_chan_probe() instead of upstream's local `irq` variable, as commit 04e227718ab8 ("dmaengine: sh: rz-dmac: Make channel irq local") is not present in this tree. Likewise kept platform_get_irq_byname() instead of platform_get_irq_byname_optional() for the error IRQ in rz_dmac_probe(), as commit 6b3a6b6dc074 ("dmaengine: sh: rz_dmac: make error interrupt optional") is not present in this tree either; its early return on failure becomes a goto err jump to match the new call order.] Signed-off-by: Tommaso Merciai Signed-off-by: Sasha Levin commit eca8b44d51fc6ab61022258ec968e55e3073b79e Author: Oliver Hartkopp Date: Fri Jul 24 12:25:58 2026 +0200 can: bcm: track a single source interface for ANYDEV timeout/throttle ops commit 2f5976f54a04e9f18b25283036ac3136be453b17 upstream. An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net(). Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-can/20260709105031.1A39C1F000E9@smtp.kernel.org/ Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-11-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Signed-off-by: Sasha Levin commit 136de17f38630307991c59aa7080012a99451783 Author: Oliver Hartkopp Date: Fri Jul 24 12:25:57 2026 +0200 can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() commit 58fd6cbc8541216af1d7ed272ea7ac2b66d50fd8 upstream. For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them. Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-can/20260707145135.5BC831F00A3A@smtp.kernel.org/ Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-10-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Signed-off-by: Sasha Levin commit 6be3e1fedf03eab36a2c09d755d1171287b2014b Author: Oliver Hartkopp Date: Fri Jul 24 12:25:56 2026 +0200 can: bcm: fix stale rx/tx ops after device removal commit 3b762c0d950383ab7a002686c9136b9aa55d2d70 upstream. RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match. Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/linux-can/20260708094536.DDF821F00A3A@smtp.kernel.org/ Closes: https://lore.kernel.org/linux-can/20260708154039.347ED1F000E9@smtp.kernel.org/ Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-9-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Signed-off-by: Sasha Levin commit b024c21c9066f6957b7d4a8f2037e4b000c5e041 Author: Oliver Hartkopp Date: Fri Jul 24 12:25:55 2026 +0200 can: bcm: add missing device refcount for CAN filter removal commit d59948293ea34b6337ce2b5febab8510de70048c upstream. sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 ("can: raw: add missing refcount for memory leak fix") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex. Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260707094716.63578-1-socketcan@hartkopp.net Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-8-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Signed-off-by: Sasha Levin commit deb6a697cce3f021e731df543597f37a5e54caab Author: Oliver Hartkopp Date: Fri Jul 24 12:25:54 2026 +0200 can: bcm: validate frame length in bcm_rx_setup() for RTR replies commit 62ec41f364648be79d54d94d0d240ee326948afd upstream. bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME. Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-7-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Signed-off-by: Sasha Levin commit bd46f55dec608daa44b45dcf3328517630ad8e40 Author: Oliver Hartkopp Date: Fri Jul 24 12:25:53 2026 +0200 can: bcm: extend bcm_tx_lock usage for data and timer updates commit 12ce799f7ab1e05bd8fbf79e46f403bfe5597ebc upstream. Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms. Fixes: c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-6-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Signed-off-by: Sasha Levin commit 8104bcdb2612fdda95169ddc3b49747b2ff98d24 Author: Oliver Hartkopp Date: Fri Jul 24 12:25:52 2026 +0200 can: bcm: fix CAN frame rx/tx statistics commit e6c24ba95fc3f1b5e1dcd28b1c6e59ef61a9daa5 upstream. KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation. Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-4-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Signed-off-by: Sasha Levin commit 19b1994069dd29478ba767de1f98f14a088198dc Author: Oliver Hartkopp Date: Fri Jul 24 12:25:51 2026 +0200 can: bcm: add locking when updating filter and timer values commit 749179c2e25b95d22499ed29096b3e02d6dfd2b4 upstream. KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock. Fixes: c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates") Reported-by: syzbot+75e5e4ae00c3b4bb544e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-can/6975d5cf.a00a0220.33ccc7.0022.GAE@google.com/ Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260714-bcm_fixes-v15-3-562f7e3e42da@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Oliver Hartkopp Signed-off-by: Sasha Levin commit ec9daa8fd1b6f45545c9839dca55bd867fad9e13 Author: Phil Rosenthal Date: Sat Jul 18 12:50:23 2026 -0400 KVM: x86/mmu: Fix use-after-free on vendor module reload commit 52f2f7c30126037975389aa04d24c506a5177c35 upstream. mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report. Fixes: cb498ea2ce1d ("KVM: Portability: Combine kvm_init and kvm_init_x86") Cc: stable@vger.kernel.org Signed-off-by: Phil Rosenthal Message-ID: <20260718-kvm-mmu-cache-uaf-v3-1-e103b93c74e1@phil.gs> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 8001d2ce9d9bd09118ce523aef595aa094573ae3 Author: Hyunwoo Kim Date: Fri Jul 17 12:30:11 2026 +0200 KVM: nVMX: Hide shadow VMCS right after VMCLEAR commit 622ebfac01ba4f9c0060cebd41257fe46fc4a0b3 upstream. free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed. Fixes: 355f4fb1405e ("kvm: nVMX: VMCLEAR an active shadow VMCS after last use") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit dd50ad7935d57885318c5e9f3a784f2343fbcb59 Author: Venkatesh Srinivas Date: Wed Jul 15 23:42:35 2026 +0000 KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN commit e800decd9c0ac4349bcd8f8f9b29fd21fe93165e upstream. On Intel platforms with a VMX preemption timer and APICv, if a VMM calls KVM_GET_LAPIC before KVM_GET_MSRS to save the vCPU state, it is possible to lose a pending timer interrupt. If the thread running these ioctls is migrated to another core after calling KVM_GET_LAPIC but before KVM_GET_MSRS and the guest is using their LAPIC timer in TSC-deadline mode, not only does the save LAPIC state not carry the pending interrupt, the TSCDEADLINE MSR will be zeroed. After migration across CPUs, KVM_GET_MSRS calls vcpu_load, posting the interrupt and clearing the MSR: vcpu_load() -> kvm_arch_vcpu_load() -> kvm_lapic_restart_hv_timer() -> start_hv_timer() -> apic_timer_expired() -> kvm_apic_inject_pending_timer_irqs() . post interrupt into the LAPIC state . clear IA32_TSCDEADLINE The saved LAPIC state will be missing the pending interrupt and the saved MSR will be zero. Oops. Fix by only posting an interrupt when we're attempting to enter the guest (vcpu->wants_to_run == true), not for vcpu_load from other paths. Assisted-by: gemini:gemini-3.1-pro-preview Debugged-by: David Matlack Debugged-by: Sean Christopherson Debugged-by: Jim Mattson Debugged-by: James Houghton Signed-off-by: Venkatesh Srinivas Message-ID: <20260715234234.15382-2-venkateshs@chromium.org> Reviewed-by: James Houghton Reviewed-by: Chao Gao Cc: stable@vger.kernel.org Fixes: ae95f566b3d2 ("KVM: X86: TSCDEADLINE MSR emulation fastpath", 2020-05-15) Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f3477a6a4164f15287444eda685b5f6405dbd1e5 Author: Sean Christopherson Date: Mon Jul 13 08:15:33 2026 -0700 KVM: x86: Check for invalid/obsolete root *after* making MMU pages available commit 2abd5287f08319fa35764566b15c6e22cb1068db upstream. Check for a "stale" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is "fine", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, "KVM: MMU: ignore zapped root pagetables"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately. Reported-by: Hyunwoo Kim Fixes: f95eec9bed76 ("KVM: x86/mmu: Don't put invalid SPs back on the list of active pages") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 865dfe76c150baee84a4f4796bcc3223e00d8147 Author: Heiko Carstens Date: Tue May 19 13:03:15 2026 +0200 seqlock: Allow UBSAN_ALIGNMENT to fail optimizing commit 88331c4ec23a28c1006ec532fa64763d4c695e90 upstream. With gcc-15 and gcc-16 with UBSAN_ALIGNMENT enabled the compiler fails to inline and optimize __scoped_seqlock_bug() away on s390: s390x-16.1.0-ld: kernel/sched/build_policy.o: in function `__scoped_seqlock_next': /.../seqlock.h:1286:(.text+0x22030): undefined reference to `__scoped_seqlock_bug' Fix this by adding UBSAN_ALIGNMENT to the list of config options where a not inlined empty __scoped_seqlock_bug() is allowed. Closes: https://lore.kernel.org/r/20260515092057.810542-1-arnd@kernel.org/ Reported-by: Arnd Bergmann Signed-off-by: Heiko Carstens Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20260519110315.1385307-1-hca@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 3958b1aeef43ba635ee7c3086986c6c7965352b4 Author: Peter Zijlstra Date: Tue Oct 28 09:56:38 2025 +0100 seqlock: Allow KASAN to fail optimizing commit b94d45b6bbb42571ec225d3be0e7457c8765a5b4 upstream. Some KASAN builds are failing to properly optimize this code -- luckily we don't care about core quality for KASAN builds, so just exclude it. Reported-by: kernel test robot Signed-off-by: Peter Zijlstra (Intel) Closes: https://lore.kernel.org/oe-kbuild-all/202510251641.idrNXhv5-lkp@intel.com/ Signed-off-by: Greg Kroah-Hartman commit ec46baf830825da915aff1d4d0b417cb556b169a Author: Peter Zijlstra Date: Thu Dec 4 11:43:32 2025 +0100 seqlock: Cure some more scoped_seqlock() optimization fails commit 90dfeef1cd38dff19f8b3a752d13bfd79f0f7694 upstream. Arnd reported an x86 randconfig using gcc-15 tripped over __scoped_seqlock_bug(). Turns out GCC chose not to inline the scoped_seqlock helper functions and as such was not able to optimize properly. [ mingo: Clang fails the build too in some circumstances. ] Reported-by: Arnd Bergmann Tested-by: Arnd Bergmann Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Cc: Oleg Nesterov Link: https://patch.msgid.link/20251204104332.GG2528459@noisy.programming.kicks-ass.net Signed-off-by: Greg Kroah-Hartman commit 8e39ed92d7c5c6bfc08dc45153916f49a4e98bab Author: Kiryl Shutsemau Date: Wed Jul 22 12:01:23 2026 +0100 fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race commit 04718f7c9290f95385f0dd328758753dc1c36dec upstream. Patch series "userfaultfd/pagemap: pre-existing fixes". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry Reported-by: Sashiko AI review . They are independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against. Link: https://lore.kernel.org/20260529172331.356655-1-kas@kernel.org Link: https://lore.kernel.org/20260529172331.356655-2-kas@kernel.org Link: https://lore.kernel.org/all/20260526130509.2748441-1-kirill@shutemov.name/ [1] Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs") Signed-off-by: Kiryl Shutsemau Reported-by: Sashiko AI review Reviewed-by: Lorenzo Stoakes Reviewed-by: Dev Jain Cc: David Hildenbrand Cc: Michal Hocko Cc: Mike Rapoport Cc: Peter Xu Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Balbir Singh Cc: Signed-off-by: Andrew Morton [ kas: adapt to the pre-softleaf idiom; apply the huge_ptep_modify_prot_start()/commit() fix to the present-PTE (!huge_pte_none()) branch ] Signed-off-by: Kiryl Shutsemau (Meta) Signed-off-by: Sasha Levin commit 89890a5fcefadad81a778863c146f18e85ab34c2 Author: Ryosuke Yasuoka Date: Mon Jul 13 22:01:00 2026 +0900 drm/virtio: fix deadlock in display_info_cb by removing hotplug from dequeue worker [ Upstream commit d1b894c5bbb3fee0012bd14356286dc2384e8213 ] A probe-time deadlock can occur between the dequeue worker and drm_client_register(). During probe, drm_client_register() holds clientlist_mutex and calls the fbdev hotplug callback, which triggers an atomic commit that ends up sleeping in virtio_gpu_queue_ctrl_sgs() waiting for virtqueue space. The dequeue worker that would free that space calls virtio_gpu_cmd_get_display_info_cb(), which invokes drm_kms_helper_hotplug_event() -> drm_client_dev_hotplug(), attempting to acquire the same clientlist_mutex. Since wake_up() is only called after the resp_cb loop, the probe thread is never woken and both threads deadlock. Fix this by removing the hotplug notification from virtio_gpu_cmd_get_display_info_cb(). The display data (outputs[i].info) is still updated synchronously in the callback. For the init path, drm_client_register() already fires an initial hotplug when the client is registered, which picks up the connector state updated by display_info_cb. For the runtime config_changed path, add a wait_event_timeout() in config_changed_work_func() so that display_info_cb updates the connector data before the hotplug notification is sent. Also replace drm_helper_hpd_irq_event() with drm_kms_helper_hotplug_event() since virtio-gpu never calls drm_kms_helper_poll_init() and thus drm_helper_hpd_irq_event() always returns false without doing anything. Fixes: 27655b9bb9f0 ("drm/client: Send hotplug event after registering a client") Closes: https://syzkaller.appspot.com/bug?id=d6dd6f86d3aaf7eebe7406e45c1c6e549453f224 Closes: https://syzkaller.appspot.com/bug?id=908bd910da5dd79b88de4cf7baf376cc873a922e Suggested-by: Dmitry Osipenko Signed-off-by: Ryosuke Yasuoka Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260713-virtiogpu_syzbot-v2-1-2958fa37d46d@redhat.com Signed-off-by: Sasha Levin commit f6410d18c1e2da325df02be989d5bca5ed38b086 Author: Brian Witte Date: Wed Feb 4 14:26:36 2026 -0600 netfilter: nf_tables: revert commit_mutex usage in reset path [ Upstream commit 7f261bb906bf527c4a6e2a646e2d5f3679f2a8bc ] It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this. Fixes: bd662c4218f9 ("netfilter: nf_tables: Add locking for NFT_MSG_GETOBJ_RESET requests") Fixes: 3d483faa6663 ("netfilter: nf_tables: Add locking for NFT_MSG_GETSETELEM_RESET requests") Fixes: 3cb03edb4de3 ("netfilter: nf_tables: Add locking for NFT_MSG_GETRULE_RESET requests") Link: https://lore.kernel.org/all/aUh_3mVRV8OrGsVo@strlen.de/ Reported-by: Closes: https://syzkaller.appspot.com/bug?extid=ff16b505ec9152e5f448 Signed-off-by: Brian Witte Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 0c8a9022f4c56066f13f8285d562fceeb76325be Author: Brian Witte Date: Wed Feb 4 14:26:38 2026 -0600 netfilter: nft_quota: use atomic64_xchg for reset [ Upstream commit 30c4d7fb59ac4c8d7fa7937df11eed10b368fa11 ] Use atomic64_xchg() to atomically read and zero the consumed value on reset, which is simpler than the previous read+sub pattern and doesn't require lock serialization. Fixes: bd662c4218f9 ("netfilter: nf_tables: Add locking for NFT_MSG_GETOBJ_RESET requests") Fixes: 3d483faa6663 ("netfilter: nf_tables: Add locking for NFT_MSG_GETSETELEM_RESET requests") Fixes: 3cb03edb4de3 ("netfilter: nf_tables: Add locking for NFT_MSG_GETRULE_RESET requests") Suggested-by: Pablo Neira Ayuso Signed-off-by: Brian Witte Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit cd968dcdec6aee79a2d399e4f6e0eca63c3b45e1 Author: Brian Witte Date: Wed Feb 4 14:26:37 2026 -0600 netfilter: nft_counter: serialize reset with spinlock [ Upstream commit 779c60a5190c42689534172f4b49e927c9959e4e ] Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later. Fixes: bd662c4218f9 ("netfilter: nf_tables: Add locking for NFT_MSG_GETOBJ_RESET requests") Fixes: 3d483faa6663 ("netfilter: nf_tables: Add locking for NFT_MSG_GETSETELEM_RESET requests") Fixes: 3cb03edb4de3 ("netfilter: nf_tables: Add locking for NFT_MSG_GETRULE_RESET requests") Suggested-by: Florian Westphal Signed-off-by: Brian Witte Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 55904f1a4689afd31902addd868ae25456be1891 Author: Daniel Borkmann Date: Wed Jul 22 15:39:08 2026 +0800 selftests/bpf: Add tests for ld_{abs,ind} failure path in subprogs commit e0fcb42bc6f41bab2895757d6610616b3820eff7 upstream. Extend the verifier_ld_ind BPF selftests with subprogs containing ld_{abs,ind} and craft the test in a way where the invalid register read is rejected in the fixed case. Also add a success case each, and add additional coverage related to the BTF return type enforcement. # LDLIBS=-static PKG_CONFIG='pkg-config --static' ./vmtest.sh -- ./test_progs -t verifier_ld_ind [...] #611/1 verifier_ld_ind/ld_ind: check calling conv, r1:OK #611/2 verifier_ld_ind/ld_ind: check calling conv, r1 @unpriv:OK #611/3 verifier_ld_ind/ld_ind: check calling conv, r2:OK #611/4 verifier_ld_ind/ld_ind: check calling conv, r2 @unpriv:OK #611/5 verifier_ld_ind/ld_ind: check calling conv, r3:OK #611/6 verifier_ld_ind/ld_ind: check calling conv, r3 @unpriv:OK #611/7 verifier_ld_ind/ld_ind: check calling conv, r4:OK #611/8 verifier_ld_ind/ld_ind: check calling conv, r4 @unpriv:OK #611/9 verifier_ld_ind/ld_ind: check calling conv, r5:OK #611/10 verifier_ld_ind/ld_ind: check calling conv, r5 @unpriv:OK #611/11 verifier_ld_ind/ld_ind: check calling conv, r7:OK #611/12 verifier_ld_ind/ld_ind: check calling conv, r7 @unpriv:OK #611/13 verifier_ld_ind/ld_abs: subprog early exit on ld_abs failure:OK #611/14 verifier_ld_ind/ld_ind: subprog early exit on ld_ind failure:OK #611/15 verifier_ld_ind/ld_abs: subprog with both paths safe:OK #611/16 verifier_ld_ind/ld_ind: subprog with both paths safe:OK #611/17 verifier_ld_ind/ld_abs: reject void return subprog:OK #611/18 verifier_ld_ind/ld_ind: reject void return subprog:OK #611 verifier_ld_ind:OK Summary: 1/18 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260408191242.526279-4-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Philo Lu Signed-off-by: Sasha Levin commit ce01a4e5cfac7adbe0be565f90cd32ecbb2f8337 Author: Daniel Borkmann Date: Wed Jul 22 15:39:07 2026 +0800 bpf: Fix ld_{abs,ind} failure path analysis in subprogs commit ee861486e377edc55361c08dcbceab3f6b6577bd upstream. Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 ("bpf: Add abnormal return checks."). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side. Fixes: 09b28d76eac4 ("bpf: Add abnormal return checks.") Reported-by: STAR Labs SG Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20260408191242.526279-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov [ Dropped visit_abnormal_return_insn changes: depends on 7.0 symbols from e40f5a6bf88a ("bpf: correct stack liveness for tail calls"); Hunk1: adapted IS_ERR/PTR_ERR to !branch/-EFAULT to match push_stack() NULL-on-failure convention. ] Signed-off-by: Philo Lu Signed-off-by: Sasha Levin commit bffc0b27e457ce5d958379fbf11f00e3f5be4773 Author: Guixiong Wei Date: Tue Jul 21 23:07:57 2026 +0800 platform/x86/intel-uncore-freq: Fix current_freq_khz after CPU hotplug commit 6b63520ed14b17bbe9c2103debbd2152dde1fba3 upstream. When the last CPU of a legacy uncore die goes offline, uncore_freq_remove_die_entry() clears control_cpu. During CPU hotplug re-add, uncore_freq_add_entry() still populates sysfs attributes before assigning the new control CPU. As a result, the current frequency read returns -ENXIO and current_freq_khz is omitted from the recreated sysfs group. Assign control_cpu before the initial read paths and before create_attr_group() so sysfs recreation uses the new online CPU. If sysfs creation fails, restore control_cpu to -1 to keep the error path state consistent. Fixes: 4d73c6772ab7 ("platform/x86: intel-uncore-freq: Conditionally create attribute for read frequency") Cc: stable@vger.kernel.org Acked-by: Srinivas Pandruvada Link: https://patch.msgid.link/20260602020752.3126-1-weiguixiong@bytedance.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Guixiong Wei Signed-off-by: Sasha Levin