Cloudanix VulnDB

CVE-2026-99213

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in the Linux kernel's handling of certain network socket connections can let local programs crash the entire system.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in vsock connect handling allows a socket still present in connected_table to be reset and re-inserted, producing a double list_add and subsequent kernel memory corruption.

Why it matters to the business

Local processes can trigger kernel crashes or memory corruption on affected Linux systems, leading to denial of service and potential system instability in environments relying on vsock or virtio transport.

How an attack unfolds

An attacker with local access triggers rapid vsock connect and reset operations that race with the connect loop and TCP_CLOSING state transition, causing the kernel to attempt re-insertion of an already-connected socket and corrupt internal lists.

How to fix it

Update to a Linux kernel containing the referenced fix for vsock connect handling and the supplementary commit that ignores signals/timeouts once a connection is established.

How to confirm the fix worked

Confirm the kernel version includes the vsock TCP_CLOSING and signal-pending handling changes; attempt to reproduce the list_add double-add condition with vsock loopback workloads and verify the BUG no longer occurs.

Typical attack path

  1. Obtain local code execution on a Linux host using vsock
  2. Repeatedly exercise vsock connect while inducing OP_RST transitions
  3. Trigger the race between TCP_ESTABLISHED to TCP_CLOSING handling and connected_table insertion
  4. Cause double list_add and kernel panic or corruption

How to detect it

Search kernel logs for list_debug BUGs, vsock_insert_connected, virtio_transport_recv_pkt, and vsock_loopback_work stack traces; inspect for repeated vsock connect/reset patterns preceding crashes.

  • list_add double add
  • __list_add_valid_or_report
  • vsock_insert_connected
  • virtio_transport_recv_pkt
  • vsock_loopback_work

What your security team should do

  • Prioritize kernel upgrades on any system exposing vsock or virtio-vsock interfaces
  • Monitor for vsock-related kernel oops or list corruption events in production workloads
  • Restrict untrusted local code execution until patches are applied

The record

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.

Affected packages

Ecosystem Package Introduced Fixed