Skip to main content
VulnerabilityPublished

CVE-2026-99005: Linux kernel · drm/i915/gt: Unmask interrupts only when ACTIVE is true

Source GCVE Database

0
Authoritative record:CVE-2026-99005· Medium

Not known to be exploited · fixed in 5346b1cec6afa4f9b4b49a9f84e3cfef95a3f7bb : update Linux kernel when convenient.

Data as of 26 Oct 2026, 14:05 UTC

Severity
Medium

Rated by Threat Radar · CVSS not yet scored by NVD

EPSS
0.1% chance of exploitation in 30 days – higher than 7% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 5346b1cec6afa4f9b4b49a9f84e3cfef95a3f7bb, 77abc1837c9651c8f43f7f7f336d10093eeb7745, 60f58da15f8c8e39706c564f9251de3626636dce +2

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 23 Oct 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 3e7abf8141935ded77abeb622480bf4a14241ece, < 5346b1cec6afa4f9b4b49a9f84e3cfef95a3f7bb
Fixed in
  • 5346b1cec6afa4f9b4b49a9f84e3cfef95a3f7bb
LinuxLinuxAffected
  • ≥ 3e7abf8141935ded77abeb622480bf4a14241ece, < 77abc1837c9651c8f43f7f7f336d10093eeb7745
Fixed in
  • 77abc1837c9651c8f43f7f7f336d10093eeb7745
LinuxLinuxAffected
  • ≥ 3e7abf8141935ded77abeb622480bf4a14241ece, < 60f58da15f8c8e39706c564f9251de3626636dce
Fixed in
  • 60f58da15f8c8e39706c564f9251de3626636dce
LinuxLinuxAffected
  • ≥ 3e7abf8141935ded77abeb622480bf4a14241ece, < 49d349c42cf5ebaa878d02699c632c9d883d935f
Fixed in
  • 49d349c42cf5ebaa878d02699c632c9d883d935f
LinuxLinuxAffected
  • ≥ 3e7abf8141935ded77abeb622480bf4a14241ece, < 0b4a0fb98b9ffeac36798bbd369c821605cae70f
Fixed in
  • 0b4a0fb98b9ffeac36798bbd369c821605cae70f
LinuxLinuxAffected
  • =5.5
Fixed in–

Description

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)

References

Community reviews

Loading reviews…