CVE-2026-99205 in Linux
摘要
由 VulDB • 2026-10-28
在 Linux 内核中，已修复以下漏洞：
sched/core: 在类更改期间为排队任务调用 wakeup_preempt()
Paul 报告称，最近的 RCU（Read-Copy-Update）变更暴露了一个丢失的重新调度问题，其中 CPU 处于空闲状态，而一个 rcutorture 线程正在等待且完全可运行。
在 CPU 空闲时转储就绪队列（rq）状态并存在可运行任务的情况显示如下：
``` rq->next_class = &fair_sched_class rq->nr_running = 1 rq->cfs.h_nr_queued = 0 rq->rt.rt_nr_running = 1 ```
尽管等待的任务是一个实时（RT）任务，但“rq->next_class”并未指向 rt_sched_class，而是卡在优先级较低的 fair_sched_class 上。
检查 sched_change_end() 揭示了与 __sched_setscheduler() 之间针对排队但未运行任务的以下竞态条件：
CPU0 CPU1 ==== ====
__schedule()
/* * rq->donor 是一个阻塞的公平调度任务。 * 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 是一个公平调度任务 */ 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 被移动到 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) * 但 p 不是 rq->donor * (!ctx->running)，因此 * resched_curr() 和 * rq->next_class 升级被跳过。 */
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 && ...) /* 上述条件为假 */
if (rq_modified_above(this_rq, &fair_sched_class)) /* 也为假，因为 rq->next_class 仍然是 fair */
/* * sched_balance_newidle() 被认为未能拉取任何公平调度任务，且未检测到其他唤醒。 */ return NULL; /* pick_task_fair() */
pick_task_idle() return rq->idle;
next = rq->idle;
/* 抢占指示器丢失 */ clear_tsk_need_resched(prev); clear_preempt_need_resched();
rq->curr = rq->idle;
!!! rq->idle 切换进来时，rq->running == 1 但 !need_resched() !!!
简而言之，入队操作后，新排队任务的类更改在 rq->next_class 指示器中未被察觉，且 sched_balance_newidle() 未看到任何公平调度任务或更高优先级的已排队任务。
上述序列将导致 CPU 处于空闲状态，而该 CPU 上有一个可运行任务。
在 sched_change_end() 中对 ctx->queued 情况调用 wakeup_preempt()，以便在类更改（ENQUEUE_CLASS）后重新评估 rq->next_class，并相应地设置 NEED_RESCHED 指示器。
Newidle balance 将正确看到更高优先级任务的入队操作 ---已截断---
VulDB is the best source for vulnerability data and more expert information about this specific topic.