<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/xe, branch v6.18.36</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.36</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.36'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-19T11:44:13+00:00</updated>
<entry>
<title>drm/xe: Clear pending_disable before signaling suspend fence</title>
<updated>2026-06-19T11:44:13+00:00</updated>
<author>
<name>Tangudu Tilak Tirumalesh</name>
<email>tilak.tirumalesh.tangudu@intel.com</email>
</author>
<published>2026-06-03T06:52:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4c10fd55187aaf7882bbb281ca37d6729198821e'/>
<id>urn:sha1:4c10fd55187aaf7882bbb281ca37d6729198821e</id>
<content type='text'>
commit 54f2a0442a30fe7a0f6bc8345e81f8b2db8effbd upstream.

In the schedule-disable done path for suspend, we
signal the suspend fence before clearing pending_disable.

That wakeup can let suspend_wait complete and resume be queued
immediately. The resume path may then reach enable_scheduling()
while pending_disable is still set and hit the
!exec_queue_pending_disable(q) assertion.

Fix this by clearing pending_disable before signaling
the suspend fence, so any resumed transition observes a
consistent state.

Fixes: 87651f31ae4e ("drm/xe/guc_submit: fix race around suspend_pending")
Cc: stable@vger.kernel.org # v7.0+
Signed-off-by: Tangudu Tilak Tirumalesh &lt;tilak.tirumalesh.tangudu@intel.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thomas.hellstrom@linux.intel.com&gt;
Signed-off-by: Daniele Ceraolo Spurio &lt;daniele.ceraolospurio@intel.com&gt;
Link: https://patch.msgid.link/20260603065217.3131066-3-tilak.tirumalesh.tangudu@intel.com
(cherry picked from commit 4b1ae138b0e103d753773956a84eebc2edbf62c4)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/xe/display: fix oops in suspend/shutdown without display</title>
<updated>2026-06-19T11:44:13+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2026-05-15T16:09:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0f68ddfaaebfbb5581ee931779757d31f4dc9e24'/>
<id>urn:sha1:0f68ddfaaebfbb5581ee931779757d31f4dc9e24</id>
<content type='text'>
commit 68938cc08e23a94fd881e845837ff918de005ce7 upstream.

The xe driver keeps track of whether to probe display, and whether
display hardware is there, using xe-&gt;info.probe_display. It gets set to
false if there's no display after intel_display_device_probe(). However,
the display may also be disabled via fuses, detected at a later time in
intel_display_device_info_runtime_init().

In this case, the xe driver does for_each_intel_crtc() on uninitialized
mode config in xe_display_flush_cleanup_work(), leading to a NULL
pointer dereference, and generally calls display code with display info
cleared.

Check for intel_display_device_present() after
intel_display_device_info_runtime_init(), and reset
xe-&gt;info.probe_display as necessary. Also do unset_display_features()
for completeness, although display runtime init has already done
that. This will need to be unified across all cases later.

Move intel_display_device_info_runtime_init() call slightly earlier,
similar to i915, to avoid a bunch of unnecessary setup for no display
cases.

Note #1: The xe driver has no business doing low level display plumbing
like for_each_intel_crtc() to begin with. It all needs to happen in
display code.

