Vghost hands root to any local user on four of the five Linux kernels Tencent tested
Tencent Zhuque Lab published working demos on October 12 for Vghost (CVE-2026-74580), a vhost bug that gives local users root on Linux 4.11 through 7.2-rc4. The August 3 fix is out, but Ubuntu 24.04 and 26.04 kernels were still listed as in progress on October 13.
The Watch · Security desk
Comparison of severity scores for the vhost flaw: kernel.org CVE team 8.8 with scope changed, Red Hat 7.3 with scope unchanged, Amazon 7.8, Oracle 7.3.
Severity score each scorer gave the vhost flaw In score
| Item | Value | Claim |
|---|---|---|
| kernel.org, scope changed | 8.8 score | 17 |
| Red Hat, scope unchanged | 7.3 score | 18 |
| Amazon | 7.8 score | 18 |
| Oracle | 7.3 score | 18 |
What happened
- vhost caches ring mappings and treats a hit as proof of a prior check, but changes to ring addresses or size on a live queue do not clear that cache.
- Two changes created the bug: a 2017 change in Linux 4.11 added the cache, and a 2020 change in Linux 5.9 moved address checking to a later step.
- The guest-to-host attack needs a virtio device behind a virtual IOMMU with iommu_platform on and vhost in device-IOTLB mode, then overwrites a function pointer in QEMU.
- Tencent reproduced the full local-user-to-root chain on Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Azure Linux 3.0 and Oracle Linux 10.2.
- The Hacker News reports no public sign of exploitation so far.
Why it matters
- exposure On four of the five tested images the device node is mode 0666, so every local account is a starting point for root. On Ubuntu only kvm group members are.
- constraint Hosts running untrusted guests behind a virtual IOMMU have no interim workaround for the guest-to-host path. Only a patched kernel and a reboot close it.
- decision Hosts still waiting on a vendor kernel can remove world access to the vhost nodes and limit the owning group to trusted virtualization services today.
- contradiction kernel.org scores it 8.8 with scope changed and Red Hat 7.3 with scope unchanged, a split over whether the guest-to-host write crosses a trust boundary.
The gating question on the local path is who can open the device node. The attack is deterministic, with no memory grooming and no timing window [6], so a user who can open /dev/vhost-net or /dev/vhost-vsock [5] does not need luck or retries. A permissions check on those two nodes is the fastest way to size exposure on a host.
The fix preceded the write-up and demos by 70 days [c2, d1]. Hosts that installed the fix when it came out are covered. Hosts that were waiting for proof the bug is real now have working demos of both attacks [2].
Patch verification is where fleets will slip. Red Hat, Amazon Linux and Oracle Linux have shipped fixes [14]. The fix is commit de845981da67, and vendors may backport it without changing the version number [13]. A version string alone does not show whether a host is fixed. A host is fixed once a kernel containing the commit is installed and booted [13].
vhost serves containers as well as virtual machines [4]. The demos cover a local user on the host and a guest behind a virtual IOMMU, and The Hacker News describes no container escape [2]. A container workload matters here only if it can open the node. The article does not say how containers reach it.
On severity, we think hosts that run untrusted guests behind a virtual IOMMU should use the kernel.org rating. The write lands in the host's QEMU process [7]. That is the boundary crossing the kernel.org team cites for its scope-changed score [17]. Red Hat's lower, scope-unchanged rating [18] fits a host where only the local path applies.
What to watch
- Ubuntu 24.04 and 26.04 kernel fixes, listed as in progress as of October 13.
- Any report of exploitation in the wild now that working demos of both attacks are public.
- Whether Microsoft ships a fix for Azure Linux 3.0, which the report does not list among the vendors with fixes.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence70
- Adoption
- Insufficient
- Hype gap−10
- Incentives
- Insufficient
- Confidence65
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
A flaw in Linux's vhost subsystem lets a local user read and write kernel memory at will and become root across nearly a decade of kernel versions.
- [2]
The bug is tracked as CVE-2026-74580 and named Vghost. Tencent Zhuque Lab, which found the flaw, released a fix on August 3 and published a full write-up on October 12 with working demos of both attacks.
- [3]
There is no public sign the flaw has been exploited yet.
- [4]
vhost is the part of the Linux kernel that speeds up network and other input/output for virtual machines and containers.
- [5]
A local user reaches vhost by opening a device node, usually /dev/vhost-net or /dev/vhost-vsock.
- [6]
On the host, the flaw gives an unprivileged user a reliable way to read and write any kernel address, bypass KASLR, and escalate to root. The attack is deterministic and needs no memory grooming and no lucky timing.
- [7]
When a virtual machine's virtio device is behind a virtual IOMMU with iommu_platform turned on, and vhost runs in device-IOTLB mode, an untrusted guest can make the host kernel write out of bounds into the host's QEMU process, overwrite a function pointer in QEMU, take control of where the host process runs next, or crash it.
- [8]
vhost caches the memory mappings behind each virtual ring and treats a cache hit as proof the region was already checked. The cache is cleared on mapping update or invalidation and on queue reset, but not when VHOST_SET_VRING_ADDR or VHOST_SET_VRING_NUM change the ring's addresses or size while the queue is live.
- [9]
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, removing the check that would have caught the stale translation.
- [10]
The flaw affects Linux kernels from 4.11 up to 7.2-rc4.
- [11]
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.
- [12]
On Ubuntu, the device node was limited to the kvm group, so the starting point was a member of that group. On the other four tested images, the node was world-readable at mode 0666, so any local user could reach it.
- [13]
The fix (commit de845981da67) clears the cache whenever the ring is reconfigured. Operators should install a kernel that contains it and reboot; vendors may backport the fix without changing their version number.
- [14]
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.
- [15]
Until a fixed kernel is in place, operators should remove world access to /dev/vhost-net and /dev/vhost-vsock, limit the owning group to trusted virtualization services, and treat membership in that group as a privilege. There is no interim workaround for the guest-to-host escape; the patched kernel is the only remedy.
- [16]
The fix preceded the write-up and demos by 70 days.
- [17]
The flaw is rated high, not critical. The kernel.org CVE team scores it 8.8 and marks its scope as changed, because the guest-to-host write reaches memory in the host's QEMU process and crosses the boundary between a guest and its host.
- [18]
Red Hat scores the flaw 7.3 with scope unchanged, treating the impact as remaining within the host's own trust boundary, and rates the integrity impact lower. Amazon scored it 7.8 and Oracle 7.3.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- thehackernews.comAI-Found Linux Kernel Flaw Gives Local Users Root, and Can Break a Guest Out to the Host
1 article · October 14, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.