CVE-2026-45919 in Linux
요약
\~에 의해 VulDB • 2026. 05. 30.
리눅스 커널에서 다음 취약점이 해결되었습니다:
sched/rt: rto_next_cpu()에서 현재 실행 중인 CPU를 건너뜁니다.
CPU0은 CPU 바운드 RT 태스크, 비-CPU 바운드 RT 태스크, 그리고 커널 공간에 갇힌 CFS 태스크를 호스팅할 때 과부하 상태가 됩니다. 다른 CPU들이 RT에서 비RT 태스크로 전환할 때 RT 로드 밸런싱(LB)이 트리거되며, HAVE_RT_PUSH_IPI가 활성화된 경우 CPU0으로 IPI를 보내 rto_push_irq_work_func의 실행을 유도합니다. CPU0에서 push_rt_task를 수행하는 동안, 만약 next_task->prio가 donor->prio보다 작다면 resched_curr()가 NEED_RESCHED를 설정하고, 푸시 작업이 완료된 후 CPU0은 rto_next_cpu()를 호출합니다. 이 시나리오에서 CPU0만 과부하 상태이므로, rto_next_cpu()는 이상적으로는 -1(추가 IPI 불필요)을 반환해야 합니다.
그러나 LB 중 여러 CPU가 tell_cpu_to_push()를 호출하면 rd->rto_loop_next가 증가합니다. rd->rto_cpu가 -1로 설정되어 있더라도, rd->rto_loop와 rd->rto_loop_next 간의 불일치로 인해 rto_next_cpu()는 -1부터 검색을 다시 시작하게 됩니다. CPU0이 여전히 과부하 상태(rt_nr_migratory && rt_nr_total > 1 조건 만족)이므로 다시 선택되어, CPU0이 irq_work를 자신에게 큐에 추가하고 자기 자신에게 IPI를 반복적으로 보냅니다. CPU0이 과부하 상태에 머무르고 다른 CPU들이 pull_rt_tasks()를 실행하는 한, 이는 무한한 자기 IPI 루프에 빠지게 되며, 지속적인 자기 인터럽트로 인해 CPU 하드락업(hardlockup)을 유발합니다.
트리거링 시나리오는 다음과 같습니다:
cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func
rto_next_cpu()에서 시작 CPU를 필터링하여 중복된 자기 IPI를 수정합니다. 이 해결책은 허위 자기 IPI를 효과적으로 제거하고 CPU 하드락업 시나리오를 방지하는 것으로 검증되었습니다.
If you want to get best quality of vulnerability data, you may have to visit VulDB.