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/[email protected] 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: [email protected] Signed-off-by: Thierry Reding Link: https://patch.msgid.link/[email protected] 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/[email protected] 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: [email protected] Fixes: 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") Reported-by: "Borah, Chaitanya Kumar" Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Andrei Kuchynski Tested-by: Chaitanya Kumar Borah Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/[email protected] 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/[email protected] Cc: [email protected] 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/[email protected] 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 [email protected] Fixes: e8babb280b5e ("drm/xe: Convert multiple bind ops into single job") Suggested-by: Matthew Auld Cc: [email protected] 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/[email protected] (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/[email protected] 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/[email protected] 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/[email protected] 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: [email protected] # v5.12+ Cc: Ankit Nautiyal Reviewed-by: Ankit Nautiyal Link: https://patch.msgid.link/[email protected] 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/[email protected] Reviewed-by: Ankit Nautiyal Stable-dep-of: f8a9262c7a6f ("drm/i915/vrr: require valid min/max vfreq for VRR") Signed-of…