CVE-2026-99005

W jądrze Linuksa usunięto następującą lukę:

drm/i915/gt: Odmaskowanie przerywa tylko wtedy, gdy ACTIVE ma wartość true

Pomiędzy odczytami funkcji intel_rps_boost() występuje małe okno wyścigu
nieaktualny stan AKTYWNY i kolejkowanie rps->work, gdzie AKTYWNY może być
zmieniany poprzez wywołania asynchroniczne wyzwalane przez upuszczenie wakeref.
Oznacza to, że funkcja rps_work() może zostać uruchomiona po tym, jak GT to zrobi
został zaparkowany, więc demaskowanie przerwań RPS PM odbyłoby się bez tego
trzymając PM wakelock. Można zaobserwować tę sekwencję zdarzeń
podczas autotestu live_rc6_ctx_wa():

1) live_rc6_ctx_wa()
-> intel_engine_pm_put()
-> wakeref_put()

Wywołanie zwrotne ASYNC1) wakeref_put().
-> __engine_park()
-> intel_gt_pm_put_async()
-> intel_gt_pm_put_async_untracked()
-> intel_wakeref_put_async()

Wywołanie zwrotne ASYNC2) wakeref_put_async().
-> __gt_park()
-> intel_rps_park()
-> intel_rps_clear_active() [wyczyść AKTYWNE]
Z PRZERWAMI:
-> rps_disable_interrupts()
-> cancel_work_sync(rps->praca)
-> rps_reset_interrupts() [rps->pm_iir = 0]
BEZ PRZERW (tryb TIMER):
-> rps_stop_timer()
-> cancel_work_sync(rps->praca)

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() [sprawdź AKTYWNE]
[OTWÓRZ OKNO WYŚCIGU]
-> kolejka_praca(rps->praca)
-> żądania przejścia na emeryturę()
-> i915_request_retire()
-> intel_rps_dec_waiters() [od 1 do 0]

Jeśli ASYNC1 i ASYNC2 miałyby zostać wykonane podczas [OTWÓRZ OKNO WYŚCIGU],
następnie:

3) rps_work() wykonuje się z kolejki roboczej i może spełnić oczekiwania
Test "(!pm_iir && !client_boost)" (w trybie TIMER rps->pm_iir
jest zerowany przez wcześniejsze wywołanie rps_work() lub nigdy nie otrzymuje nowego
wartość po poprzednim zdarzeniu intel_rps_unpark()), więc przeskakuje
do etykiety „out”, omijając ochronę intel_rps_is_active() i
wykonuje gen6_gt_pm_unmask_irq();

4) GT jest zaparkowany, a wakelock PM w czasie wykonywania zostaje usunięty, więc tylko
surowe odniesienie w __gt_park() ->
intel_display_power_put_async() pozostaje przez 100 ms, następnie
Zapis MMIO w gen6_gt_pm_unmask_irq() wykrywa brak
wakelock poprzez Assert_rpm_wakelock_held() i emituje
Jądro skażone „RPM wakelock ref nie jest utrzymywane podczas dostępu do sprzętu”.

Zatwierdź 3e7abf814193 („drm/i915: Wyodrębnij zarządzanie stanem mocy renderowania GT”)
upuścił zabezpieczenie „if (rps->interrupts_enabled)”.
gen6_pm_rps_work() zajmowała się tym zdemaskowaniem w i915_irq.c.
INTEL_RPS_ACTIVE obejmuje to samo okno, ponieważ jest w nim ustawione
intel_rps_unpark() przed rps_enable_interrupts() i
rps_start_timer() i wcześniej wyczyszczony w intel_rps_park().
rps_stop_timer() i rps_disable_interrupts().

Pomiń demaskowanie, gdy RPS nie jest już aktywny (osiągając unmask
działanie jest niezależne od trybu PRZERWA). To nie
uniemożliwić wznowienie działania RPS przy następnym odparkowaniu.
W trybie przerwania wywołuje funkcję intel_rps_unpark().
rps_enable_interrupts(), która włącza i demaskuje PM
przerywa. W trybie timera wywołuje rps_start_timer(),
ponowne uruchomienie okresowej oceny pracy silnika. Minutnik
generuje bezpośrednio zdarzenia oprogramowania RPS i kolejki rps_work(),
niezależnie od dostarczania przerwań PM. Żaden tryb nie wymaga
spóźniony pracownik w celu zdemaskowania przeszkadza, gdy GT jest zaparkowany

(wiśnia wybrana z zatwierdzenia ca4a6deadad15b91ee083afe445fa6bdbfb68206)