Vghost: a nine-year-old Linux kernel bug hands local users root — and can let a VM reach into its host

A newly disclosed flaw in the Linux kernel's vhost subsystem, tracked as CVE-2026-74580 and nicknamed Vghost, lets an unprivileged local user read and write arbitrary kernel memory and climb to root. In a narrower virtualization setup, the same bug lets an untrusted guest VM corrupt memory inside the host's QEMU process. The upstream fix has been available since early August; the full technical write-up, with working demonstrations, landed on October 12. There is no public evidence of exploitation in the wild so far.

What happened

vhost is the in-kernel fast path that virtual machines and containers use for networking and other I/O. Userspace reaches it through device nodes — typically /dev/vhost-net and /dev/vhost-vsock.

To save work, vhost caches the memory mapping behind each virtual ring and treats a cache hit as proof that the region was already validated. The cache is flushed on mapping updates, invalidations and queue resets — but not when the VHOST_SET_VRING_ADDR or VHOST_SET_VRING_NUM commands change a live ring's address or size. With a device IOTLB attached, those commands defer their address check; once the cache is warm, that deferred check never runs. The kernel keeps translating with the stale mapping and copies data without a bounds check, giving the attacker out-of-bounds kernel read/write.

Two separately reasonable changes created the hole: a 2017 optimization (Linux 4.11) introduced the cache, and a 2020 refactor (Linux 5.9) moved address validation out of the command path. Together they left the bug in place for roughly nine years.

The researchers, Tencent Zhuque Lab, demonstrated two outcomes:

• Local privilege escalation (host): a deterministic chain — no heap grooming, no race — to arbitrary kernel read/write, KASLR bypass and root.
• Guest-to-host impact: when a virtio device sits behind a virtual IOMMU with iommu_platform enabled and vhost runs in device-IOTLB mode, a malicious guest can make the host kernel write out of bounds into the host's QEMU process, overwrite a function pointer and redirect or crash it.

The bug was surfaced with help from Corvus AI, the lab's multi-agent kernel research system — the upstream patch carries an Assisted-by credit. This is AI-assisted defensive research, not an AI-driven attack.

Why it matters

• Wide version range. Affected kernels span 4.11 through 7.2-rc4, i.e. almost every supported enterprise kernel.
• Confirmed on major distributions. The full local-to-root chain was reproduced on Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Microsoft Azure Linux 3.0 and Oracle Linux 10.2. On four of those images the vhost node was world-accessible (mode 0666); on Ubuntu it was limited to the kvm group.
• Severity: high, not critical — and scorers disagree. kernel.org rates it 8.8 with a changed scope because of the guest-to-host path; Red Hat (7.3) and Oracle (7.3) treat the scope as unchanged; Amazon lands at 7.8. We would treat it as high priority on any multi-tenant or virtualization host and on shared Linux systems where untrusted users have a shell.

What to do

1. Patch and reboot. Install a kernel that includes upstream commit de845981da67. First fixed stable releases:

   Stable branch	First fixed
   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

   Distributions often backport without bumping the version — check your vendor advisory, not just uname -r. Red Hat, Amazon Linux and Oracle Linux have shipped fixes; Ubuntu has fixed 22.04, with 24.04 and 26.04 still listed as in progress as of October 13.

2. Lock down the device nodes until you can reboot. Remove world access from /dev/vhost-net and /dev/vhost-vsock (and make it persist via udev rules), restrict the owning group to trusted virtualization services, and treat membership of that group (e.g. kvm) as a privileged role.

3. Prioritize hypervisors. There is no interim workaround for the guest-to-host path — the patched kernel is the only fix. Hosts running untrusted guests with a vIOMMU/iommu_platform configuration should go first.

4. Inventory and verify. Find Linux hosts, CI runners, container nodes and cloud images in the affected range, confirm which have reachable vhost nodes, and track them to closure.

Source: The Hacker News — thehackernews.com. Original research: Tencent Zhuque Lab.