CVE-2026-98310 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/shrinker: Take a runtime PM ref before shrinking non-system memory
__xe_shrinker_walk() 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/xe_bo.c:770 at xe_bo_move_notify+0x1fc/0x450 [xe]
xe_bo_shrink+0x20f/0x2b0 [xe]
__xe_shrinker_walk+0x174/0x410 [xe]
xe_shrinker_scan+0x10c/0x1e0 [xe]
do_shrink_slab+0x176/0x7e0 drop_caches_sysctl_handler+0x9c/0xf0
Take a reference before walking a memory type other than XE_PL_SYSTEM 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 xe_device_is_l2_flush_optimized(), the same condition under which xe_bo_trigger_rebind() issues the invalidation for a non-fault-mode vm, so reclaim is unaffected elsewhere. The System CCS copy already has its own reference in xe_bo_shrink().
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@xe_madvise@dontneed-before-exec while the GPU is runtime suspended.
v2: simplify needs_rpm check. (Matt) retarget Fixes tag since the issue occurs with the non-fault-mode path added by 4e7ebff69aed. v3: handle this in xe_shrinker.c instead of xe_bo.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 xe_pm_runtime_put() with xe_shrinker_runtime_pm_put(). (Thomas)
(cherry picked from commit 628f92b28bf4c371c10207daf6fc4caee0c0db2e)
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel driver for Intel Xe graphics contains a critical concurrency and power management flaw within the buffer object shrinker logic, specifically affecting non-system memory types such as Translation Table (TT) LRUs. The vulnerability arises because the __xe_shrinker_walk function attempts to reclaim buffers that reside outside of system memory without first acquiring a runtime Power Management reference for the GPU device. This oversight creates a race condition where the kernel may attempt to invalidate GPU mappings and perform TLB invalidations while the hardware is in a suspended state. Since these operations require an active, resumed device context, executing them during suspension leads to immediate failure of page table zapping and results in error codes such as -ENODEV being returned from low-level driver functions.
From a technical perspective, this defect represents a violation of proper resource lifecycle management within the kernel's memory subsystem. When the shrinker walks through memory lists to free pages under memory pressure, it must ensure that any hardware-dependent operations are protected by appropriate power references. The absence of this check means that if the GPU is runtime suspended, typically due to inactivity or power-saving policies triggered by tools like igtxe_madvisedontneed-before-exec, the subsequent attempt to unmap buffers triggers an assertion failure in xe_bo_move_notify and causes warnings related to buffer shrinking operations. This behavior not only disrupts normal memory reclamation but can also lead to kernel panics or unstable system states depending on how strictly assertions are configured during compilation.
The operational impact of this vulnerability includes potential denial-of-service conditions for graphics workloads, particularly those involving heavy memory pressure combined with periods of GPU inactivity. Users may experience graphical glitches, application crashes, or complete system hangs when the shrinker is forced to operate while the hardware is powered down. Furthermore, repeated assertion failures can generate significant kernel log noise and potentially trigger watchdog timeouts if the state remains unresolved for extended periods. The issue specifically affects non-fault-mode virtual memory configurations, as fault-mode VMs inherently hold runtime PM references throughout their lifetime, thereby shielding them from this specific race condition.
To mitigate this vulnerability, the fix involves modifying the shrinker logic to acquire a runtime PM reference before attempting to walk or reclaim any memory type other than XE_PL_SYSTEM. If the reference cannot be acquired because the device is suspended, the operation should halt rather than proceed with invalid hardware state access. The implementation reuses existing shrinker acquisition paths that intelligently resume the device directly when reclaim allows it, or queues a power management worker for later execution if immediate resumption is not feasible. Additionally, the walk stops once the scan target is met to prevent unnecessary wake-ups of the device during satisfied scans. This logic is gated by xe_device_is_l2_flush_optimized() to ensure that only relevant hardware configurations are affected, leaving system memory reclamation and other unaffected paths unchanged.
This vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, as the race condition stems from accessing shared hardware resources without proper synchronization via power management references. It also relates to CWE-459, Incomplete Cleanup, insofar as the failure to manage device state properly leaves the system in an inconsistent operational mode during memory reclamation events. From a defensive standpoint, this incident highlights the importance of adhering strictly to kernel API contracts regarding runtime PM usage in drivers that interact with hardware-dependent subsystems like GPU buffer management.