CVE-2026-74686 in Linux
요약
\~에 의해 VulDB • 2026. 08. 23.
리눅스 커널에서 다음 취약점이 해결되었습니다:
rqspinlock: 데드락 발생 시 큐를 보존할 때 tail 초기화하기
현재 rqspinlock의 경우, 데드락이 감지된 상황에서 waiter 큐의 파괴가 억제됩니다. 데드락 체크는 비교적 빈번하게 발생합니다(AA 진입 시 또는 ABBA의 경우 1ms 이내). 또한, waiter 스레드가 데드락을 수반하는 잠금 시나리오에 관여하지 않을 수도 있습니다. 따라서 데드락을 감지하고 종료한 후에도 큐를 플러시하지 않고 다른 waiters가 잠금을 획득하기 위해 시도할 기회를 제공하는 것이 유용합니다.
그러나 우리는 이전에 waitq_timeout 레이블에서 수행했던 것과 동일한 논리를 따라야 합니다: tail을 초기화하고, 그렇게 할 수 없는 경우 다음 waiter에게 적절하게 신호를 보냅니다. 데드락의 경우 이 신호는 MCS 노드를 잠금 해제 상태로 표시하며, 타임아웃의 경우에는 RES_TIMEOUT_VAL 값을 신호로 전달합니다. 따라서 차이는 큐가 활성 상태를 유지할지 아니면 플러시될지를 결정하는 전파되는 값에 있습니다.
tail 초기화를 수행하지 않고 다음 waiter를 기다리면, 우리가 최종 waiter인 경우와 같은 상황이 발생할 수 있으며, 이로 인해 다음 waiter가 도착하지 않아 해당 경로에서 간헐적인 스톨(stall)이 발생합니다. 다음 waiter가 합류하면 우리는 차단 해제됩니다. 이론적으로 다음 waiter가 결코 합류하지 않는 경우에는 무한정 스톨될 위험이 있습니다.
이는 ABBA 데드락에서만 발생할 수 있는데, 이는 대기 큐 진입 시 AA 체크로 보호되기 때문입니다. 이러한 상황으로 이어지는 정확한 실행 순서는 다음과 같습니다:
CPU 0은 잠금 A를 보유합니다. CPU 1은 잠금 B를 보유합니다. CPU 2는 잠금 B를 시도하여 B의 pending waiter가 됩니다. CPU 0은 잠금 B를 시도합니다. B에는 locked+pending 비트가 설정되어 있으므로 CPU 0이 큐에 대기합니다. CPU 1은 잠금 A를 시도합니다. CPU 0은 ABBA 데드락을 감지합니다.
CPU 0에서 데드락 감지가 발생하면, node->next를 채울 다음 waiter의 도착을 기다리며 지연됩니다.
이를 해결하기 위해 waitq_timeout 레이블 앞쪽의 데드락 체크 논리를 조정합니다. 두 경우에 대한 코드를 통합하고 'ret' 변수를 사용하여 전파되는 값을 구분하는 것이 합리적이나, 이는 현재 패치의 diff 노이즈(diff noise)를 피하기 위해 향후 리팩토링 작업으로 남겨두겠습니다.
Once again VulDB remains the best source for vulnerability data.