From: sashiko-bot@kernel.org
To: "Satyanarayana K V P" <satyanarayana.k.v.p@intel.com>,
intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v7 1/3] drm/xe: Prevent VF memory IRQ from accessing a torn-down engine
Date: Tue, 13 Oct 2026 15:46:17 +0000 [thread overview]
Message-ID: <sashiko-outbox-170039@kernel.org> (raw)
In-Reply-To: <20261013152417.3189567-6-satyanarayana.k.v.p@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe: TOCTOU NULL pointer deref in query_engine_cycles() during unplug
--
commit f3434e1999c04ac6bc30530fad97ca5ad34cad2a
Author: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
drm/xe: Prevent VF memory IRQ from accessing a torn-down engine
This commit invalidates the engine name during engine teardown in
hw_engine_fini() to prevent a NULL pointer dereference in IRQ handlers.
By clearing hwe->name, subsequent engine scans will skip the torn-down
engine.
> diff --git a/drivers/gpu/drm/xe/xe_hw_engine.c b/drivers/gpu/drm/xe/xe_hw_engine.c
> index 265f95c0c8993..55ee0c892c1e8 100644
> --- a/drivers/gpu/drm/xe/xe_hw_engine.c
> +++ b/drivers/gpu/drm/xe/xe_hw_engine.c
> @@ -275,11 +275,22 @@ static const struct engine_info engine_infos[] = {
> static void hw_engine_fini(void *arg)
> {
> struct xe_hw_engine *hwe = arg;
> + struct xe_gt *gt = hwe->gt;
> +
> + if (gt) {
> + struct xe_device *xe = gt_to_xe(gt);
> + unsigned long flags;
>
> - if (hwe->exl_port)
> - xe_execlist_port_destroy(hwe->exl_port);
> + if (hwe->exl_port)
> + xe_execlist_port_destroy(hwe->exl_port);
>
> - hwe->gt = NULL;
> + spin_lock_irqsave(&xe->irq.lock, flags);
> + hwe->name = NULL;
> + hwe->gt = NULL;
> + spin_unlock_irqrestore(&xe->irq.lock, flags);
[Severity: High]
Does this still leave a TOCTOU NULL pointer dereference in
query_engine_cycles() during device unplug?
Device removal (e.g., driver unbind or PCI unplug) invokes
xe_device_remove(), which calls drm_dev_unplug().
Since drm_dev_unplug() waits only for SRCU readers that called
drm_dev_enter(), and neither xe_drm_ioctl() nor query_engine_cycles()
uses drm_dev_enter(), the IOCTL can execute concurrently with the devres
teardown phase.
If hw_engine_fini() runs concurrently, it clears hwe->gt = NULL while
holding xe->irq.lock.
Concurrently, query_engine_cycles() can retrieve the engine via
xe_gt_hw_engine() just before hwe->name is cleared, and then call
hwe_read_timestamp():
drivers/gpu/drm/xe/xe_query.c:query_engine_cycles() {
hwe = xe_gt_hw_engine(gt, user_to_xe_engine_class[eci->engine_class],
eci->engine_instance, true);
if (!hwe)
return -EINVAL;
fw_domain = xe_hw_engine_to_fw_domain(hwe);
xe_with_force_wake(fw_ref, gt_to_fw(gt), fw_domain) {
if (!xe_force_wake_ref_has_domain(fw_ref.domains, fw_domain))
return -EIO;
hwe_read_timestamp(hwe, &resp.engine_cycles, &resp.cpu_timestamp,
&resp.cpu_delta, cpu_clock);
}
}
Inside hwe_read_timestamp(), it dereferences hwe->gt without taking
xe->irq.lock:
drivers/gpu/drm/xe/xe_query.c:hwe_read_timestamp() {
struct xe_mmio *mmio = &hwe->gt->mmio;
...
}
Can this lead to a NULL pointer dereference crash, allowing a local DoS by
triggering driver unbind while executing the query IOCTL?
> + } else {
> + hwe->name = NULL;
> + }
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261013152417.3189567-5-satyanarayana.k.v.p@intel.com?part=1
next prev parent reply other threads:[~2026-10-13 15:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 15:24 [PATCH v7 0/3] Fix kernel crash during driver teardown Satyanarayana K V P
2026-10-13 15:24 ` [PATCH v7 1/3] drm/xe: Prevent VF memory IRQ from accessing a torn-down engine Satyanarayana K V P
2026-10-13 15:46 ` sashiko-bot [this message]
2026-10-13 15:24 ` [PATCH v7 2/3] drm/xe/guc: Protect timeout handling from device unplug Satyanarayana K V P
2026-10-13 15:40 ` sashiko-bot
2026-10-13 15:24 ` [PATCH v7 3/3] drm/xe/gt: Disable GT reset worker before engine teardown Satyanarayana K V P
2026-10-13 15:34 ` ✓ CI.KUnit: success for Fix kernel crash during driver teardown (rev8) Patchwork
2026-10-13 20:40 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-14 4:27 ` ✗ Xe.CI.FULL: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-170039@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=satyanarayana.k.v.p@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.