UBUNTU-CVE-2026-99122: Medium severity vulnerability
In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: validate packet source for connected sockets vmcitransportrecvstreamcb() looks up sockets first by the full source and destination tuple, then by destination only in the bound table. The fallback can select a non-listening socket without checking whether the packet came from its stored peer. This was reproduced with two VMCI contexts. A RST from the context not stored in a TCPSYNSENT socket reset that socket after it was selected by the destination-only lookup. VMCI can process notification packets in bottom-half context when the socket is not owned by user context, or defer packets to a workqueue. Use vsockchecksource() after taking the socket lock in the bottom-half path, and recheck after locksock() in the workqueue path. Listening sockets continue to accept packets from any source. Reply with a RST addressed from the received packet before dropping a source that fails validation. This preserves the existing reset behavior for bound non-listening and concurrently closed sockets without directing the reset to a connected socket's stored peer.
Event History
Frequently Asked Questions
What access or setup is needed to trigger the issue?
The reported reproduction used two VMCI contexts. A RST sent from a context other than the peer stored by a TCP_SYN_SENT socket could be selected through the destination-only bound-socket lookup and reset that socket.
Are listening sockets affected by the new source validation?
Listening sockets continue to accept packets from any source. The validation is applied to connected sockets after the socket lock is acquired, including packets handled in bottom-half context or deferred to a workqueue.