CVE-2025-68333
ŚrednieCVSS 5.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 1 - wyżej niż 1% wszystkich znanych CVE
Streszczenie
W jądrze Linux w podsystemie sched_ext występuje możliwe zakleszczenie w funkcji deferred_irq_workfn() na jądrach z PREEMPT_RT=y. Gdy funkcja jest wykonywana w kontekście zadania per-CPU irq_work/* bez wyłączonych przerwań, może dojść do ponownego zablokowania tej samej blokady rq->__lock przez przerwanie. Poprawka wymusza wykonywanie funkcji w kontekście hard-irq.
Ocena ryzyka
Może prowadzić do zakleszczenia systemu na jądrach czasu rzeczywistego (PREEMPT_RT), powodując zawieszenie maszyny. Dotyczy systemów wykorzystujących scheduler sched_ext w konfiguracji RT.
Rekomendacja
Zaktualizuj jądro Linux do wersji zawierającej poprawkę używającą IRQ_WORK_INIT_HARD() do inicjalizacji rq->scx.deferred_irq_work.
Inne podatności w Linux kernel (sched_ext)
Zobacz wszystkie- CVE-2026-89519Niskie ryzyko· EPSS 9%
W jądrze Linux w schedulerze sched_ext flaga SCX_RQ_BAL_KEEP informuje pick o kontynuowaniu poprzedniego zadania, co jest pozostałością z czasów, gdy balansowanie i wybieranie były osobnymi operacjami. Flaga na poziomie rq działa tylko, gdy dispatche i picki łączą się jeden do jednego, co łamie core scheduling: wybory przeplatają się przez zwolnienia blokady dispatch, a pick może zużyć nieaktualną flagę, zachowując zadanie, które zostało już usunięte z kolejki.
- CVE-2026-89516Niskie ryzyko· EPSS 9%
W jądrze Linux w schedulerze sched_ext funkcja scx_bpf_dsq_reenq() kolejkuje odroczone ponowne wstawienie (dru), które uruchamia się z run_deferred(), a nie ops.dispatch(). Jeśli DSQ zostanie zniszczone przed uruchomieniem dru, process_deferred_reenq_users() widzi dsq->id == SCX_DSQ_INVALID i trafia na BUG_ON. destroy_dsq() nie opróżnia oczekujących drus, więc wystarczy pominąć.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix possible deadlock in the deferred_irq_workfn() For PREEMPT_RT=y kernels, the deferred_irq_workfn() is executed in the per-cpu irq_work/* task context and not disable-irq, if the rq returned by container_of() is current CPU's rq, the following scenarios may occur: lock(&rq->__lock); <Interrupt> lock(&rq->__lock); This commit use IRQ_WORK_INIT_HARD() to replace init_irq_work() to initialize rq->scx.deferred_irq_work, make the deferred_irq_workfn() is always invoked in hard-irq context.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS