CVE-2026-99213

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: treat TCP_CLOSING as once-established<br /> <br /> Handle the TCP_ESTABLISHED -&gt; TCP_CLOSING transition on OP_RST, which can<br /> race with the connect loop. Immediately break and return 0 on<br /> ESTABLISHED/CLOSING. The return value of connect() should reflect what<br /> happened up to the point the connection was established or failed. Events<br /> that occur afterwards must not affect it. E.g. even if OP_RW has already<br /> set sk_err, connect() should still return 0, not ENOBUFS because of it.<br /> Adapt the inaccurate comment above signal_pending().<br /> <br /> Resetting a socket that is still present in connected_table can lead to<br /> memory corruption. The reporter noted lost transports for in-flight skbs,<br /> and I have reproduced crashes caused by re-insertion into connected_table.<br /> <br /> list_add double add: new=, prev=, next=.<br /> kernel BUG at lib/list_debug.c:35!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> Workqueue: vsock-loopback vsock_loopback_work<br /> RIP: 0010:__list_add_valid_or_report+0x11f/0x130<br /> Call Trace:<br /> vsock_insert_connected.cold+0xe/0x13<br /> virtio_transport_recv_pkt+0x10e9/0x1460<br /> vsock_loopback_work+0x305/0x480<br /> process_one_work+0xe4c/0x1560<br /> worker_thread+0x4f1/0xd60<br /> kthread+0x36e/0x470<br /> ret_from_fork+0x47b/0x6b0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> This fix is supplementary to commit 002541ef650b ("vsock: Ignore<br /> signal/timeout on connect() if already established"). Details under Link.