
Linux vhost Flaw CVE-2026-74580 Allows Local Root and Guest Escape
A nine-year-old Linux kernel flaw in the vhost subsystem, CVE-2026-74580 (Vghost), lets local users gain root and allows VMs to escape to the host. Tencent Zhuque Lab found it with AI assistance and released a fix in August.
Background and Impact
A vulnerability in the Linux kernel's vhost subsystem, tracked as CVE-2026-74580 and named Vghost, has been disclosed by Tencent Zhuque Lab. The flaw affects kernel versions from 4.11 through 7.2-rc4, a span of roughly nine years. It allows an unprivileged local user to read and write arbitrary kernel memory, bypass kernel address space layout randomization, and escalate privileges to root. In a virtualization scenario where a virtio device is placed behind a virtual IOMMU with iommu_platform enabled and vhost runs in device-IOTLB mode, an untrusted guest can trigger the same bug to write out of bounds into the host's QEMU process, potentially achieving code execution on the host.
The bug was found with assistance from Corvus AI, a multi-agent system developed by Tencent for kernel vulnerability research. The upstream fix credits the AI system with an Assisted-by line. Tencent released the fix on August 3 and published a full write-up with working demonstrations on October 12. There is no public indication that the vulnerability has been exploited in the wild.
Technical Details
The vhost subsystem accelerates network and other input/output for virtual machines and containers. A local user accesses it through device nodes such as /dev/vhost-net or /dev/vhost-vsock. The subsystem maintains a cache of memory mappings for each virtual ring and shared queue. A cache hit is treated as proof that the region has already been validated. The cache is cleared when mappings are updated or invalidated and when the queue is reset, but not when the VHOST_SET_VRING_ADDR or VHOST_SET_VRING_NUM commands change the ring's addresses or size while the queue is live.
When a device IOTLB is attached, those commands accept the new addresses without immediate validation, deferring the check to a later step. Once the cache is populated, the subsequent validation never runs, and vhost continues to translate new addresses using the stale mapping. The kernel then copies data to or from the resulting pointer without a bounds check, allowing a write to the used ring or a read of a descriptor to land outside the mapped region. This provides the attacker with kernel read and write primitives. The flaw originated from two separate changes: a 2017 change in Linux 4.11 that introduced the cache and its shortcut, and a 2020 change in Linux 5.9 that moved address checking out of the command path, removing the check that would have caught the stale translation.
Mitigation and Severity
The fix, commit de845981da67, clears the cache whenever the ring is reconfigured. Users should install a kernel that includes this fix and reboot. The first fixed upstream stable releases are 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9, and 7.2. Red Hat, Amazon Linux, and Oracle Linux have already shipped updated kernels. Ubuntu has fixed the 22.04 release and, as of October 13, lists its 24.04 and 26.04 kernels as still in progress.
Until a patched kernel is deployed, administrators should restrict access to the vhost device nodes by removing world read and write permissions on /dev/vhost-net and /dev/vhost-vsock, limiting the owning group to trusted virtualization services, and treating membership in that group as a privileged operation. There is no interim workaround for the guest-to-host escape path; a patched kernel is the only remedy. Severity ratings vary: the kernel.org CVE team scores the flaw at 8.8 with changed scope because the guest-to-host write crosses the guest-host boundary, while Red Hat scores it at 7.3 with unchanged scope and lower integrity impact. Amazon rates it 7.8 and Oracle 7.3.
Sources: The Hacker News
SiTech — AI-powered web development
We build fast, modern websites and bring AI into real business workflows. Have a project or a question? We'd love to help.