Linux Vghost CVE-2026-74580 can root a host or hit QEMU
Stale vhost IOTLB cache, local privilege escalation, limited VM escape path

Linux Vghost CVE-2026-74580 can root a host or hit QEMU

Tencent Zhuque Lab disclosed Vghost on 12 October, and the oss-security note landed on 14 October. CVE-2026-74580 is a stale IOTLB metadata cache in Linux vhost frontends. A local user who can open /dev/vhost-net or /dev/vhost-vsock can get arbitrary kernel read and write, then root. There is no public sign of in-the-wild exploitation.

What happened

vhost caches address mappings for virtqueue rings. Changing the ring address or size does not always clear that cache. A later cache hit translates the new address through the old mapping and skips the range check. The researchers showed a local chain that leaks kernel data, including KASLR material, and overwrites sensitive kernel state such as modprobe_path. They reproduced local-to-root on Ubuntu 26.04 (7.0.0-28-generic), RHEL 9.8, and Amazon Linux 2023, among others. On several of those test images, /dev/vhost-vsock was mode 0666.

A second path needs a guest with a virtual IOMMU, iommu_platform, and VIRTIO_F_RING_RESET. In that setup the same stale cache can overwrite QEMU heap memory and hijack the process that runs the virtual machine. That is a VM escape only for hosts that expose those features. It is not a universal breakout from every guest.

The upstream fix resets the vring metadata cache in vhost_vring_set_num_addr(). First fixed upstream stable versions called out 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. Vendor kernels may backport the fix onto an older version string, so the package changelog matters more than the major number.

Who is affected

Hypervisors, container hosts, and developer workstations that expose /dev/vhost-* to untrusted local users. Multi-tenant KVM hosts and CI runners where a low-privilege account can open vhost-vsock are the priority. Guests alone are not enough for the QEMU path unless vIOMMU and the listed virtio features are on.

What to do now

Install the vendor kernel that includes the vhost IOTLB cache reset, and until then treat /dev/vhost-* as a privileged device. Remove world-writable permissions. Keep the kvm group limited to accounts that must run virtual machines. If you do not need vhost acceleration for untrusted guests, do not pass those devices through. On hosts where VM isolation matters, disable the vIOMMU plus iommu_platform plus ring-reset combination until the kernel is patched.

  • Check mode and group on /dev/vhost-net and /dev/vhost-vsock. 0666 is an incident waiting, not a default to keep.
  • Match your running kernel against the vendor advisory, not only against 5.10.265 or 7.2.
  • Separate CI tenants from production hypervisors if both can open vhost devices.
  • No KEV listing and no confirmed exploitation yet. Patch on the next kernel window, but do not leave device nodes world-accessible while you wait.

Source: oss-security disclosure by the Tencent Zhuque Lab researchers. CVE-2026-74580: Linux vhost stale IOTLB cache leading to LPE and VM escape.

Also on the blog

Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.

n0n lists 38 ports and shipping firms, deadline 19 October
Unverified data-theft extortion claim, demands from 2.4 to 14 million dollars