Note #2: The actual bug is present already in commit 44e694958b95
("drm/xe/display: Implement display support"), but the oops was likely
introduced later at commit ddf6492e0e50 ("drm/xe/display: Make display
suspend/resume work on discrete").

Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7904
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/6150
Cc: stable@vger.kernel.org # v6.8+
Reviewed-by: Suraj Kandpal &lt;suraj.kandpal@intel.com&gt;
Link: https://patch.msgid.link/20260515160920.1082842-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
(cherry picked from commit 7c3eb9f47533220888a67266448185fd0775d4da)
Signed-off-by: Matthew Brost &lt;matthew.brost@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/xe: fix refcount leak in xe_range_fence_insert()</title>
<updated>2026-06-19T11:44:02+00:00</updated>
<author>
<name>Wentao Liang</name>
<email>vulab@iscas.ac.cn</email>
</author>
<published>2026-06-10T17:27:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=361e97d81331ca15fabf80b028b4caeb4a08862c'/>
<id>urn:sha1:361e97d81331ca15fabf80b028b4caeb4a08862c</id>
<content type='text'>
[ Upstream commit ba36786b21d19082e696eda85bfcd49e7071944a ]

xe_range_fence_insert() acquires a reference on fence via
dma_fence_get() and stores it in rfence-&gt;fence.  It then calls
dma_fence_add_callback() and handles two cases: when the callback
is successfully registered (err == 0) the fence is transferred to
the tree for later cleanup; when the fence is already signaled
(err == -ENOENT) it manually drops the extra reference with
dma_fence_put(fence).

However, dma_fence_add_callback() can fail with other errors
(e.g. -EINVAL) and in that case the code falls through to the free:
label without releasing the acquired reference, leaking it.

Fix the leak by adding an else branch that calls dma_fence_put()
before jumping to free: for any error other than -ENOENT.

Fixes: 845f64bdbfc9 ("drm/xe: Introduce a range-fence utility")
Signed-off-by: Wentao Liang &lt;vulab@iscas.ac.cn&gt;
Reviewed-by: Matthew Brost &lt;matthew.brost@intel.com&gt;
Signed-off-by: Matthew Brost &lt;matthew.brost@intel.com&gt;
Link: https://patch.msgid.link/20260610172705.3450560-1-matthew.brost@intel.com
(cherry picked from commit 98c4a4201290823c2c5c7ba21692bd9a64b61021)
Signed-off-by: Matthew Brost &lt;matthew.brost@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/xe: Restore IDLEDLY regiter on engine reset</title>
<updated>2026-06-09T10:28:28+00:00</updated>
<author>
<name>Balasubramani Vivekanandan</name>
<email>balasubramani.vivekanandan@intel.com</email>
</author>
<published>2026-05-22T16:35:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=75cf24709037c671c62c49cd12285893bd679eb2'/>
<id>urn:sha1:75cf24709037c671c62c49cd12285893bd679eb2</id>
<content type='text'>
[ Upstream commit f657a6a3ba4c20bc01f5be3752d53498ee1bfe35 ]

Wa_16023105232 programs the register IDLEDLY. The register is reset
whenever the engine is reset. Therefore it should be added to the GuC
save-restore register list for it to be restored after reset.

Fixes: 7c53ff050ba8 ("drm/xe: Apply Wa_16023105232")
Reviewed-by: Matt Roper &lt;matthew.d.roper@intel.com&gt;
Link: https://patch.msgid.link/20260522163531.1365540-2-balasubramani.vivekanandan@intel.com
Signed-off-by: Balasubramani Vivekanandan &lt;balasubramani.vivekanandan@intel.com&gt;
(cherry picked from commit df1cfe24743a93b71eab27687e148ab8ae9b69e3)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/xe/oa: Fix exec_queue leak on width check in stream open</title>
<updated>2026-06-01T15:51:07+00:00</updated>
<author>
<name>Shuicheng Lin</name>
<email>shuicheng.lin@intel.com</email>
</author>
<published>2026-05-14T20:32:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=04ef7592eaadd9ca8f8f66e76452f73525cff819'/>
<id>urn:sha1:04ef7592eaadd9ca8f8f66e76452f73525cff819</id>
<content type='text'>
[ Upstream commit 4d25342543c01310fc4e0cba7cb17c775e2421e2 ]

In xe_oa_stream_open_ioctl(), when param.exec_q-&gt;width &gt; 1 the
function returns -EOPNOTSUPP directly, skipping the existing
err_exec_q cleanup path. The exec_queue reference obtained by
xe_exec_queue_lookup() is leaked.

The exec queue holds a reference on the xe_file, which is only
dropped during queue teardown. The leaked lookup ref is not on
the file's exec_queue xarray, so file close cannot release it.
This keeps both the exec queue and the file private state pinned
indefinitely.

Jump to err_exec_q instead of returning directly so the reference
is released.

Fixes: f0ed39830e60 ("xe/oa: Fix query mode of operation for OAR/OAC")
Assisted-by: Claude:claude-opus-4.6
Reviewed-by: Ashutosh Dixit &lt;ashutosh.dixit@intel.com&gt;
Link: https://patch.msgid.link/20260514203210.593488-1-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin &lt;shuicheng.lin@intel.com&gt;
(cherry picked from commit 339fa0be9e4a5d69fa47e91f4a36574224fb478f)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/xe/pf: Fix CFI failure in debugfs access</title>
<updated>2026-06-01T15:51:03+00:00</updated>
<author>
<name>Mohanram Meenakshisundaram</name>
<email>mohanram.meenakshisundaram@intel.com</email>
</author>
<published>2026-05-14T17:49:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6c9e9272bc37f1bebab59f244c3e4c296a573dbc'/>
<id>urn:sha1:6c9e9272bc37f1bebab59f244c3e4c296a573dbc</id>
<content type='text'>
[ Upstream commit 96bf49b526e2d03a2b7f6e861925a08f46ed0d28 ]

Reading debugfs file (/sys/kernel/debug/dri/0/gt*/pf/adverse_events)
with CFI (Control Flow Integrity) enabled, the kernel panics at
xe_gt_debugfs_simple_show+0x82/0xc0.

xe_gt_debugfs_simple_show() declare a function pointer expecting int
return type, but xe_gt_sriov_pf_monitor_print_events() is void return
type, leading to CFI failure and kernel panic.

[507620.973657] CFI failure at xe_gt_debugfs_simple_show+0x82/0xc0 [xe]
(target: xe_gt_sriov_pf_monitor_print_events+0x0/0x130 [xe]; expected
type: 0xd72c7139)

Fix xe_gt_sriov_pf_monitor_print_events() function by updating to return
an int type.

Fixes: 1c99d3d3edab ("drm/xe/pf: Expose PF monitor details via debugfs")
Signed-off-by: Mohanram Meenakshisundaram &lt;mohanram.meenakshisundaram@intel.com&gt;
Reviewed-by: Michal Wajdeczko &lt;michal.wajdeczko@intel.com&gt;
Signed-off-by: Michal Wajdeczko &lt;michal.wajdeczko@intel.com&gt;
Link: https://patch.msgid.link/20260514174918.1556357-2-mohanram.meenakshisundaram@intel.com
(cherry picked from commit ff1d386a8359746d9699ac30336e3b0684c68958)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/xe/vf: Fix signature of print functions</title>
<updated>2026-06-01T15:51:02+00:00</updated>
<author>
<name>Michal Wajdeczko</name>
<email>michal.wajdeczko@intel.com</email>
</author>
<published>2026-05-14T15:57:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dc26e00860a15e5fbe000a74276dccd1690a0420'/>
<id>urn:sha1:dc26e00860a15e5fbe000a74276dccd1690a0420</id>
<content type='text'>
[ Upstream commit 9bb2f1d7e6e58b8e434ddc2048c661bf87ccdf2a ]

We have plugged-in existing VF print functions into our GT debugfs
show helper as-is, but we missed that the helper expects functions
to return int, while they were defined as void. This can lead to
errors being reported when CFI is enabled.

Fixes: 63d8cb8fe3dd ("drm/xe/vf: Expose SR-IOV VF attributes to GT debugfs")
Signed-off-by: Michal Wajdeczko &lt;michal.wajdeczko@intel.com&gt;
Cc: Mohanram Meenakshisundaram &lt;mohanram.meenakshisundaram@intel.com&gt;
Reviewed-by: Shuicheng Lin &lt;shuicheng.lin@intel.com&gt;
Link: https://patch.msgid.link/20260514155726.7165-1-michal.wajdeczko@intel.com
(cherry picked from commit 314e31c9a8a1c421ee4f7f755b9348aefbbca090)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/xe/gsc: Fix double-free of managed BO in error path</title>
<updated>2026-06-01T15:51:02+00:00</updated>
<author>
<name>Shuicheng Lin</name>
<email>shuicheng.lin@intel.com</email>
</author>
<published>2026-05-11T15:41:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2c890e71ae26fa32f5a96c3694b71a2c310940e7'/>
<id>urn:sha1:2c890e71ae26fa32f5a96c3694b71a2c310940e7</id>
<content type='text'>
[ Upstream commit d3ded53fab90996e7d94a39049e11962dd066725 ]

The error path in xe_gsc_init_post_hwconfig() explicitly frees a BO
allocated with xe_managed_bo_create_pin_map() via
xe_bo_unpin_map_no_vm(). Since the managed BO already has a devm
cleanup action registered, this causes a double-free when devm
unwinds during probe failure.

Remove the explicit free and let devm handle it, consistent with
all other xe_managed_bo_create_pin_map() callers.

Fixes: 2e5d47fe7839 ("drm/xe/uc: Use managed bo for HuC and GSC objects")
Reviewed-by: Daniele Ceraolo Spurio &lt;daniele.ceraolospurio@intel.com&gt;
Assisted-by: Claude:claude-opus-4.6
Link: https://patch.msgid.link/20260511154134.223696-1-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin &lt;shuicheng.lin@intel.com&gt;
(cherry picked from commit 71d61e3e299a17139e47f980a4d6f425b2c59bf7)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/xe/hdcp: Add NULL check for media_gt in intel_hdcp_gsc_check_status()</title>
<updated>2026-06-01T15:50:36+00:00</updated>
<author>
<name>Gustavo Sousa</name>
<email>gustavo.sousa@intel.com</email>
</author>
<published>2026-05-22T18:47:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=814326e86e929b865020ff44f4576dbdfe3f7ff3'/>
<id>urn:sha1:814326e86e929b865020ff44f4576dbdfe3f7ff3</id>
<content type='text'>
commit 60a1e131a811b68703da58fd805ab359b704ab03 upstream.

When media GT is disabled via configfs, there is no allocation for
media_gt, which is kept as NULL.  In such scenario,
intel_hdcp_gsc_check_status() results in a kernel pagefault error due to
&amp;gt-&gt;uc.gsc being evaluated as an invalid memory address.

Fix that by introducing a NULL check on media_gt and bailing out early
if so.

While at it, also drop the NULL check for gsc, since it can't be NULL if
media_gt is not NULL.

v2:
  - Get address for gsc only after checking that gt is not NULL.
    (Shuicheng)
  - Drop the NULL check for gsc. (Shuicheng)
v3:
  - Add "Fixes" and "Cc: &lt;stable...&gt;" tags. (Matt)

Fixes: 4af50beb4e0f ("drm/xe: Use gsc_proxy_init_done to check proxy status")
Cc: &lt;stable@vger.kernel.org&gt; # v6.10+
Reviewed-by: Matt Roper &lt;matthew.d.roper@intel.com&gt;
Reviewed-by: Shuicheng Lin &lt;shuicheng.lin@intel.com&gt;
Link: https://patch.msgid.link/20260416-check-for-null-media_gt-in-intel_hdcp_gsc_check_status-v2-1-9adb9fd3b621@intel.com
Signed-off-by: Gustavo Sousa &lt;gustavo.sousa@intel.com&gt;
(cherry picked from commit bfaf87e84ca3ca3f6e275f9ae56da47a8b55ffd1)
Signed-off-by: Matthew Brost &lt;matthew.brost@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/xe/dma-buf: fix UAF with retry loop</title>
<updated>2026-05-23T11:07:19+00:00</updated>
<author>
<name>Matthew Auld</name>
<email>matthew.auld@intel.com</email>
</author>
<published>2026-05-08T10:26:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=39fdac6be02eb7c3460518c1c4085f75f935c4ce'/>
<id>urn:sha1:39fdac6be02eb7c3460518c1c4085f75f935c4ce</id>
<content type='text'>
commit 155a372a1cc50fa93387c5d3cdfd614a61e1afd1 upstream.

Retry doesn't work here, since bo will be freed on error, leading to
UAF. However, now that we do the alloc &amp; init before the attach, we can
now combine this as one unit and have the init do the alloc for us. This
should make the retry safe.

Reported by Sashiko.

v2: Fix up the error unwind (CI)

Closes: https://sashiko.dev/#/patchset/20260506184332.86743-2-matthew.auld%40intel.com
Fixes: eb289a5f6cc6 ("drm/xe: Convert xe_dma_buf.c for exhaustive eviction")
Signed-off-by: Matthew Auld &lt;matthew.auld@intel.com&gt;
Cc: Thomas Hellström &lt;thomas.hellstrom@linux.intel.com&gt;
Cc: Matthew Brost &lt;matthew.brost@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v6.18+
Reviewed-by: Thomas Hellström &lt;thomas.hellstrom@linux.intel.com&gt;
Link: https://patch.msgid.link/20260508102635.149172-4-matthew.auld@intel.com
(cherry picked from commit 479669418253e0f27f8cf5db01a731352ea592e7)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
