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

Published Oct 23, 2026
·
Updated

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 intelrpsboost() reading a stale ACTIVE state and queuing rps->work, where ACTIVE may be changed via asynchronous calls triggered by wakeref drop. This means that rpswork() 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 liverc6ctxwa() selftest:

1) liverc6ctxwa() -> intelenginepmput() -> wakerefput()

ASYNC1) wakerefput() callback -> enginepark() -> intelgtpmputasync() -> intelgtpmputasyncuntracked() -> intelwakerefputasync()

ASYNC2) wakerefputasync() callback -> gtpark() -> intelrpspark() -> intelrpsclearactive() [clear ACTIVE] WITH INTERRUPTS: -> rpsdisableinterrupts() -> cancelworksync(rps->work) -> rpsresetinterrupts() [rps->pmiir = 0] WITHOUT INTERRUPTS (TIMER mode): -> rpsstoptimer() -> cancelworksync(rps->work)

2) liverc6ctxwa() -> intelgtwaitforidle() -> intelgtretirerequeststimeout() -> dmafencewaittimeout() -> ops->wait() [i915fencewait()] -> i915requestwaittimeout() -> intelrpsboost() -> intelrpsisactive() [check ACTIVE] [OPEN RACE WINDOW] -> queuework(rps->work) -> retirerequests() -> i915requestretire() -> intelrpsdecwaiters() [from 1 to 0]

If ASYNC1 and ASYNC2 would execute during [OPEN RACE WINDOW], then:

3) rpswork() executes from the workqueue and may satisfy "(!pmiir && !clientboost)" test (in TIMER mode rps->pmiir is zeroed by an earlier rpswork() call or never gets a new value after previous intelrpsunpark() event), so it jumps to "out" label, bypassing intelrpsisactive() guard and executes gen6gtpmunmaskirq();

4) GT is parked and runtime PM wakelock is dropped, so only a raw reference in gtpark() -> inteldisplaypowerputasync() remains for 100ms, then the MMIO write in gen6gtpmunmaskirq() detects missing wakelock via assertrpmwakelockheld() 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->interruptsenabled)" guard that gen6pmrpswork() had around this unmask in i915irq.c. INTELRPSACTIVE brackets the same window, since it is set in intelrpsunpark() before rpsenableinterrupts() and rpsstarttimer() and cleared in intelrpspark() before rpsstoptimer() and rpsdisableinterrupts().

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, intelrpsunpark() calls rpsenableinterrupts(), which enables and unmasks the PM interrupts. In timer mode, it calls rpsstarttimer(), restarting periodic engine-busyness evaluation. The timer generates software RPS events and queues rpswork() 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 Software

1 affected component
Linux Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Linux kernel to a version that resolves this vulnerability.

    Patch ca4a6deadad15b91ee083afe445fa6bdbfb68206

Event History

Oct 23, 2026
CVE Published
via MITRE·12:20 PM
Data Sourced
via MITRE·12:20 PM
Description

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203