CVE-2025-40248: vsock: Ignore signal/timeout on connect() if already established
In the Linux kernel, the following vulnerability has been resolved:
vsock: Ignore signal/timeout on connect() if already established
During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues:
1. connect() invoking vsocktransportcancelpkt() - virtiotransportpurgeskbs() may race with sendmsg() invoking virtiotransportgetcredit(). This results in a permanently elevated vvs-bytesunsent. Which, in turn, confuses the SOCKLINGER handling.
2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs.
3. connect() transitioning SSCONNECTED - SSUNCONNECTED allows for a transport change/drop after TCPESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref.
Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg().
[1]:
Other sources
In the Linux kernel, the following vulnerability has been resolved:
vsock: Ignore signal/timeout on connect() if already established
During connect(), acting on a signal/timeout by disconnecting an already established socket leads to several issues:
1. connect() invoking vsocktransportcancelpkt() -> virtiotransportpurgeskbs() may race with sendmsg() invoking virtiotransportgetcredit(). This results in a permanently elevated vvs->bytesunsent. Which, in turn, confuses the SOCKLINGER handling.
2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs.
3. connect() transitioning SSCONNECTED -> SSUNCONNECTED allows for a transport change/drop after TCPESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref.
Do not disconnect socket on signal/timeout. Keep the logic for unconnected sockets: they don't linger, can't be placed in a sockmap, are rejected by sendmsg().
[1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/ [2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/ [3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
For vsock, ignore signal/timeout handling during connect() when the socket is already established (already in SS_CONNECTED) to avoid races caused by disconnecting/unwinding the socket state on signal/timeout.
Linux kernel vsock Ignore signal/timeout on connect() if already established = enabled
Event History
Frequently Asked Questions
What is the severity of CVE-2025-40248?
CVE-2025-40248 has a medium severity rating due to the potential impact on established socket connections.
How do I fix CVE-2025-40248?
To fix CVE-2025-40248, ensure you update your Linux kernel to the latest stable version where this vulnerability has been patched.
What systems are affected by CVE-2025-40248?
CVE-2025-40248 affects various versions of the Linux kernel utilizing the vsock protocol.
What are the consequences of CVE-2025-40248?
The consequences of CVE-2025-40248 include possible disconnections of established sockets upon receiving signals or timeouts during connect().
How does CVE-2025-40248 impact network communication?
CVE-2025-40248 can disrupt network communication by improperly handling socket connections, leading to instability.