virtio-win Viosock EUVD-2026-83179

Requires the attacker to already have local low-privilege code execution inside a Windows guest running the virtio-win Viosock (vsock) driver from an affected build (mm210 up to but not including mm320), and that driver/device must be loaded and reachable by the process. Exploitation is performed by submitting an IOCTL_SELECT request carrying attacker-controlled VIRTIO_VSOCK_SELECT.Fdss[*].fd_count values whose 32-bit sum wraps. Limiting factors: no remote/network vector (AV:L), authentication/local foothold needed (PR:L), and the guest must actually use the vsock driver - many KVM Windows guests deploy the core virtio-win drivers without Viosock, narrowing real exposure. No user interaction required (UI:N).

The vendor-assigned CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 7.8 High) is internally consistent and I concur with it. This is a local privilege-escalation flaw: an integer-overflow bug (32-bit sum of three attacker-controlled fd_count fields wraps past the FD_SETSIZE bounds check) drives a heap overflow (CWE-122) in the NonPagedPool kernel heap of the Viosock driver, corrupting kernel memory. Attack vector is genuinely local (AV:L) - the attacker must already run code as a low-privilege process inside the Windows guest (PR:L) to submit the IOCTL_SELECT request, so this is not a remote or network-facing issue. AC:L is justified because the overflow condition is deterministically triggerable via crafted fd_count values; however, reliably converting NonPagedPool corruption into stable code execution is a non-trivial exploitation step, so C:H/I:H/A:H represents realistic-but-not-turnkey potential rather than guaranteed SYSTEM. On the exploitation-signal side there is no EPSS score, no CISA KEV listing, and no public POC provided in the input - so the practical status is: no public exploit identified at time of analysis. The fix is confirmed (commit c6bef93d, PR#1568, release mm320) and the root cause is clearly documented in the diff, which raises confidence in the technical validity but does not indicate active exploitation. Net: a real, credible local EoP that matters most in multi-tenant KVM environments where untrusted users share a guest, but it is a patch-in-normal-cycle priority rather than an emergency, absent any exploitation evidence.

A low-privilege user or sandboxed process inside a Windows KVM/QEMU guest that has the Viosock driver loaded opens the device and issues an IOCTL_SELECT request with VIRTIO_VSOCK_SELECT.Fdss[*].fd_count values crafted so their 32-bit sum wraps below FD_SETSIZE while an individual count is huge. VIOSockSelectCopyFds then iterates on the unchecked large count and writes past the pPkt->Fds allocation in NonPagedPool, corrupting kernel memory to escalate toward SYSTEM in the guest. No public POC is referenced in the provided data.