CVE-2025-40248

Vulnerability

In the Linux kernel's vsock implementation, the connect() system call could be interrupted by a signal or timeout even after the socket had already transitioned to the SS_CONNECTED state. When this happened, the kernel would incorrectly tear down the established connection, leading to a race condition with concurrent sendmsg() operations and potential corruption of internal state.

Exploitation

An attacker who can trigger a signal or timeout on a vsock socket during the connect() call—for example, by sending a signal to the process or by exploiting a network timeout—can cause the kernel to invoke vsock_transport_cancel_pkt(), which may race with virtio_transport_get_credit() called from sendmsg(). This race can leave the bytes_unsent counter permanently elevated, confusing the SOCK_LINGER handling. Additionally, resetting a connected socket's state can race with the socket being placed in a sockmap, leading to a disconnected socket remaining in the map and triggering kernel warnings (WARNs).

Impact

A successful exploit can result in a use-after-free or NULL-pointer dereference, as the socket transitions from SS_CONNECTED to SS_UNCONNECTED after the connection was already established, allowing a transport change or drop after TCP_ESTABLISHED. This can crash the system or potentially allow an attacker to escalate privileges. The vulnerability.

Mitigation

The fix, applied in multiple stable kernel commits [1][2][3][4], ensures that connect() does not disconnect an already-established socket on signal or timeout. The logic for unconnected sockets remains unchanged, as they cannot be placed in a sockmap and are rejected by sendmsg(). Users should update to a patched kernel version.