CVE-2026-99005 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Unmask interrupts only when ACTIVE is true
There is a small race window between intel_rps_boost() reading a stale ACTIVE state and queuing rps->work, where ACTIVE may be changed via asynchronous calls triggered by wakeref drop. This means that rps_work() could be triggered after the GT has been parked, so unmasking RPS PM interrupts would happen without holding PM wakelock. This sequence of events may be observed during live_rc6_ctx_wa() selftest:
1) live_rc6_ctx_wa() -> intel_engine_pm_put() -> wakeref_put()
ASYNC1) wakeref_put() callback -> __engine_park() -> intel_gt_pm_put_async() -> intel_gt_pm_put_async_untracked() -> intel_wakeref_put_async()
ASYNC2) wakeref_put_async() callback -> __gt_park() -> intel_rps_park() -> intel_rps_clear_active() [clear ACTIVE]
WITH INTERRUPTS: -> rps_disable_interrupts() -> cancel_work_sync(rps->work) -> rps_reset_interrupts() [rps->pm_iir = 0]
WITHOUT INTERRUPTS (TIMER mode): -> rps_stop_timer() -> cancel_work_sync(rps->work)
2) live_rc6_ctx_wa() -> intel_gt_wait_for_idle() -> intel_gt_retire_requests_timeout() -> dma_fence_wait_timeout() -> ops->wait() [i915_fence_wait()]
-> i915_request_wait_timeout() -> intel_rps_boost() -> intel_rps_is_active() [check ACTIVE]
[OPEN RACE WINDOW]
-> queue_work(rps->work) -> retire_requests() -> i915_request_retire() -> intel_rps_dec_waiters() [from 1 to 0]
If ASYNC1 and ASYNC2 would execute during [OPEN RACE WINDOW],
then:
3) rps_work() executes from the workqueue and may satisfy "(!pm_iir && !client_boost)" test (in TIMER mode rps->pm_iir is zeroed by an earlier rps_work() call or never gets a new value after previous intel_rps_unpark() event), so it jumps to "out" label, bypassing intel_rps_is_active() guard and executes gen6_gt_pm_unmask_irq();
4) GT is parked and runtime PM wakelock is dropped, so only a raw reference in __gt_park() -> intel_display_power_put_async() remains for 100ms, then the MMIO write in gen6_gt_pm_unmask_irq() detects missing wakelock via assert_rpm_wakelock_held() and emits "RPM wakelock ref not held during HW access" tainting kernel.
Commit 3e7abf814193 ("drm/i915: Extract GT render power state management") dropped the "if (rps->interrupts_enabled)" guard that gen6_pm_rps_work() had around this unmask in i915_irq.c. INTEL_RPS_ACTIVE brackets the same window, since it is set in intel_rps_unpark() before rps_enable_interrupts() and rps_start_timer() and cleared in intel_rps_park() before rps_stop_timer() and rps_disable_interrupts().
Skip unmasking when RPS is no longer active (reaching unmask operation is independent of INTERRUPT mode). This does not prevent RPS operation from resuming on the next unpark. In interrupt mode, intel_rps_unpark() calls rps_enable_interrupts(), which enables and unmasks the PM interrupts. In timer mode, it calls rps_start_timer(), restarting periodic engine-busyness evaluation. The timer generates software RPS events and queues rps_work() directly, independently of PM interrupt delivery. Neither mode requires the late worker to unmask interrupts while the GT is parked
(cherry picked from commit ca4a6deadad15b91ee083afe445fa6bdbfb68206)
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel driver for Intel graphics hardware, specifically within the drm/i915/gt subsystem, contains a race condition vulnerability related to power management state synchronization. This flaw arises from an asynchronous interaction between runtime power management wakelocks and Render Power State RPS workqueues. The core issue is that interrupts are unmasked by the kernel even when the Graphics Technology GT unit has already been parked or is in the process of being powered down, leading to hardware access without holding the required PM wakelock. This situation creates a window where asynchronous callbacks triggered by wakeref drops can clear active states while other threads simultaneously attempt to queue work items based on stale state information.
The technical flaw manifests during specific sequences involving live_rc6_ctx_wa selftests and general GT idle wait operations. When intel_rps_boost is called, it checks the ACTIVE state of the RPS subsystem. If this check occurs after an asynchronous wakeref_put callback has already cleared the active flag via __gt_park or intel_rps_clear_active, a race condition exists. The worker thread rps_work may execute and satisfy conditions that bypass the standard activity guard because the pm_iir register is zeroed by previous operations or timer modes. Consequently, the function gen6_gt_pm_unmask_irq executes without verifying if the GT remains active. This unmasking operation attempts to write to hardware registers while the runtime PM wakelock has been dropped, violating kernel power management protocols.
The operational impact of this vulnerability includes kernel tainting and potential system instability. When the MMIO write occurs in gen6_gt_pm_un_mask_irq without an active wakelock, the assert_rpm_wakelock_held macro triggers a warning. This results in a tainted kernel message indicating that a raw reference remains for only one hundred milliseconds before being dropped by __gt_park and intel_display_power_put_async. While this may not immediately cause a system crash, it indicates improper hardware access patterns that can lead to undefined behavior on certain Intel GPU architectures, particularly during context switching or power state transitions where timing is critical.
This vulnerability was introduced when commit 3e7abf814193 removed the interrupts_enabled guard from gen6_pm_rps_work in i915_irq.c. The fix involves ensuring that unmasking of RPS PM interrupts only occurs when the ACTIVE flag is true, effectively closing the race window regardless of whether the system operates in interrupt mode or timer mode. In both modes, late worker execution should not attempt to unmask interrupts while the GT is parked, as neither mechanism requires this action during power-down sequences. The solution restores proper synchronization between state checks and hardware access operations.
From a security perspective, this issue aligns with CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization Race Conditions. It also relates to improper handling of asynchronous events which can lead to unauthorized or unsafe resource access patterns. In the context of MITRE ATT&CK, while primarily a stability and correctness issue rather than an exploit vector for privilege escalation, it reflects weaknesses in how kernel subsystems manage shared resources during state transitions. Such race conditions are often precursors to more severe vulnerabilities if they allow for use-after-free scenarios or memory corruption through improper hardware register manipulation under concurrent execution contexts.
Mitigation strategies involve applying the upstream Linux kernel patch that adds a check for RPS activity before unmasking interrupts. System administrators should ensure their kernels include this fix, which is typically available in recent stable releases of distributions maintaining Intel graphics drivers. For developers and maintainers, it highlights the importance of verifying hardware state consistency before performing MMIO operations during asynchronous power management callbacks. Regular updates to kernel components are essential to prevent these synchronization flaws from manifesting as system instability or potential exploitation vectors in complex multi-threaded environments.