CVE-2026-64115

Linux 커널에서는 다음 취약점이 해결되었습니다.

vsock/vmci: 핸드셰이크 중에 피어가 연결을 재설정할 때 UAF 수정

vmci_transport_recv_connecting_server()가 피어에 대해 err = 0을 반환했습니다. 기본 스위치 암의 RST:

오류 = pkt->유형 == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;

이로 인해 vmci_transport_recv_listen()이 vsock_remove_pending()을 건너뛰게 되었습니다. 리스너의 보류 중인_링크에 보류 중인 소켓을 남겨 둡니다. sk_state = 파괴하는 동안 TCP_CLOSE: 여전히 명시적인 항목을 삭제했습니다. Schedule_delayed_work() 이전에 작성된 참조입니다.

1초 후 vsock_pending_work()가 is_pending=true를 관찰하고 전체 정리 수행: vsock_remove_pending() 그 다음 두 개의 후행 sock_put(sk) 호출 -- 처음으로 도달한 참조 횟수 0 및 __sk_freed 소켓, 두 번째는 해제된 개체에 썼습니다.

버그: KASAN: refcount_warn_saturate에서 slab-use-after-free task kworker에 의해 addr ffff88800b1cac80에 크기 4 쓰기 작업 대기열: 이벤트 vsock_pending_work

피어 RST를 다른 예상치 못한 패킷 유형(err = -EINVAL)처럼 처리합니다. 모든 destroy: arm은 이제 err < 0을 반환하므로 vmci_transport_recv_listen() Pending_links에서 보류 중인 항목을 동기식으로 제거하고 vsock_pending_work()는 is_pending=false / !rejected 분기를 사용합니다. 자체 작업 참조만 삭제합니다. 이것은 또한 v2에서 보고된 다중 패킷 경주 Sashiko: 보류 중이 제거되었습니다. 후속 패킷이 이를 찾을 수 있기 전의 목록입니다.

err < 0 경로의 기존 sk_acceptq_removed() 간격 Sashiko도 언급한 vmci_transport_recv_listen()은 그렇지 않습니다. 이번 패치로 도입되거나 변경되었습니다.

KASAN을 사용하여 lts-6.12.79에서 테스트되었습니다. 52/100 패치되지 않음 -> 0/100 패치됨.