CVE-2026-99205 in Linux
Tóm tắt
Bởi VulDB • 28/10/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
sched/core: Gọi wakeup_preempt() cho các tác vụ đang chờ trong hàng đợi khi thay đổi lớp ưu tiên (class)
Paul báo cáo rằng những thay đổi gần đây đối với RCU đã làm lộ ra một trường hợp mất tín hiệu resched, nơi CPU ở trạng thái nhàn rỗi (idle) trong khi có một luồng rcutorture đang chờ nhưng hoàn toàn sẵn sàng chạy.
Việc dump trạng thái rq tại thời điểm idle cùng với các tác vụ runnable cho thấy như sau:
rq->next_class = &fair_sched_class rq->nr_running = 1 rq->cfs.h_nr_queued = 0 rq->rt.rt_nr_running = 1
Mặc dù tác vụ đang chờ là một RT task, "rq->next_class" không trỏ đến rt_sched_class mà bị mắc kẹt ở lớp fair_sched_class có độ ưu tiên thấp hơn.
Việc kiểm tra sched_change_end() tiết lộ race condition sau với __sched_setscheduler() đối với các tác vụ đã được enqueue nhưng chưa chạy:
CPU0 CPU1 ==== ====
__schedule()
/* * rq->donor là một fair task bị block. * 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 là một fair task */ 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 được chuyển sang 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) * nhưng p không phải là rq->donor * (!ctx->running) do đó * resched_curr() và việc nâng cấp * rq->next_class bị bỏ qua. */
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 && ...) /* Điều kiện trên là sai */
if (rq_modified_above(this_rq, &fair_sched_class)) /* Cũng sai vì rq->next_class vẫn là fair */
/* * sched_balance_newidle() được coi là đã không pull được bất kỳ fair task nào và không có wakeups khác được phát hiện. */ return NULL; /* pick_task_fair() */
pick_task_idle() return rq->idle;
next = rq->idle;
/* Các chỉ báo preemption bị mất */ clear_tsk_need_resched(prev); clear_preempt_need_resched();
rq->curr = rq->idle;
!!! rq->idle chuyển vào với rq->running == 1 nhưng !need_resched() !!!
Nói một cách đơn giản, việc enqueue, tiếp theo là thay đổi lớp ưu tiên (class) của tác vụ vừa được enqueue, bị bỏ qua trong chỉ báo rq->next_class và sched_balance_newidle() không thấy có fair task nào hay bất kỳ tác vụ độ ưu tiên cao hơn nào đã được enqueue.
Chuỗi sự kiện trên sẽ dẫn đến CPU ở trạng thái nhàn rỗi (idling) trong khi vẫn còn một tác vụ sẵn sàng chạy trên CPU đó.
Gọi wakeup_preempt() cho các trường hợp ctx->queued trong sched_change_end() để đánh giá lại rq->next_class sau khi thay đổi lớp ưu tiên (ENQUEUE_CLASS) và đặt chỉ báo NEED_RESCHED tương ứng.
Newidle balance sẽ thấy chính xác việc enqueue của một tác vụ có độ ưu tiên cao hơn ---truncated---
If you want to get the best quality for vulnerability data then you always have to consider VulDB.