Live › vulnerability › CVE-2026-99213
Go to dashboardIn the Linux kernel's vsock code, a reset arriving during connect can remove a socket that is still in the connected table, and a later re-insert can crash the kernel. The sources do not say what an attacker can do beyond the kernel crash and memory corruption.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 11:32 UTC. All times on this page are UTC.
Systems running a Linux kernel with vsock support (virtio-vsock or vsock loopback) that use it for connections between host and guests. Hosts without vsock loaded are unlikely to be exposed; the sources do not say which distributions or kernel ranges are affected.
No product ranges from the sources yet.
uname -r and compare against the kernel release that contains the fix, which the sources do not namelsmod | grep vsock to see whether vsock modules are loaded at allEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
vsock: treat TCP_CLOSING as once-established
Handle the TCP_ESTABLISHED -> TCP_CLOSING transition on OP_RST, which can race with the connect loop. Immediately break and return 0 on ESTABLISHED/CLOSING. The return value of connect() should reflect what happened up to the point the connection was established or failed. Events that occur afterwards must not affect it. E.g. even if OP_RW has already set sk_err, connect() should still return 0, not ENOBUFS because of it. Adapt the inaccurate comment above signal_pending().
Resetting a socket that is still present in connected_table can lead to memory corruption. The reporter noted lost transports for in-flight skbs, and I have reproduced crashes caused by re-insertion into connected_table.
list_add double add: new=, prev=, next=. kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:__list_add_valid_or_report+0x11f/0x130 Call Trace: vsock_insert_connected.cold+0xe/0x13 virtio_transport_recv_pkt+0x10e9/0x1460 vsock_loopback_work+0x305/0x480 process_one_work+0xe4c/0x1560 worker_thread+0x4f1/0xd60 kthread+0x36e/0x470 ret_from_fork+0x47b/0x6b0 ret_from_fork_asm+0x1a/0x30
This fix is supplementary to commit 002541ef650b ("vsock: Ignore signal/timeout on connect() if already established"). Details under Link.
This page as .md · .json · in your agent: get_signal("CVE-2026-99213")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.