CVE-2026-64374 in Linux
요약
\~에 의해 VulDB • 2026. 07. 25.
리눅스 커널에서 다음 취약점이 해결되었습니다:
sched/rt: 비 PREEMPT_RT 환경에서는 RT_PUSH_IPI를 기본적으로 비활성화합니다.
RT 마이그레이션은 공격적으로 수행됩니다. CPU가 낮은 우선순위 태스크보다 높은 우선순위의 RT(Real-Time) 태스크를 스케줄 아웃할 때, 다른 CPU에서 더 높은 우선순위를 가진 대기 중인 RT 태스크가 있는지 확인합니다. 만약 발견되면 해당 태스크를 현재 CPU로 가져와 실행하도록 합니다.
일반적으로 이 'pull' 작업은 rto(RT overloaded mask)를 참조하여 수행되는데, 여기에는 현재 자신의 CPU에서 더 높은 우선순위 RT 태스크가 실행 중이어서 대기 중인 RT 태스크들을 가진 스케줄러 도메인의 모든 CPU 정보가 포함되어 있습니다. 낮은 우선순위 태스크를 스케줄링하려는 CPU는 과부하 상태인 CPU의 rq(runqueue) 잠금을 획득하여 해당 CPU의 runqueue에서 RT 태스크를 가져와 로컬 runqueue로 이동시키고 더 높은 우선순위의 RT 태스크를 실행합니다.
이 방식은 많은 CPU가 동시에 낮은 우선순위 태스크를 스케줄링할 때 문제를 일으켰습니다. 모든 CPU가 과부하 상태인 RT 태스크들을 가진 CPU의 동일한 runqueue 잠금을 획득하려고 시도했습니다. 먼저 접근한 CPU만 해당 태스크를 가져갈 수 있었고, 나머지 CPU들은 runqueue 잠금을 얻어내고 실제로 이동시킬 것이 없음을 확인하여 아무 작업도 수행하지 않고 대기해야 했습니다. 많은 CPU를 갖춘 시스템에서는 이로 인해 최대 500us에 달하는 큰 지연(latency)이 발생했으며, 이는 PREEMPT_RT가 허용하는 범위를 벗어난 수치였습니다.
이에 대한 해결책으로 RT_PUSH_IPI 로직을 도입했습니다. 어떤 CPU든 태스크를 가져오려 할 때 과부하 상태인 CPU의 runqueue 잠금을 획득하는 대신, 먼저 해당 과부하 CPU로 IPI(Inter-Processor Interrupt)를 보내고, 그 IPI 핸들러가 대기 중인 RT 태스크를 가진 CPU에서 'push' 작업을 수행하도록 합니다. 그런 다음 해당 핸들러는 또 다른 과부하 상태의 RT 태스크들을 가진 다음 CPU로 IPI를 보내는 식으로 과정을 계속합니다. 참고로 첫 번째 CPU가 이 프로세스를 시작한 후, 만약 다른 CPU도 pull을 시도한다면 이미 프로세스가 시작되었음을 인지하고 IPI 전송이 다시 이루어지도록 카운터만 증가시킵니다.
RT_PUSH_IPI는 PREEMPT_RT에서의 지연 문제를 해결했지만 비 PREEMPT_RT 환경에서는 새로운 문제를 야기할 수 있습니다. 즉, softirqs는 PREEMPT_RT에서 스레드 컨텍스트로 실행되지만 non-RT(일반 커널)에서는 인터럽트 컨텍스트에서 실행될 수 있습니다.
만약 IPI가 여러 RT 태스크를 깨운 직후의 CPU에 도달하고 현재 해당 CPU가 비 RT 또는 낮은 우선순위의 RT 태스크를 실행 중이라면, push 대신 단순히 그 CPU에서 스케줄링을 수행하게 됩니다. 하지만 이 CPU에서 softirq도 동시에 실행 중인 경우, 스케줄링은 softirq가 완료될 때까지 대기해야 합니다. 이때까지 해당 CPU는 여전히 과부하 상태로 간주됩니다(실행 가능한 RT 태스크들이 아직 대기 중이므로).
대규모 머신에서 네트워크 트래픽을 많이 처리하는 워크로드에서 라이브 락(live lock) 현상이 발생했는데, 이 경우 softirqs가 750us 중 500us 동안 실행되었으며 동시에 RT 태스크들을 깨워 RT pull 로직이 지속적으로 실행되도록 했습니다.
RT 태스트들이 큐에 있지만 아직 실행되지 않은 CPU에서 softirq가 트리거되면, 다른 CPU들은 이 CPU를 과부하 상태로 간주하고 IPI를 보냅니다. 해당 CPU는 대기 중인 RT 태스크들의 우선순위가 현재 실행 중인 태스크보다 높음을 인지하고 단순히 스케줄링
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.