CVE-2026-74580 - Vghost: urgent for some, routine patching for most.

AnthonySmith · 2:20PM

https://security-tracker.debian.org/tracker/CVE-2026-74580

The simple tl;dr first:

There's a bug in the Linux kernel's virtualisation plumbing that lets someone who's already logged into a machine make themselves the admin (root), but only if they can access a few special virtualisation files.

Some systems let every user access those files, and those need patching now. Many others restrict them to admins only, and there the risk is much lower. The scary "VM escape" part only works on virtual machines set up with IOMMU (a virtual IOMMU) that most normal VMs don't use. If you're the only person who logs into your server, it's not world-accessible an your VMs are standard, just install the kernel update and reboot at your next convenient maintenance time. If other people or untrusted containers share your machine, patch and reboot as soon as you can.

Basically, Kubernetes and Docker and limited KVM-based situations are impacted; anyone still using OpenVZ might as well be sleeping with the windows and doors open and leaving the car keys and all their money in the garden.

Post done with AI for speed and accuracy:

What it is

A stale-cache bug in the kernel's vhost subsystem (present since about 4.11). Reconfiguring a virtqueue's ring addresses doesn't clear a cached memory mapping, so later accesses skip the bounds checks. The upstream fix is commit
de845981da67, and it has been backported to all maintained stable kernels (5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9, 7.2).

Attack 1: local user to root (the serious one)

The attacker needs to open a vhost device node (/dev/vhost-vsock, /dev/vhost-net and so on).
The public proof of concept used /dev/vhost-vsock.
On systems where these nodes are world-accessible (0666), any local user can reliably get root. Some distributions ship them that way.
Where they're 0660 root:kvm, only root and members of the kvm group can reach them, so kvm membership should be treated as root-equivalent.

Attack 2: guest VM into the host's QEMU process (narrow)

The guest needs a virtual IOMMU, with iommu_platform enabled on the vhost-backed device and ring reset support.
A guest can then overwrite memory in its own QEMU process on the host. It doesn't get kernel access directly, but it's a foothold.
Ordinary KVM guests without a virtual IOMMU can't trigger this.
Nested virtualization doesn't change this: a guest's own nested VMs use vhost in the guest's kernel, not the host's.

Who should treat it as urgent

Multi-user systems: shared hosting, university or lab machines, build and CI runners.
Container hosts that pass /dev/vhost-* into untrusted containers.
Any host where the vhost nodes are world-accessible.
Virtualization hosts running untrusted guests with a virtual IOMMU.

Who can schedule it normally

Hosts where only admins have logins, the vhost nodes are 0660 root:kvm, the kvm group has no untrusted members and guests have no virtual IOMMU.
The remaining risk there is chaining: someone who first escapes a VM into QEMU through a different bug could use this to get host root. So patch in your next maintenance window rather than ignoring it.

Quick checks

ls -l /dev/vhost-*                      # world-accessible = urgent
getent group kvm                        # extra members = root-equivalent
virsh dumpxml <vm> | grep -i iommu      # nothing = guest path not reachable
cat /proc/version                       # compare to your distro's advisory

Many distributions shipped the fix well before the public write-up, so you may already be patched. The running kernel is what counts: an installed but un-rebooted kernel doesn't protect you.

Stopgaps if you can't reboot yet

Restrict the vhost nodes to root or kvm and unload vhost_vsock if you don't use it. Changing permissions doesn't close file descriptors that are already open, and it doesn't stop the guest-side attack. Only the kernel fix does that.