All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH V2] drm/xe: fix UAF race between exec-queue teardown and GuC CT pause-abort
@ 2026-11-14  3:57 Tejas Upadhyay
  2026-11-14  4:07 ` ✓ CI.KUnit: success for drm/xe: fix UAF race between exec-queue teardown and GuC CT pause-abort (rev2) Patchwork
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Tejas Upadhyay @ 2026-11-14  3:57 UTC (permalink / raw)
  To: intel-xe; +Cc: himal.prasad.ghimiray, matthew.brost, arvind.yadav,
	Tejas Upadhyay

xe_guc_submit_pause_abort() walks guc->submission_state.exec_queue_lookup
and unconditionally calls guc_exec_queue_kill() on every entry found,
without verifying the queue hasn't already begun/finished its own
independent teardown. guc_exec_queue_fini() (run once a queue's own
refcount drops to zero via the normal close path) only erases its xarray
entry partway through its body, via release_guc_id() -- so there is a
window where a queue's refcount is already 0 but its xarray entry is
still present.

This was caught as a debug assertion firing on both BMG and CRI:

	xe 0000:00:03.0: [drm] Assertion `kref_read(&q->refcount)` failed!
	WARNING: drivers/gpu/drm/xe/xe_guc_submit.c:2242 at guc_exec_queue_kill+0x2e2/0x360
	 guc_exec_queue_kill+0x2e2/0x360 [xe]
	 xe_guc_submit_pause_abort+0x8e/0xf0 [xe]
	 guc_submit_fini+0x11f/0x180 [xe]
	 devm_action_release+0x15/0x30
	 ...
	 device_release_driver_internal+0x230/0x270
	 unbind_store+0xac/0xc0                          [BMG: igt@xe_configfs, sysfs unbind]
	 pci_iov_remove_virtfn+0xd1/0x140
	 sriov_disable+0x42/0x100
	 pci_disable_sriov+0x23/0x40
	 xe_pci_sriov_configure+0x2b9/0x1350 [xe]
	 sriov_numvfs_store+0x136/0x1f0           [CRI: igt@xe_pmu, SR-IOV VF disable]

Pin the queue with kref_get_unless_zero() before touching it, skipping the
redundant guc_exec_queue_kill() for entries that have already
independently reached a zero refcount instead of operating on an object
that's already being torn down elsewhere.

V2(Sashiko):
-xe_sched_submission_start(sched) must still run unconditionally for every
non-duplicate entry regardless of that refcount check

Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
---
 drivers/gpu/drm/xe/xe_guc_submit.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
index d76f125f9c3a..c333010693c2 100644
--- a/drivers/gpu/drm/xe/xe_guc_submit.c
+++ b/drivers/gpu/drm/xe/xe_guc_submit.c
@@ -3310,8 +3310,25 @@ void xe_guc_submit_pause_abort(struct xe_guc *guc)
 		if (q->guc->id != index)
 			continue;
 
+		/*
+		 * Resume the scheduler unconditionally so any pending message
+		 * (e.g. STATIC_MSG_CLEANUP queued by a concurrent
+		 * guc_exec_queue_destroy()) still gets processed, even if q
+		 * is skipped below.
+		 */
 		xe_sched_submission_start(sched);
+
+		/*
+		 * q may have already dropped to a zero refcount via its own
+		 * independent teardown (guc_exec_queue_fini(), xarray entry
+		 * not yet erased); let that teardown finish via the resumed
+		 * scheduler instead of killing an object already being freed.
+		 */
+		if (!kref_get_unless_zero(&q->refcount))
+			continue;
+
 		guc_exec_queue_kill(q);
+		xe_exec_queue_put(q);
 	}
 	mutex_unlock(&guc->submission_state.lock);
 }
-- 
2.52.0


^ permalink raw reply related	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-11-14  4:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-14  3:57 [PATCH V2] drm/xe: fix UAF race between exec-queue teardown and GuC CT pause-abort Tejas Upadhyay
2026-11-14  4:07 ` ✓ CI.KUnit: success for drm/xe: fix UAF race between exec-queue teardown and GuC CT pause-abort (rev2) Patchwork
2026-11-14  4:32 ` [PATCH V2] drm/xe: fix UAF race between exec-queue teardown and GuC CT pause-abort sashiko-bot
2026-11-14  4:39 ` ✓ Xe.CI.BAT: success for drm/xe: fix UAF race between exec-queue teardown and GuC CT pause-abort (rev2) Patchwork

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.