CVE-2026-64115 in Linux
Tóm tắt
Bởi VulDB • 20/07/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
vsock/vmci: sửa lỗi Use-After-Free (UAF) khi peer gửi RST để đóng kết nối trong quá trình bắt tay (handshake).
Hàm `vmci_transport_recv_connecting_server()` trả về `err = 0` cho trường hợp peer gửi RST tại nhánh mặc định của câu lệnh switch:
err = pkt->type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;
Điều này khiến hàm `vmci_transport_recv_listen()` bỏ qua việc gọi `vsock_remove_pending()`, để lại socket đang chờ trong danh sách `pending_links` của trình nghe với trạng thái `sk_state = TCP_CLOSE`. Trong khi đó, khối mã dọn dẹp (`destroy:`) vẫn giải phóng tham chiếu rõ ràng đã được lấy trước khi lên lịch thực hiện `schedule_delayed_work()`.
Một giây sau, hàm `vsock_pending_work()` quan sát thấy cờ `is_pending=true` và tiến hành dọn dẹp đầy đủ: gọi `vsock_remove_pending()` rồi hai lệnh gọi tiếp theo là `sock_put(sk)`. Lệnh gọi đầu tiên làm cho bộ đếm tham chiếu (refcount) giảm về 0 và giải phóng socket (`__sk_freed`), còn lệnh gọi thứ hai ghi vào đối tượng đã bị giải phóng:
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
Xử lý RST từ peer giống như bất kỳ loại gói tin không mong đợi nào khác (đặt `err = -EINVAL`). Tất cả các nhánh `destroy:` hiện trả về giá trị `err < 0`, do đó `vmci_transport_recv_listen()` sẽ xóa mục đang chờ khỏi danh sách `pending_links` một cách đồng bộ, và hàm `vsock_pending_work()` sẽ đi vào nhánh có điều kiện `is_pending=false / !rejected`, chỉ giải phóng tham chiếu công việc của riêng nó. Điều này cũng khắc phục race condition đa gói tin mà Sashiko đã báo cáo trên phiên bản v2: mục đang chờ bị xóa khỏi danh sách trước khi bất kỳ gói tin tiếp theo nào có thể tìm thấy nó.
Khoảng trống `sk_acceptq_removed()` tồn tại từ trước trên đường dẫn `err < 0` của hàm `vmci_transport_recv_listen()`, mà Sashiko cũng đã lưu ý, không phải do bản vá này giới thiệu hay thay đổi.
Đã kiểm thử trên phiên bản lts-6.12.79 với KASAN: kết quả trước khi áp dụng bản vá là 52/100 lỗi phát hiện được -> sau khi áp dụng bản vá giảm xuống còn 0/100.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.