Re: [PATCH net] vsock/virtio: validate packet source for connected sockets

[Daehyeon Ko <4ncienth@gmail.com>]

On Mon, Aug 17, 2026 at 10:56:38AM -0700, Bobby Eshleman wrote:
> Does this equality work for loopback, when the CID may be
> VMADDR_CID_LOCAL and/or VMADDR_CID_HOST on host or the guest CID in
> guest?

Not in all cases. I tested VMADDR_CID_HOST with no guest-to-host transport,
where it is routed over loopback but packets carry VMADDR_CID_LOCAL as their
source. The unpatched kernel transferred data in 3/3 runs, while v1 timed out
in 3/3 runs.

The v2 candidate requires the source port to match the socket's remote port
and accepts VMADDR_CID_LOCAL as the canonical source CID for loopback. It
preserved the CID_LOCAL, CID_HOST, and guest-CID loopback cases in my tests,
while the original cross-UID injection remained blocked. The selected VSOCK
selftests also passed with no KASAN report.

Stefano, to clarify the original description: the victim socket received the
exact 16 attacker-chosen bytes; the intended peer-side socket received none.
I will use your clearer description and keep the comment minimal in v2.

I also confirmed the analogous VMCI destination-only fallback. With two VMCI
contexts, an RST from a mismatched context reset another context's pending
connection in 3/3 runs. VMCI also has a notification fast path before the
workqueue handler, so I will address it separately with validation in both
paths. Hyper-V does not appear to share this packet lookup path.

I will post the virtio v2 as a separate thread.

Thanks,
Daehyeon