PT-2026-128206

CVE-2026-99213

·

Published

2026-10-28

·

Updated

2026-10-28

Description by

Score
N/A
Not available

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.

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.
Vendors
Affected products
Related identifiers
Found an issue in the description? Have something to add? Feel free to write us 👾