CVE-2026-98391: drm/xe: Guard page-fault worker with runtime PM check
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 gucctsendlocked() on an already-suspended device, tripping:
Assertion !xepmruntimesuspended(xe) failed! WARNING at xedevice.c:1267 xedeviceassertmemaccess+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 xepagefaultqueuework using guard(xepmruntime)(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 writeonly 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 xedevice struct for compatibility while cherry-picking]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch fcc2431d2213dc4d04250c4f1ae87d9c3ae0d455
Event History
Frequently Asked Questions
Which systems are exposed to this condition?
Systems using the Linux kernel drm/xe driver are affected when a VM is torn down while stale page faults remain queued and the device can autosuspend before the page-fault worker acknowledges them.
What evidence would indicate that this issue has occurred?
The page-fault worker can trigger an assertion that the device is not runtime suspended. Reported evidence includes "Assertion `!xe_pm_runtime_suspended(xe)` failed!" and a warning from xe_device_assert_mem_access in the xe module.
What changes in the fix prevent the failure?
The fix holds a runtime PM reference for the entire page-fault queue worker batch. This keeps the device active while acknowledgements are delivered, including the final flush for write-only acknowledgements.