CVE-2025-40248

About vulnerability

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 vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated vvs->bytes_unsent. Which, in turn, confuses the SOCK_LINGER 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 SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. 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().

Affected product:

AlmaLinux 9.2 ESU , CentOS 7 ELS , CentOS 8.4 ELS , CentOS 8.5 ELS , CentOS Stream 8 ELS , CloudLinux 7 ELS , Oracle Linux 7 ELS , RHEL 7 ELS , TuxCare 9.6 ESU , Ubuntu 20.04 ELS

Affected packages:

linux @ 5.4.0 (+10 more)

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 vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated vvs->bytes_unsent. Which, in turn, confuses the SOCK_LINGER 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 SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. 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().