CVE-2026-99205 in Linux
Zusammenfassung
von VulDB • 28.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
sched/core: Aufruf von wakeup_preempt() für wartende Aufgaben während der Klassenänderung
Paul meldete, dass kürzliche RCU-Änderungen einen verlorenen Reschedule (resched) offengelegt haben, bei dem die CPU im Leerlauf ist, während ein rcutorture-Thread wartet und vollständig lauffähig ist.
Das Dumping des rq-Zustands zum Zeitpunkt der Leerlaufeinrichtung mit lauffähigen Aufgaben zeigte Folgendes:
rq->next_class = &fair_sched_class rq->nr_running = 1 rq->cfs.h_nr_queued = 0 rq->rt.rt_nr_running = 1
Obwohl die wartende Aufgabe eine RT-Aufgabe war, verweist „rq->next_class“ nicht auf rt_sched_class und bleibt an der fair_sched_class mit niedrigerer Priorität hängen.
Die Inspektion von sched_change_end() offenbarte folgende Race Condition (Wettlaufsituation) mit __sched_setscheduler() für wartende, aber nicht laufende Aufgaben:
CPU0 CPU1 ==== ====
__schedule()
/* * rq->donor ist eine fair-Aufgabe, die blockiert. * rq->next_class = &fair_sched_class */
rq_lock(rq0)
pick_next_task() /* nr_running = 0 */ pick_task_fair() sched_balance_newidle() raw_spin_rq_unlock(rq0) rq_lock(rq0)
activate_task(rq0, p) /* p ist eine fair-Aufgabe */ rq0->nr_running++; rq0->cfs.h_nr_queued++; wakeup_preempt(rq, p) rq->next_class = &fair_sched_class resched_curr()
rq_unlock(rq0)
__sched_setscheduler(p) /* p wird zu SCHED_RR verschoben */ task_rq_lock(p) sched_change_begin()
rq0->cfs.h_nr_queued--; rq0->rt.rt_nr_running++;
sched_change_end() /* * p->on_rq = 1 (ctx->queued) * aber p ist nicht rq->donor * (!ctx->running), daher wird * resched_curr() übersprungen und * das Upgrade von rq->next_class * wird übergangen. */
task_rq_unlock()
raw_spin_rq_lock(rq0)
/* * rq->nr_running = 1 * rq->cfs.h_nr_queued = 0 * rq->rt.rt_nr_running = 1 * rq->next_class = &fair_sched_class */
if (rq->cfs.h_nr_queued && ...) /* Obiges ist falsch */
if (rq_modified_above(this_rq, &fair_sched_class)) /* Auch falsch, da rq->next_class immer noch fair ist */
/* * sched_balance_newidle() gilt als gescheitert beim Ziehen von * beliebigen fair-Aufgaben und es wurden keine anderen Wakeups erkannt. */ return NULL; /* pick_task_fair() */
pick_task_idle() return rq->idle;
next = rq->idle;
/* Preemption-Indikatoren gehen verloren */ clear_tsk_need_resched(prev); clear_preempt_need_resched();
rq->curr = rq->idle;
!!! rq->idle schaltet ein mit rq->running == 1, aber !need_resched() !!!
Einfach ausgedrückt: Das Enqueue (Warteschlangeneinreihung), gefolgt von einer Klassenänderung der neu eingereihten Aufgabe, bleibt im Indikator rq->next_class unbemerkt und sched_balance_newidle() sieht keine fair-Aufgabe noch eine andere hochpriorisierte Aufgabe in der Warteschlange.
Die obige Sequenz führt dazu, dass die CPU im Leerlauf ist, während sich eine lauffähige Aufgabe auf der CPU befindet.
Aufruf von wakeup_preempt() für ctx->queued-Fälle in sched_change_end(), um rq->next_class nach der Klassenänderung (ENQUEUE_CLASS) neu zu bewerten und den NEED_RESCHED-Indikator entsprechend festzulegen.
Newidle-Balance wird korrekt ein Enqueue einer höher priorisierten Aufgabe erkennen ---abgeschnitten---
If you want to get the best quality for vulnerability data then you always have to consider VulDB.