Cloudanix VulnDB

CVE-2026-99005

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in certain Intel graphics drivers on Linux can cause the system to log unexpected warnings during normal power-saving operations.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition between intel_rps_boost checking stale ACTIVE state and asynchronous GT parking allows rps_work to execute gen6_gt_pm_unmask_irq after wakelock is dropped, triggering assert_rpm_wakelock_held failure and kernel taint.

Why it matters to the business

Linux systems using Intel integrated graphics may experience unexpected kernel warnings or reduced stability during power-management transitions; low immediate operational risk but adds noise to logs and complicates debugging.

How an attack unfolds

A local user triggers graphics operations that cause wakeref drops while simultaneously queuing RPS work; the race window lets the worker unmask interrupts on a parked GT, violating power-management invariants and producing the taint message.

How to fix it

Apply the upstream fix that adds an ACTIVE-state guard before unmasking RPS PM interrupts; rebuild and deploy updated kernel packages containing commit ca4a6deadad15b91ee083afe445fa6bdbfb68206 or equivalent backport.

How to confirm the fix worked

Confirm the patched kernel contains the ACTIVE check before gen6_gt_pm_unmask_irq; reproduce live_rc6_ctx_wa selftest without triggering the RPM wakelock warning.

Typical attack path

  1. Trigger Intel GPU rendering or fence-wait operations
  2. Cause concurrent engine/GT parking via wakeref_put paths
  3. Hit open race window between ACTIVE check and rps_work execution
  4. Observe kernel taint warning from gen6_gt_pm_unmask_irq without wakelock

How to detect it

Search kernel logs for the exact string RPM wakelock ref not held during HW access originating from gen6_gt_pm_unmask_irq; correlate with i915 fence-wait and engine-park sequences.

What your security team should do

  • Prioritize kernel update on all systems exposing the i915 driver
  • Monitor kernel logs for RPM wakelock taint messages as a temporary indicator
  • Restrict unprivileged access to GPU workloads until patched

The record

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)

Affected packages

Ecosystem Package Introduced Fixed