Linux Vhost PoC Shows Root Escalation, Conditional VM Escape
Tencent Zhuque Lab published its technical analysis of CVE-2026-74580, named Vghost, on October 12, 2026. The flaw affects upstream kernels from Linux 4.11 through 7.2-rc4. It carries a CVSS v3.1 score of 8.8, with the vector AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. The Tencent Zhuque Lab analysis describes a path from local access to root privileges, plus a separate risk to VM hosts that depends on their configuration.
The host-side risk is conditional, not universal.
Stale mappings can send writes to the wrong memory
Linux vhost accelerates virtual machine device traffic through shared virtqueues. The flaw appears when a ring is reconfigured: Linux updates its address or size but leaves cached IOTLB metadata behind. That metadata can be tied to the descriptor ring. The same problem affects the available-data and used-data rings. VHOST_SET_VRING_ADDR and VHOST_SET_VRING_NUM can replace a ring configuration without clearing the old cache entry. A later cache hit can bypass the expected address check and translate the new address through the stale mapping, passing an invalid pointer to kernel copy routines.
Researchers on the Seclists mailing list traced the issue to two earlier kernel changes. One added the metadata cache; the other deferred guest I/O address validation. To attempt local privilege escalation, an attacker must first be able to open a vhost device such as /dev/vhost-net or /dev/vhost-vsock. The PoC primes the cache, changes a ring address without clearing its cached entry, then triggers the queue to read and write kernel memory. The reported chain needs no race. It also requires neither heap grooming nor prior knowledge of kernel structure locations.
The demonstrated chain first uses a kernel memory read to determine the address randomization offset. It then writes to the kernel's modprobe_path setting. Triggering a kernel module request can run an attacker-controlled helper with root privileges. Researchers report arbitrary kernel read and write access, a KASLR bypass, and escalation to root. This is a local attack that requires vhost device access, not a remote-only vulnerability.
Exposure depends on device access and VM configuration
Researchers reproduced the local escalation chain on Ubuntu 26.04 and RHEL 9.8. They also tested Amazon Linux 2023 and Azure Linux 3.0. Oracle Linux 10.2 was another affected system. The tested Ubuntu installation restricted device access to the kvm group; the other listed systems exposed the device to ordinary users. That Ubuntu result applies specifically to version 26.04, distinct from the Ubuntu 26.10 beta discussed in separate beta coverage.
On unpatched systems, membership in a group that can access vhost devices should be treated as privileged. Checking device permissions helps identify exposure, but it does not replace installing the kernel fix. The Openwall oss-security advisory recommends restricting access to vhost device nodes. It also says to treat membership in a device-owning group such as kvm as privileged.
The guest-triggered path requires a vhost device behind a virtual IOMMU, with the iommu_platform setting enabled. Vhost must also run in device-IOTLB mode. The guest must use the VIRTIO_F_RING_RESET feature. It can then reset and re-enable a queue, prompting the host to reconfigure its ring while stale metadata remains cached. Triggering the queue can direct a used-ring write beyond guest memory and into the QEMU process heap. Researchers say the corruption can crash QEMU or affect its control flow. That is a conditional escape risk, not evidence that every VM can be escaped.
Patch the kernel and restrict vhost access
The upstream fix, commit de845981da67, clears the vring metadata cache when the ring address or size changes. The new configuration must then pass IOTLB validation. Fixed upstream stable releases listed for affected series are 5.10.265 and 5.15.216, followed by 6.1.183 and 6.6.152. The list continues with 6.12.104 and 6.18.45, then 7.1.9 and 7.2. Administrators should install a fixed kernel or vendor backport, then reboot into it. A running vulnerable kernel continues to use the old vhost logic.
Until patching, restrict access to /dev/vhost-net and /dev/vhost-vsock. Apply the same restriction to /dev/vhost-scsi and /dev/vhost-vdpa-*. Do not pass those devices to untrusted containers. On unpatched virtualization hosts, avoid exposing vhost devices with iommu_platform behind a virtual IOMMU to untrusted guests. Permission changes do not revoke file descriptors that are already open. They also do not address the guest-triggered path.
