linux-stable.git/drivers/gpu/drm, branch v6.18.44

drm/tegra: fbdev: Do not assign to struct drm_fb_helper.info

2026-08-09T18:25:29+00:00

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

drm/fb-helper: Fix a locking bug in an error path

2026-08-09T18:25:29+00:00

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

drm/xe/pt: Reset current_op in xe_pt_update_ops_init()

2026-08-09T18:25:29+00:00

[ 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

drm/xe: Add page reclamation info to device info

2026-08-09T18:25:29+00:00

[ 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

drm/xe: Stub out new pagefault layer

2026-08-09T18:25:29+00:00

[ 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

drm/xe: Use SVM range helpers in PT layer

2026-08-09T18:25:29+00:00

[ 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

drm/i915/vrr: require valid min/max vfreq for VRR

2026-08-09T18:25:29+00:00

[ 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

drm/i915/vrr: Check HAS_VRR() first in intel_vrr_is_capable()

2026-08-09T18:25:29+00:00

[ 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

drm/xe: Wait on external BO kernel fences in exec IOCTL

2026-08-09T18:25:28+00:00

[ 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

drm/exec: Remove the index parameter from drm_exec_for_each_locked_obj[_reverse]

2026-08-09T18:25:28+00:00

[ 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