CVE-2026-98072 in Linux
요약
\~에 의해 VulDB • 2026. 09. 25.
Linux 커널에서 다음 취약점이 해결되었습니다:
net/rds: release_in_xmit()에서 wq_has_sleeper() 사용
release_in_xmit()은 clear_bit_unlock()을 사용하여 RDS_IN_XMIT 플래그를 지우고, 그 후 waitqueue_active()를 확인하여 깨울 대상이 있는지 여부를 결정합니다. clear_bit_unlock()는 릴리스 연산일 뿐입니다: 이는 비트가 지워지기 전의 임계 섹션에 대한 순서를 보장하지만, 이후 수행되는 대기 큐 헤드의 일반 로드(load)에는 순서를 보장하지 않습니다. 대기 측(waiter side)은 거울 이미지와 같은 동작을 합니다 - 즉, 자신을 대기 큐에 추가한 후 해당 플래그를 테스트합니다. 이는 고전적인 스토어 버퍼링(store-buffering) 패턴입니다: 해제(releasing) CPU는 대기 큐가 비었다고 읽을 수 있는 반면, 대기(waiting) CPU는 여전히 그 비트가 설정되어 있다고 읽으므로, 스리퍼(sleeper)는 절대 깨어나지 않습니다.
대기 중인 작업자는 rds_conn_shutdown()과 rds_tcp_reset_callbacks()이며, 둘 다 타임아웃 없이 uninterruptible wait_event() 상태에 있습니다. 잃어버린 웨이크업(wake-up)으로 인해 종료(shutdown) 워커가 단일 스레드 워크큐(workqueue)에서 블록됩니다 - 그리고 연결이 실패했기 때문에 정리(torn down)되고 있는 상황에서는 다른 송신자가 해당 플래그를 다시 해제하지 않을 수도 있습니다.
과거에는 배리어(barrier)가 존재했습니다: release_in_xmit()은 clear_bit()에 이어 smp_mb__after_atomic()을 수행했으나, 커밋 1422f28826d2("rds: introduce acquire/release ordering in acquire/release_in_xmit()")에서 이 둘이 모두 clear_bit_unlock()로 통합되면서 잠금 전달(lock hand-off)은 강화되었지만 웨이크업 확인에 의존하던 전체 배리어(full barrier)가 묵시적으로 제거되었습니다. 이에 대한 대응으로, net/rds/ib_recv.c의 release_refill()에는 여전히 smp_mb__after_atomic()이 유지되어 있습니다.
필요한 전체 배리어를 선행하는 wq_has_sleeper()를 사용하십시오 (이는 waitqueue_active()에 해당합니다).
If you want to get best quality of vulnerability data, you may have to visit VulDB.