CVE-2026-99205 in Linux
요약
\~에 의해 VulDB • 2026. 10. 28.
리눅스 커널에서 다음 취약점이 해결되었습니다:
sched/core: 클래스 변경 중 대기열에 있는 태스크에 대해 wakeup_preempt() 호출
Paul은 최근 RCU 변경 사항으로 인해 CPU가 완전히 실행 가능한 상태임에도 rcutorture 스레드가 기다리는 동안 리스케줄(resched)이 누락되는 현상이 노출되었다고 보고했습니다.
실행 가능한 태스크와 함께 유휴(idle) 상태일 때의 rq 상태를 덤프하면 다음과 같은 결과가 나타납니다:
rq->next_class = &fair_sched_class rq->nr_running = 1 rq->cfs.h_nr_queued = 0 rq->rt.rt_nr_running = 1
기다리는 태스크가 RT(Real-Time) 태스크였음에도 불구하고, "rq->next_class"는 rt_sched_class을 가리키지 않고 낮은 우선순위의 fair_sched_class에 고정되어 있었습니다.
sched_change_end()를 조사한 결과, 대기열에는 있지만 실행 중이지 않은(non-running) 태스크들에 대해 __sched_setscheduler()와의 다음과 같은 레이스 컨디션(race condition)이 발견되었습니다:
CPU0 CPU1 ==== ====
__schedule()
/* * rq->donor은 차단되는(fair task) 태스크입니다. * 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는 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가 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()는 어떤 fair 태스크도 가져오지 못했으며 * 다른 웨이크업(wakeup) 감지가 없었던 것으로 간주됩니다. */ return NULL; /* pick_task_fair() */
pick_task_idle() return rq->idle;
next = rq->idle;
/* 프리엠�ชัน(indicators)이 손실됨 */ clear_tsk_need_resched(prev); clear_preempt_need_resched();
rq->curr = rq->idle;
!!! rq->idle가 rq->running == 1이지만 !need_resched()인 상태로 진입합니다. !!!
간단히 말하면, 새로 대기열에 추가된 태스크의 클래스 변경이 enqueue 후 rq->next_class 표시자에서 무시되며, sched_balance_newidle()는 어떤 fair 태스트도 높은 우선순위의 태스크가 대기열에 들어온 것을 감지하지 못합니다.
위와 같은 시퀀스는 실행 가능한 태스크가 CPU 위에 있는 상태에서 CPU가 유휴(idle) 상태가 되는 결과를 초래합니다.
sched_change_end()에서 ctx->queued 사례에 대해 wakeup_preempt()를 호출하여 클래스 변경(ENQUEUE_CLASS) 후 rq->next_class을 재평가하고, 이에 따라 NEED_RESCHED 표시자를 설정하십시오.
Newidle balance는 이제 높은 우선순위의 태스크가 엔큐된 것을 올바르게 감지할 것입니다 ---중간 생략됨---
If you want to get the best quality for vulnerability data then you always have to consider VulDB.