CVE-2026-74580: a nine-year-old flaw in Linux's vhost subsystem lets a local user read and write kernel memory at will and escalate to root — and in one virtualization configuration an untrusted guest can write into the host's QEMU process.
What Vghost (CVE-2026-74580) enables
The vulnerability, named Vghost and tracked as CVE-2026-74580, gives an unprivileged local user a reliable, deterministic primitive to read and write arbitrary kernel addresses and escalate to root across a broad range of kernels. Tencent Zhuque Lab, which discovered the bug, released a fix on August 3 and published a full technical write-up with working demos on October 12. There is no public sign the bug has been exploited in the wild.
Separately, in configurations where a virtual machine's virtio device sits behind a virtual IOMMU with iommu_platform enabled and vhost runs in device-IOTLB mode, an untrusted guest can trigger the same flaw and cause the host kernel to write out of bounds into the host's QEMU process. From that point a guest can overwrite a QEMU function pointer to redirect execution or crash the process.
How vhost's cache and vring commands create the out‑of‑bounds writes
vhost maintains a small cache of the memory mappings used for each virtio ring and its shared queues. A cache hit is treated as proof that an earlier mapping check has already validated the region. The cache is cleared when mappings are updated, invalidated, or the queue is reset — but not when the VHOST_SET_VRING_ADDR or VHOST_SET_VRING_NUM commands change the ring's address or size while the queue remains live.
With a device IOTLB attached, those vring commands accept the new addresses without performing the check at that moment, postponing validation to a later step. If the cache becomes filled, the later validation is skipped and vhost continues translating addresses using the stale mapping. The kernel then copies data to or from a pointer derived from the stale translation without a bounds check, producing out-of-bounds reads or writes that enable kernel memory access.
Tencent's write-up notes the exploit is deterministic — it requires neither memory grooming nor lucky timing — and that two historical changes produced the bug: a 2017 change (Linux 4.11) added the cache shortcut, and a 2020 change (Linux 5.9) moved address checking to a later step.
Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlogWhich kernels and distributions were tested
The flaw affects Linux kernels from 4.11 up to 7.2-rc4. Tencent reproduced a full local-user-to-root chain on five distribution kernels: Ubuntu 26.04, Red Hat Enterprise Linux (RHEL) 9.8, Amazon Linux 2023, Microsoft Azure Linux 3.0, and Oracle Linux 10.2.
Device nodes providing access are usually /dev/vhost-net or /dev/vhost-vsock. On the tested Ubuntu image the node was limited to the kvm group, so an exploit's starting point would require membership in that group rather than any local user account. On the other four tested images the device node was world-readable (mode 0666), allowing any local user to reach it.
Fixes, vendor responses, and immediate mitigation steps
The upstream fix (commit de845981da67) clears the vhost cache whenever a ring is reconfigured. The simple operational remedy: install a kernel that contains that commit and reboot. Vendors may also backport the fix without changing the kernel version number.
Several vendors have shipped fixes: Red Hat, Amazon Linux, and Oracle Linux. Ubuntu has fixed 22.04 and, as of October 13, lists kernels for 24.04 and 26.04 as "in progress." The advisory from Tencent emphasizes there is no interim workaround to prevent the guest‑to‑host escape; the patched kernel is the only remedy for that path.
Until patched kernels are in place, administrators should restrict access to vhost device nodes: 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 privileged capability while running the vulnerable kernel.
How virtualization operators, distribution vendors, and security teams should respond
- Virtualization operators: Prioritize applying kernels that include the de845981da67 commit and reboot affected hosts. Where immediate patching is not possible, remove world-readable permissions on /dev/vhost-* and restrict the device to a minimal, trusted group.
- Distribution vendors and maintainers: Continue shipping or backporting the upstream fix and clearly flag whether fixes are backported without a version-number change. Communicate status for specific supported releases so operators can plan remediation.
- Security teams and incident responders: Treat local access to vhost device nodes as an elevation risk; scan images and host configurations for world-readable vhost nodes and for virtual IOMMU/device-IOTLB combinations that would enable guest-to-host memory writes. Note that the guest-to-host path has no interim workaround beyond patching the kernel.
Tencent attributes the discovery to machine-assisted research: Corvus AI, a multi‑agent system built for kernel vulnerability research, and the upstream patch credits Corvus with an "Assisted-by" line. Tencent says the pipeline found the flaw; it is not presented as an AI attack but as machine-assisted research. The same pipeline previously surfaced an 18‑year‑old SCTP kernel flaw disclosed in August that also produced root in testing and, in that testing, escaped a container.
Vghost is a reminder that long-lived subsystem changes can interact in unforeseen ways. Operators should assume that until a kernel carrying commit de845981da67 is installed and hosts rebooted, local access — and in certain virtualization setups, guest access — remains a real risk.
https://thehackernews.com/2026/10/ai-found-linux-kernel-flaw-gives-local.html
