Vghost: A Nine-Year-Old Linux vhost Bug Gives Local Users Root and Lets Guests Hit the Host

If you run Linux hosts that do virtualization, or shared machines where users can reach vhost device nodes, this one deserves your attention this week. A bug in the kernel’s vhost subsystem gives a local user full kernel read and write, and in one configuration it lets an untrusted guest VM reach out of its sandbox.

Here is what The Hacker News reported, followed by my own take.

What was reported

The flaw is tracked as CVE-2026-74580 and named Vghost. Tencent Zhuque Lab found it, released a fix on August 3, and published a full write-up on October 12 with working demos of both attacks. There is no public sign of exploitation yet.

vhost is the kernel component that speeds up network and other I/O for virtual machines and containers. A local user reaches it by opening a device node, usually /dev/vhost-net or /dev/vhost-vsock.

There are two attack paths:

• Local privilege escalation on the host. An unprivileged user gets a reliable way to read and write any kernel address, bypass KASLR, and become root. The article says the attack is deterministic: no memory grooming and no lucky timing.
• Guest-to-host escape. This is narrower. It applies when a VM’s virtio device sits behind a virtual IOMMU with iommu_platform on, and vhost runs in device-IOTLB mode. An untrusted guest can then trigger the same bug and make the host kernel write out of bounds into the host’s QEMU process. The guest can overwrite a function pointer in QEMU and control where the host process runs next, or just crash it.

How the bug works

vhost keeps a small cache of the memory mappings behind each virtual ring. A cache hit is treated as proof that the region was already validated. The cache gets cleared on mapping updates, invalidations, and queue resets. It does not get cleared when VHOST_SET_VRING_ADDR or VHOST_SET_VRING_NUM change the ring’s addresses or size while the queue is live.

With a device IOTLB attached, those commands accept new addresses without checking them and leave validation for later. Once the cache is filled, that later check never runs. vhost keeps translating the new addresses with the old mapping, and the kernel copies data to or from the resulting pointer with no bounds check. A write to the used ring, or a read of a descriptor, lands outside the mapped region. That is the read/write primitive.

The bug survived about nine years because it took two reasonable changes to create it. A 2017 change (Linux 4.11) added the cache and its shortcut. A 2020 change (Linux 5.9) moved address checking out of the command and into a later step, which removed the check that would have caught the stale translation.

Who is affected

Kernels from 4.11 up to 7.2-rc4 are affected. Tencent reproduced the full local-user-to-root chain on five distribution kernels: Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Microsoft Azure Linux 3.0, and Oracle Linux 10.2.

Access to the device node matters a lot here. On Ubuntu it was limited to the kvm group, so the starting point was a member of that group. On the other four images the node was world-readable at mode 0666, so any local user could reach it.

The fix and vendor status

The fix, commit de845981da67, clears the cache whenever the ring is reconfigured. The first fixed upstream stable releases:

Stable branch	First fixed version
5.10.y	5.10.265
5.15.y	5.15.216
6.1.y	6.1.183
6.6.y	6.6.152
6.12.y	6.12.104
6.18.y	6.18.45
7.1.y	7.1.9
7.2	7.2

Vendors may backport the fix without changing the version number, so a version string alone won’t always tell you the truth. Red Hat, Amazon Linux, and Oracle Linux have shipped fixes. Ubuntu has fixed 22.04 and, as of October 13, still lists its 24.04 and 26.04 kernels as in progress.

Severity and the AI angle

The flaw is rated high, not critical, and the raters disagree. The kernel.org CVE team gives it 8.8 with changed scope, since the guest-to-host write crosses a trust boundary. Red Hat scores it 7.3 with unchanged scope and a lower integrity impact. Amazon scored it 7.8 and Oracle 7.3.

The bug was found with help from Corvus AI, a multi-agent system Tencent built for kernel vulnerability research. The upstream fix carries an Assisted-by line. The article frames this as machine-assisted research, not an AI-run attack, and notes the same team and pipeline was behind an 18-year-old SCTP kernel flaw disclosed in August.

My take

Everything below is my opinion, not the article’s.

The score disagreement is a distraction. Whether it’s 7.3 or 8.8 depends on whether you think the host’s QEMU process is a separate trust boundary. If you run multi-tenant virtualization, it obviously is. If you run a single-owner box, you care mostly about the local root path. Pick the reading that matches your environment and move on.

The device-node permissions are the real story for triage. A reliable, deterministic root exploit is bad everywhere, but it is much worse where /dev/vhost-net is mode 0666. Four of the five tested distributions shipped that way. Any shell on those machines, whether from a stolen low-privilege account, a compromised web app, or a CI runner, becomes a root shell. I’d rank hosts by who can get a local shell, not by whether they run VMs at the moment.

The bug’s history is also a reminder that individually sensible refactors can cancel each other out. A cache added in one release and a validation move in another were each fine in review. Nobody was looking at their interaction for nine years. That is the kind of gap automated research tools seem well suited to find, and I expect more disclosures like this one, with defenders getting shorter windows between write-up and working demo.

Practical takeaways

1. Inventory first. Find hosts running kernels in the 4.11 to 7.2-rc4 range that have /dev/vhost-net or /dev/vhost-vsock, including container hosts and CI runners.
2. Patch and reboot. Install a kernel containing commit de845981da67. Check your vendor’s advisory, since backports keep the old version number.
3. Lock down the nodes now if you can’t patch. Remove world access to both device nodes, limit the owning group to trusted virtualization services, and treat membership in that group as a privilege.
4. Know the limits of that workaround. The article says there is no interim workaround for the guest-to-host escape. If you run untrusted guests behind a virtual IOMMU with iommu_platform on, the patched kernel is the only remedy, so put those hosts first.
5. Watch Ubuntu 24.04 and 26.04. As of October 13 those kernels were still listed as in progress. Apply the group restriction and check back for updates.
6. Plan for faster cycles. With a public write-up and demos out, assume exploit code will spread. Shorten your kernel patch window for virtualization hosts.

Sources

• AI-Found Linux Kernel Flaw Gives Local Users Root, and Can Break a Guest Out to the Host — The Hacker News, 2026-10-14