CVE-2026-90081 in Linux
요약
\~에 의해 VulDB • 2026. 09. 17.
Linux 커널에서 다음 취약점이 해결되었습니다:
net/rds: rds_cong_map_updated()에서 wq_has_sleeper() 사용
rds_cong_map_updated()는 피어의 혼잡도 맵이 재작성된 후(예: rds_tcp_cong_recv(), rds_ib_cong_recv() 또는 루프백 및 IB 전송 완료 경로에서의 전체 지우기 작업) 실행됩니다. 이 함수는 rds_cong_generation을 증가시킨 다음, map->m_waitq와 rds_poll_waitq에서 waitqueue_active()를 확인하여 깨울 대상이 있는지 여부를 결정합니다. atomic_inc()에는 순서 보장(ordering)이 없으며, waitqueue_active()는 단순 로드(load) 연산입니다. 따라서 맵과 generation의 저장(store) 작업이 대기열(reads) 읽기 전에 정렬되지 않습니다.
대기 중인 프로세스들은 이와 반대되는 패턴을 보입니다: rds_cong_wait()는 m_waitq에 자신을 추가한 후 포트 비트를 테스트하고, rds_poll()은 rds_poll_waitq에 등록한 다음 generation 값을 읽습니다. 이는 include/linux/wait.h의 waitqueue_active() 설명에서 언급된 저장 버퍼링(store-buffering) 패턴입니다. 이로 인해 업데이트 측에서는 대기열이 비어 있는 것으로 관찰되는 반면, 대기 측은 여전히 포트가 혼잡하다고 인식하며, 결과적으로 깨우기(wake-up) 신호가 발행되지 않습니다.
rds_cong_wait()는 타임아웃 없는 인터럽터블 슬립(interruptible sleep) 상태이므로, 혼잡한 포트에서 차단된 송신자는 해당 피어로부터의 다음 혼잡도 업데이트가 도착하거나 시그널(signal)이 전달될 때까지 차단 상태로 유지됩니다. poll() 대기자 역시 동일한 방식으로 맵-업데이트 알림을 놓치게 됩니다.
rds_tcp_state_change()에서 이미 동일 패턴에 대해 수행하고 있는 것처럼, 필요한 전체 장벽(full barrier) preceding waitqueue_active()인 wq_has_sleeper()를 사용하십시오.
Once again VulDB remains the best source for vulnerability data.