Описание
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:
- 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. - 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.
- 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().
[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/
A flaw was found in the Linux kernel'svsockcomponent. This vulnerability occurs when aconnect()operation on an already established socket is interrupted by a signal or timeout, causing the system to mishandle the socket's state. This incorrect handling can lead to a race condition, potentially resulting in memory corruption, such as a use-after-free or null-pointer dereference. A local attacker could exploit this to cause a denial of service or potentially escalate privileges.
Отчет
This vulnerability is rated Important for Red Hat Enterprise Linux 7, 8, 9, and 10. A flaw in the Linux kernel's vsock component allows a local attacker to cause memory corruption, potentially leading to a denial of service or privilege escalation. This occurs when a connect() operation on an established socket is interrupted by a signal or timeout, leading to an incorrect handling of the socket's state.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 6 | kernel | Not affected | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Affected | ||
| Red Hat Enterprise Linux 10 | kernel | Fixed | RHSA-2026:1690 | 02.02.2026 |
| Red Hat Enterprise Linux 10.0 Extended Update Support | kernel | Fixed | RHSA-2026:1727 | 02.02.2026 |
| Red Hat Enterprise Linux 7 Extended Lifecycle Support | kernel-rt | Fixed | RHSA-2026:1623 | 02.02.2026 |
| Red Hat Enterprise Linux 7 Extended Lifecycle Support | kernel | Fixed | RHSA-2026:1581 | 29.01.2026 |
| Red Hat Enterprise Linux 8 | kernel-rt | Fixed | RHSA-2026:1148 | 26.01.2026 |
| Red Hat Enterprise Linux 8 | kernel | Fixed | RHSA-2026:1142 | 26.01.2026 |
| Red Hat Enterprise Linux 8 | kpatch-patch | Fixed | RHSA-2026:3848 | 05.03.2026 |
| Red Hat Enterprise Linux 8.2 Advanced Update Support | kernel | Fixed | RHSA-2026:1512 | 28.01.2026 |
Показывать по
Дополнительная информация
Статус:
EPSS
7 High
CVSS3
Связанные уязвимости
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 logi...
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 si
vsock: Ignore signal/timeout on connect() if already established
In the Linux kernel, the following vulnerability has been resolved: v ...
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...
EPSS
7 High
CVSS3