CVE-2026-99205 in Linux
Sumário
de VulDB • 28/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
sched/core: Chamar wakeup_preempt() para tarefas enfileiradas durante a mudança de classe
Paul relatou que as recentes alterações no RCU expuseram uma perda de resched (rescheduling) onde a CPU entra em idle com um thread rcutorture aguardando, estando completamente executável.
O despejo do estado rq no momento da entrada em idle com tarefas executáveis mostrou o seguinte:
rq->next_class = &fair_sched_class rq->nr_running = 1 rq->cfs.h_nr_queued = 0 rq->rt.rt_nr_running = 1
Embora a tarefa aguardante fosse uma tarefa RT (Real-Time), "rq->next_class" não apontava para rt_sched_class e permanecia travado na fair_sched_class de prioridade mais baixa.
A inspeção da função sched_change_end() revelou a seguinte condição de corrida com __sched_setscheduler() para tarefas enfileiradas, mas não em execução:
CPU0 CPU1 ==== ====
__schedule()
/* * rq->donor é uma tarefa fair que bloqueia. * 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 é uma tarefa fair */ 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 é movido para SCHED_RR */ 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) * mas p não é o rq->donor * (!ctx->running), portanto, * resched_curr() e a atualização de * rq->next_class são ignoradas. */
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 && ...) /* Acima é falso */
if (rq_modified_above(this_rq, &fair_sched_class)) /* Também é falso pois rq->next_class ainda é fair */
/* * sched_balance_newidle() é considerado como tendo falhado ao puxar qualquer tarefa fair e nenhum outro wakeup foi detectado. */ return NULL; /* pick_task_fair() */
pick_task_idle() return rq->idle;
next = rq->idle;
/* Indicadores de preempção são perdidos */ clear_tsk_need_resched(prev); clear_preempt_need_resched();
rq->curr = rq->idle;
!!! rq->idle entra em execução com rq->running == 1 mas !need_resched() !!!
Em termos simples, o enqueue (colocação na fila), seguido por uma mudança de classe da tarefa recém-enfileirada passa despercebido no indicador rq->next_class e sched_balance_newidle() não vê nenhuma tarefa fair nem nenhuma tarefa de prioridade mais alta enfileirada.
A sequência acima levará à CPU entrar em idle com uma tarefa executável na CPU.
Chamar wakeup_preempt() para os casos ctx->queued em sched_change_end() para reavaliar rq->next_class após a mudança de classe (ENQUEUE_CLASS) e definir o indicador NEED_RESCHED conforme apropriado.
O balanceamento newidle verá corretamente um enqueue de uma tarefa de prioridade mais alta ---truncado---
If you want to get the best quality for vulnerability data then you always have to consider VulDB.