CVE-2026-89519
Niskie ryzyko· EPSS 9%Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 9 - wyżej niż 9% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Może wystąpić niespójność stanu schedulera, prowadząca do błędnego działania systemu, awarii lub potencjalnie do eskalacji uprawnień w kontekście jądra.
Rekomendacja
Zaktualizuj jądro Linux do wersji zawierającej poprawkę zastępującą flagę SCX_RQ_BAL_KEEP jawnym zwrotem werdyktu z scx_dispatch_sched() i balance_one(). Do czasu aktualizacji unikaj konfiguracji wykorzystujących sched_ext z core scheduling.
Inne podatności w Linux kernel (sched_ext)
Zobacz wszystkie- 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ąć.
- CVE-2025-68333Średnie
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.
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: sched_ext: Replace SCX_RQ_BAL_KEEP with a dispatch verdict return SCX_RQ_BAL_KEEP tells the pick to keep running the previous task, a leftover from when balancing and picking were separate operations. An rq-level flag only works while dispatches and picks pair up one to one, which core scheduling breaks: selections interleave through dispatch's lock drops and a pick can consume a stale flag, keeping a task that has since been dequeued. Fixing core scheduling support requires the decision to travel with the dispatch that made it. Make scx_dispatch_sched() and balance_one() return an explicit verdict instead and drop the flag's plumbing from the tools autogen enum headers. Also factor the pick-side invocation, its follow-up queueing and the post-dispatch checks out of do_pick_task_scx() into dispatch_pick(). No functional changes intended. v2: Drop the SCX_RQ_BAL_KEEP plumbing from the tools autogen enum headers as well (Andrea).
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

