CVE-2026-98310: drm/xe/shrinker: Take a runtime PM ref before shrinking non-system memory
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/shrinker: Take a runtime PM ref before shrinking non-system memory
xeshrinkerwalk() walks the SYSTEM and TT LRUs without a runtime PM reference. Shrinking a bo outside system memory invalidates its GPU mappings, which needs the device resumed, so while it is runtime suspended the page table zap trips an assert and the TLB invalidation returns -ENODEV:
WARNING: drivers/gpu/drm/xe/xebo.c:770 at xebomovenotify+0x1fc/0x450 [xe] xeboshrink+0x20f/0x2b0 [xe] xeshrinkerwalk+0x174/0x410 [xe] xeshrinkerscan+0x10c/0x1e0 [xe] doshrinkslab+0x176/0x7e0 dropcachessysctlhandler+0x9c/0xf0
Take a reference before walking a memory type other than XEPLSYSTEM and stop there if it cannot be acquired. Reuse the shrinker's existing acquire path, which resumes the device directly where reclaim allows that and otherwise queues the PM worker for a later scan. Stop the walk once the scan target is met, so a satisfied scan does not wake the device. System memory is still reclaimed while the device is suspended.
Gate this on xedeviceisl2flushoptimized(), the same condition under which xebotriggerrebind() issues the invalidation for a non-fault-mode vm, so reclaim is unaffected elsewhere. The System CCS copy already has its own reference in xeboshrink().
Only a non-fault-mode vm can reach this, since a fault-mode vm requires LR mode and that holds a runtime PM reference for the vm's lifetime.
Reproduced with igt@xemadvise@dontneed-before-exec while the GPU is runtime suspended.
v2: simplify needsrpm check. (Matt) retarget Fixes tag since the issue occurs with the non-fault-mode path added by 4e7ebff69aed. v3: handle this in xeshrinker.c instead of xebo.c (Thomas) v4: stop the walk once the scan target is met. (Sashiko) v5: rebase on the freed page accounting fix. (Sashiko) v6: reuse the shrinker acquire path so runtime pm can be resumed directly instead of always queueing a worker. (Thomas) v7: replace xepmruntimeput() with xeshrinkerruntimepmput(). (Thomas)
(cherry picked from commit 628f92b28bf4c371c10207daf6fc4caee0c0db2e)
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel drm/xeto a version that resolves this vulnerability.Patch 628f92b28bf4c371c10207daf6fc4caee0c0db2e
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel xe DRM driver are relevant. The affected path involves reclaiming non-system GPU memory while the device is runtime suspended, under the xe_device_is_l2_flush_optimized() condition.
What conditions trigger the problem?
The issue occurs when the xe shrinker walks TT or other non-system memory LRUs without first obtaining a runtime PM reference, and shrinking a buffer object invalidates GPU mappings while the GPU is suspended. Memory-reclaim activity, including a drop-caches operation shown in the report, can reach this path.
What happens when the issue is triggered?
The page-table zap can trip an assertion, and TLB invalidation can return -ENODEV because the device is runtime suspended. System-memory reclamation remains possible while the device is suspended.
What behavior does the fix introduce if the device cannot be resumed immediately?
For non-system memory, the shrinker stops that walk when it cannot acquire the required runtime PM reference. Where direct resume is not allowed during reclaim, it queues the PM worker so the memory can be scanned later.