CVE-2026-98391 in Linux
Summary
by MITRE • 10/14/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Guard page-fault worker with runtime PM check
During VM teardown, the VM's runtime PM reference is dropped asynchronously, allowing the device to autosuspend while stale page faults belonging to the now-dead VM are still queued. When the page-fault worker later tries to ack one of these, it calls into guc_ct_send_locked() on an already-suspended device, tripping:
Assertion `!xe_pm_runtime_suspended(xe)` failed! WARNING at xe_device.c:1267 xe_device_assert_mem_access+0x11c/0x140 [xe]
A live VM/exec queue always holds a PM reference while it has outstanding work, so if the device is suspended at ack time, the owning context is already gone and the fault is stale.
Take a runtime PM reference across the entire pagefault queue worker to safely deliver acks for torn-down VMs.
v3: - Move PM ref to the generic xe_pagefault_queue_work using guard(xe_pm_runtime)(xe) instead of tracking it in the GuC backend(Matt Brost).
v2: - Hold PM ref across the entire batch (begin/end) instead of per-ack. This prevents the device from autosuspending mid-batch, which would leave write_only acks written but the end flush skipped, and skip counter++, desyncing the cadence check.(Himal) - Add a comment explaining stale faults.(Himal)
(cherry picked from commit fcc2431d2213dc4d04250c4f1ae87d9c3ae0d455) [Rodrigo: Added xe_device struct for compatibility while cherry-picking]
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability described involves a race condition within the Linux kernel's DRM Xe driver, specifically concerning power management synchronization during virtual machine teardown. The core issue arises from an asynchronous drop of runtime power management references associated with a virtual machine context. When this reference is released, the underlying hardware device becomes eligible for autosuspension even while page fault events belonging to that now-terminated VM remain queued in the system's workqueue infrastructure. This temporal mismatch creates a window where stale faults are processed after the device has entered a low-power suspended state, leading to invalid memory access attempts and assertion failures within the driver code.
From a technical perspective, the flaw lies in the lifecycle management of power states relative to asynchronous task execution. The page-fault worker routine is responsible for acknowledging these hardware interrupts by sending completion signals via the GuC command transport interface. However, this operation requires active device memory access capabilities which are disabled during autosuspension. Without holding a valid runtime PM reference throughout the duration of the fault processing logic, the driver attempts to invoke guc_ct_send_locked on an inactive device. This triggers the xe_device_assert_mem_access assertion failure located in xe_device.c, effectively causing a kernel warning and potentially leading to undefined behavior or system instability depending on how strictly the hardware handles such invalid command submissions.
The operational impact of this vulnerability includes potential denial of service through kernel warnings that may disrupt normal graphics processing operations. In severe cases, if the driver fails to handle the assertion gracefully, it could lead to a kernel panic or require a full system reboot. Furthermore, the desynchronization mentioned in earlier versions highlights secondary risks where incomplete acknowledgment sequences might leave internal counters and state machines out of sync, potentially affecting future scheduling decisions for execution queues and compromising the integrity of subsequent graphics workloads.
To mitigate this issue, the fix implements a robust synchronization mechanism by acquiring a runtime PM reference at the start of the page-fault queue worker and releasing it only after all acknowledgments have been successfully delivered. This ensures that the device remains in an active power state for the entire duration required to process stale faults safely. The implementation utilizes guard macros to manage this reference automatically, preventing leaks or premature releases. By holding the PM ref across the entire batch of fault processing rather than per individual acknowledgment, the driver prevents mid-batch autosuspension which could otherwise result in partial updates and counter desynchronization. This approach aligns with best practices for concurrent resource management in kernel drivers, ensuring that hardware state transitions do not interfere with pending software tasks.
This vulnerability can be categorized under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, as the race condition stems from improper coordination between asynchronous task completion and power state changes. In terms of attack vectors or failure modes, it relates to resource management errors that could lead to availability issues, though exploitation typically requires specific timing conditions related to VM teardown and high interrupt loads rather than direct malicious input. The fix reinforces the principle that any component accessing hardware resources must guarantee those resources remain accessible for its entire operational lifespan, a critical consideration in complex subsystems like GPU drivers where multiple asynchronous events interact with shared physical devices.