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
