GIVE YOUR AGENT THE EVIDENCE

Set up in your agent.

One prompt to get started. Paste it into your coding agent to connect cve.new through MCP and bring vulnerability context into your workflow.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

GIVE YOUR AGENT THE EVIDENCE

Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

cve.new
Check your stack
CVE-2026-99213unknown

vsock: treat TCP_CLOSING as once-established

Impact

In the Linux kernel, the following vulnerability has been resolved:

Source excerpt · Linux

Affected packages

This source has no supported package-version data for matching. You can read the advisory here, but this record alone cannot power a dependency check.

Affected products

Vendor version evidence. Product records are separate from automatic dependency matching.

Linux · Linux

Other versions: unaffected

Version / rangeSource status
d021c344051af91f42c5ba9fdedc176740cbd238 to before c2c5359ef2c33684fa3f3652fd761a483db8d1e7affected
d021c344051af91f42c5ba9fdedc176740cbd238 to before 44d1ca05d6094a5d75c671a0545249186d790b8daffected
d021c344051af91f42c5ba9fdedc176740cbd238 to before 4f6ac74fa594a918d41255c941256e1d51592d3baffected
Linux version evidence

Linux · Linux

Other versions: affected

Version / rangeSource status
3.9affected
0 to before 3.9unaffected
6.18.59 through 6.18.* (inclusive)unaffected
7.2.13 through 7.2.* (inclusive)unaffected
7.3 through * (inclusive)unaffected
Linux version evidence

Original source description

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.

References