VulnerabilityPublished 28 Oct 2026

CVE-2026-99213: Linux kernel · vsock: treat TCP_CLOSING as once-established

Affects Linux kernelSource CVE Database V5

Not known to be exploited · fixed in c2c5359ef2c33684fa3f3652fd761a483db8d1e7 : update Linux kernel when convenient.

Data as of 28 Oct 2026, 10:58 UTC

Severity

Unrated

Rated by Threat Radar · CVSS not yet scored by NVD

Patch: Available – fixed in c2c5359ef2c33684fa3f3652fd761a483db8d1e7, 44d1ca05d6094a5d75c671a0545249186d790b8d, 4f6ac74fa594a918d41255c941256e1d51592d3b

Exploitation evidence

Disclosed: evidence found.
CVE published 28 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade Linux kernel to c2c5359ef2c33684fa3f3652fd761a483db8d1e7, 44d1ca05d6094a5d75c671a0545249186d790b8d or 4f6ac74fa594a918d41255c941256e1d51592d3b.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ d021c344051af91f42c5ba9fdedc176740cbd238, < c2c5359ef2c33684fa3f3652fd761a483db8d1e7	Fixed in c2c5359ef2c33684fa3f3652fd761a483db8d1e7
LinuxLinux	Affected ≥ d021c344051af91f42c5ba9fdedc176740cbd238, < 44d1ca05d6094a5d75c671a0545249186d790b8d	Fixed in 44d1ca05d6094a5d75c671a0545249186d790b8d
LinuxLinux	Affected ≥ d021c344051af91f42c5ba9fdedc176740cbd238, < 4f6ac74fa594a918d41255c941256e1d51592d3b	Fixed in 4f6ac74fa594a918d41255c941256e1d51592d3b
LinuxLinux	Affected =3.9	Fixed in–

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

Community reviews

Loading reviews…