Katalog CVE

CVE-2026-68094

Niskie ryzyko· EPSS 5%
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.16%

Percentyl 5 - wyżej niż 5% wszystkich znanych CVE

Streszczenie

W jądrze Linux wykryto podatność w mechanizmie sched_ext, gdzie funkcja dispatch_to_local_dsq() może przełączać kolejki rq bez aktualizacji śledzenia bieżącego rq, co prowadzi do naruszenia asercji lockdep i potencjalnego błędu krytycznego. Problem dotyczy zachowania spójności między blokadami rq a ich śledzeniem podczas zagnieżdżonych wywołań ops.dequeue().

Ocena ryzyka

Podatność może powodować awarię systemu (panic) lub nieprawidłowe działanie planisty zadań, szczególnie w środowiskach używających sched_ext do zaawansowanego zarządzania obciążeniem. Może to prowadzić do przerw w działaniu usług lub niestabilności systemu.

Rekomendacja

Zaleca się natychmiastowe zastosowanie oficjalnej łatki jądra Linux, która wprowadza funkcję switch_rq_lock() i aktualizuje śledzenie rq przy każdej zmianie blokady. Należy również monitorować komunikaty o nowych wersjach jądra i testować aktualizacje w środowisku staging przed wdrożeniem produkcyjnym.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Preserve rq tracking across local DSQ dispatch dispatch_to_local_dsq() can run from scx_bpf_dsq_move_to_local() while ops.dispatch() has recorded the current rq. Moving a task to a local DSQ may switch to the source or destination rq before synchronously invoking ops.dequeue() through the following path: SCX_CALL_OP(dispatch, rq) ops.dispatch() scx_bpf_dsq_move_to_local() scx_flush_dispatch_buf() finish_dispatch() dispatch_to_local_dsq() scx_dispatch_enqueue() local_dsq_post_enq() call_task_dequeue() SCX_CALL_OP_TASK(dequeue, locked_rq, ...) The nested callback saves the recorded rq and restores it on return. If the rq tracking does not follow the lock switch, update_locked_rq() can trigger the following lockdep assertion while restoring an rq which is no longer held: WARNING: kernel/sched/sched.h:1641 at call_task_dequeue+0x160/0x170 Call Trace: scx_dispatch_enqueue+0x2b0/0x460 dispatch_to_local_dsq+0x138/0x230 scx_flush_dispatch_buf+0x1af/0x220 scx_bpf_dsq_move_to_local___v2+0xe2/0x1c0 bpf__sched_ext_ops_dispatch+0x4b/0xa7 do_pick_task_scx+0x3b6/0x910 __pick_next_task+0x105/0x1f0 __schedule+0x3e7/0x1980 Introduce switch_rq_lock() to update the tracking state together with each rq lock handoff. Use it in dispatch_to_local_dsq(), move_remote_task_to_local_dsq() and the in-balance paths of scx_dsq_move(), ensuring that scx_locked_rq() consistently refers to the rq whose lock is actually held throughout the lock dance.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS