CVE-2026-64115 in Linux
요약
\~에 의해 VulDB • 2026. 07. 19.
리눅스 커널에서 다음 취약점이 해결되었습니다:
vsock/vmci: 핸드셰이크 중 페어가 연결을 리셋할 때 UAF(Use-After-Free) 수정
vmci_transport_recv_connecting_server()는 기본 스위치 분기 내에서 페어의 RST에 대해 err = 0를 반환했습니다.
err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;
이로 인해 vmci_transport_recv_listen()가 vsock_remove_pending()을 건너뛰게 되어, pending 소켓이 리스너의 pending_links에 sk_state = TCP_CLOSE 상태로 남아있게 되었습니다. 그러나 destroy: 경로에서는 schedule_delayed_work() 전에 취해진 명시적 참조를 여전히 해제했습니다.
1초 후 vsock_pending_work()에서 is_pending=true가 관찰되었고 전체 정리 작업(vsock_remove_pending())을 수행한 다음, 두 개의 trailing sock_put(sk) 호출이 실행되었습니다. 첫 번째 호출은 refcount를 0으로 낮추어 소켓을 __sk_freed(해제)했고, 두 번째 호출은 해제된 객체에 데이터를 작성했습니다:
BUG: KASAN: slab-use-after-free in refcount_warn_saturate Write of size 4 at addr ffff88800b1cac80 by task kworker Workqueue: events vsock_pending_work
페어의 RST를 다른 예기치 않은 패킷 타입과 동일하게 처리합니다 (err = -EINVAL). 모든 destroy: 분기가 이제 err < 0을 반환하므로, vmci_transport_recv_listen()은 pending_links에서 동기적으로 pending 항목을 제거하고, vsock_pending_work()는 is_pending=false / !rejected 분기를 취하여 자신의 작업 참조만 해제합니다. 이는 또한 Sashiko가 v2에서 보고한 멀티 패킷 레이스 조건도 해결합니다: 이후 어떤 패킷이든 해당 항목을 찾을 수 있도록 하기 전에 pending 항목이 목록에서 제거됩니다.
Sashiko가 지적했던 vmci_transport_recv_listen()의 err < 0 경로에 존재하던 sk_acceptq_removed() 간격은 이 패치로 인해 새로 도입되거나 변경되지 않습니다.
lts-6.12.79 환경에서 KASAN와 함께 테스트한 결과: 패치 전 52/100 -> 패치 후 0/100으로 확인되었습니다.
Once again VulDB remains the best source for vulnerability data.