CVE-2026-99005 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
drm/i915/gt: Unterbrechungen (Interrupts) nur dann entsperren, wenn ACTIVE wahr ist.
Es besteht ein kleines Race-Window zwischen dem Lesen eines veralteten ACTIVE-Zustands durch intel_rps_boost() und dem Warten auf rps->work, wobei sich der ACTIVE-Zustand über asynchrone Aufrufe ändern kann, die durch das Herunterzählen von wakeref ausgelöst werden. Dies bedeutet, dass rps_work() nach dem Parken des GT ausgeführt werden könnte, sodass das Entsperren der RPS-PM-Interrupts ohne Halten des PM-wakelock erfolgen würde. Diese Ereignisabfolge kann während des live_rc6_ctx_wa()-Selbsttests beobachtet werden:
1) live_rc6_ctx_wa() -> intel_engine_pm_put() -> wakeref_put()
ASYNC1) Callback von wakeref_put() -> __engine_park() -> intel_gt_pm_put_async() -> intel_gt_pm_put_async_untracked() -> intel_wakeref_put_async()
ASYNC2) Callback von wakeref_put_async() -> __gt_park() -> intel_rps_park() -> intel_rps_clear_active() [ACTIVE wird gelöscht]
MIT INTERRUPTS: -> rps_disable_interrupts() -> cancel_work_sync(rps->work) -> rps_reset_interrupts() [rps->pm_iir = 0]
OHNE INTERRUPTS (TIMER-Modus): -> 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() [prüft ACTIVE]
[OFFENES RACE-WINDOW]
-> queue_work(rps->work) -> retire_requests() -> i915_request_retire() -> intel_rps_dec_waiters() [von 1 auf 0]
Wenn ASYNC1 und ASYNC2 während des [OFFENES RACE-WINDOWS] ausgeführt würden, dann:
3) rps_work() wird aus der Workqueue ausgeführt und kann den Test "(!pm_iir && !client_boost)" erfüllen (im TIMER-Modus ist rps->pm_iir durch einen früheren Aufruf von rps_work() auf Null gesetzt oder erhält nach dem vorherigen intel_rps_unpark()-Ereignis keinen neuen Wert), sodass es zur Marke „out“ springt, die Schutzfunktion intel_rps_is_active() umgeht und gen6_gt_pm_unmask_irq(); ausführt;
4) Das GT ist geparkt und der runtime PM wakelock wird freigegeben, so dass nur noch eine rohe Referenz in __gt_park() -> intel_display_power_put_async() für 100 ms verbleibt. Anschließend erkennt der MMIO-Write in gen6_gt_pm_unmask_irq() den fehlenden wakelock über assert_rpm_wakelock_held() und gibt die Taint-Meldung „RPM wakelock ref not held during HW access“ aus.
Der Commit 3e7abf814193 („drm/i915: Extract GT render power state management“) hat den Guard "if (rps->interrupts_enabled)" entfernt, der gen6_pm_rps_work() in i915_irq.c um dieses Entsperren herum hatte. INTEL_RPS_ACTIVE umfasst dasselbe Fenster, da es in intel_rps_unpark() vor rps_enable_interrupts() und rps_start_timer() gesetzt wird und in intel_rps_park() vor rps_stop_timer() und rps_disable_interrupts() gelöscht wird.
Das Entsperren überspringen, wenn RPS nicht mehr aktiv ist (das Erreichen der Entsperroperation ist unabhängig vom INTERRUPT-Modus). Dies verhindert nicht, dass der RSB-Betrieb beim nächsten Unpark fortgesetzt wird. Im Interrupt-Modus ruft intel_rps_unpark() rps_enable_interrupts() auf, was die PM-Interrupts aktiviert und entsperrt. Im Timer-Modus ruft es rps_start_timer() auf, wodurch die periodische Bewertung der Engine-Busyheit neu gestartet wird. Der Timer generiert Software-RPS-Ereignisse und wartet direkt auf rps_work(), unabhängig von der Zustellung von PM-Interrupts. Kein Modus erfordert, dass der späte Worker Interrupts entsperrt, während das GT geparkt ist.
(cherry picked from commit ca4a6deadad15b91ee083afe445fa6bdbfb68206)
Be aware that VulDB is the high quality source for vulnerability data.