Linux's October 2026 Vghost Bug Explained: Who Is Exposed and What to Patch

Every user who can open that file can reach the buggy kernel code, so an ordinary login becomes a path to root. That is the risk the Vghost Linux vhost vulnerability brings to many Linux machines in October 2026.

Picture a common setup. A hosting team runs 24 Linux hosts for customer VMs and 6 shared build servers where 35 developers have their own logins. The setup is made up, but the bug is real.

On 13 October, the team sees an alert about Vghost and asks three questions. Which machines are exposed, which kernel fixes them, and what can change today before every machine reboots? This guide answers them in that order.

You need nine ideas. Each one is used later in the guide.

• Virtual machine (VM): a pretend computer running inside a real one. The real machine is the host; the VM is the guest.
• Kernel: the core of the operating system, which controls memory and hardware. Whoever controls it has root, full control of the machine.
• QEMU: the program on the host that builds and runs each VM.
• vhost: a kernel driver that moves a VM's data directly in the host kernel, skipping QEMU for speed. vhost-net handles networking; vhost-vsock handles VM-to-host sockets.
• Device file: a file under /dev that a program opens to talk to a driver, such as /dev/vhost-net.
• File mode: three digits that say who may read and write a file. 0666 lets every user in; 0660 lets in only the owner and the owning group.
• kvm group: on many distributions, the group of users allowed to run VMs. Members can open files owned by that group.
• CVE: a public ID for a known security bug, such as CVE-2026-74580.
• Backport: a vendor copying a fix into an older kernel it supports, under its own version number.

Vghost is a bug in the Linux vhost driver, tracked as CVE-2026-74580. The fix's title sums it up: vhost now resets its cache of ring address translations when a ring is reconfigured. Before the fix, an old translation could outlive the change. A ring here is a queue in VM memory that vhost reads and writes.

Zhuque Lab published the details. It reports two outcomes. A local user who can open a vhost device file can get root. A guest VM in one special setup can write into its host's QEMU process.

This guide covers exposure, fixed versions, checks and stopgaps only. It does not explain how the bug is triggered, because a defender does not need that to patch.

The cache arrived in Linux 4.11 in 2017. The lab describes the bug as that cache combined with a 2020 change in Linux 5.9. For patching, follow the CVE record: it lists every kernel from 4.11 onward as affected until fixed.

Two groups are exposed. The local door needs someone who can open a vhost device file. The guest door needs a VM with a virtual IOMMU and vhost in device-IOTLB mode.

Think of each host as a building with a faulty lock inside. The vhost files are doors to the room with that lock, and the file mode decides who holds a key. Where the picture breaks: closing a door never repairs the lock; only the patched kernel does.

The local door: device file permissions

The researchers tested /dev/vhost-vsock and found mode 0666 on Red Hat Enterprise Linux (RHEL) 9.8, Amazon Linux 2023, Azure Linux 3.0 and Oracle Linux 10.2. Ubuntu 26.04 used 0660, owner root and group kvm.

udev is the service that sets device file permissions at boot. Ubuntu 24.04's udev package (255.4-1ubuntu8.18, checked 19 October 2026) also ships both vhost files at 0660 root:kvm. The researchers say several distributions get 0666 from systemd's default udev rules.

The team's 6 build servers run Amazon Linux 2023, so /dev/vhost-vsock shows 666 there, and 35 developers can log in. On a vulnerable kernel, any of them could become root. Containers, isolated apps that share the host's kernel, count too if a runtime passes a vhost device into one.

The guest door: a vhost device behind a virtual IOMMU

An IOMMU is a translator and gatekeeper for device memory access. It turns a device address into a real memory address and refuses anything outside the allowed region. A vIOMMU is a virtual one that QEMU gives to a guest.

In device-IOTLB mode, vhost asks QEMU for these translations and caches them. IOTLB means I/O translation lookaside buffer, a cache of translations.

The researchers list three conditions for their guest path: a vIOMMU, vhost in device-IOTLB mode and iommu_platform on the device. That last setting sends the device's memory access through the vIOMMU. Their write-up describes no guest path without all three.

In practice, two settings make all three true. In the Linux and QEMU source we read on 19 October 2026, vhost enters device-IOTLB mode whenever a vhost device behind a vIOMMU has iommu_platform on.

Do not confuse this with device-iotlb, an option of QEMU's emulated Intel IOMMU. That option, off by default, turns on device-IOTLB support in that emulated IOMMU, paired with ats=on on the device. ATS (address translation services) lets a device keep its own cache of translations. vhost's mode does not need it.

Most of the team's VMs have no vIOMMU. One customer's plan uses a vIOMMU with iommu_platform on, on 2 hosts.

How to check both doors from a shell

The stat command prints the mode as three digits like 666, then owner and group. getent lists the members of a group. The pgrep line counts running QEMU processes with both a vIOMMU and iommu_platform on. It matches plain flags and the JSON form some tools pass.

# Who can open the vhost device files? (run on each host)
stat -c '%a %U:%G %n' /dev/vhost-net /dev/vhost-vsock
# First field 666: every user can open the file
# First field 660: only the owner and the group can

# Who is in the group that owns them (kvm on Ubuntu)?
getent group kvm

# Guest door: count QEMU processes with a vIOMMU and iommu_platform on.
# 0 means no running VM has both on its command line.
pgrep -a qemu | grep -E 'intel-iommu|amd-iommu|virtio-iommu|smmuv3' \
  | grep -cE 'iommu_platform(=on|=yes|=true|":true)'

# libvirt VM: print its vIOMMU and iommu='on' lines (none on a plain VM)
virsh dumpxml myvm | grep -E "iommu model=|iommu='on'"

libvirt is a common tool that manages QEMU VMs, and it uses vhost for virtio networking by default when the host has it. For a libvirt VM, the virsh line in the block prints the settings that matter; put your VM's name in place of myvm.

An iommu element line plus a driver line with iommu='on' means the guest-door setup. A plain VM prints nothing. The attributes iotlb='on' and ats='on' may also appear, but they are not the test.

As of 19 October 2026, Vghost scores 7.8 to 8.8 on CVSS 3.1, a 0 to 10 severity scale, and Ubuntu sets its priority at Medium. The scorers disagree on two inputs: scope and harm to data integrity.

"Scope changed" means the damage can reach beyond the attacked part, such as a guest reaching its host. That choice raises the number.

CISA, the US cyber defence agency, added its own assessment on 16 October. It records no known exploitation, not automatable, and total technical impact.

Any kernel that contains the fix, main-project commit de845981da67 or one of its stable copies, is fixed. The main Linux project shipped it in these stable releases, listed in the CVE record as of 19 October 2026.

Most machines do not run these exact numbers. Linux distributions backport the fix into their own kernels, so the vendor's CVE page is the answer for a vendor kernel.

• Ubuntu: the standard 22.04 kernel is fixed in 5.15.0-198.208. As of the page's 13 October update, 24.04 and 26.04 show "Vulnerable, work in progress".
• Amazon Linux: on 31 August, Amazon Linux 2023 got fixes in ALAS2023-2026-2107 (kernel), ALAS2023-2026-2110 (kernel6.12) and ALAS2023-2026-2106 (kernel6.18). Live patches and Amazon Linux 2 fixes are listed too.
• Oracle Linux: UEK kernel errata from 4 September, with the latest listed on 16 October.
• Red Hat: as of 19 October 2026, its CVE page shows a score and a mitigation, and we found no fixed package listed. Recheck it for your release.
• Other vendors: read your vendor's CVE-2026-74580 page for the package that fixes your release.

Read the running kernel's version, then compare it with the table or your vendor's page. The command uname -r prints it, for example 6.18.44-fc-v139 on our test machine.

The check below prints the running kernel and the vhost file modes. It compares only against the main project's version numbers, so a patched vendor kernel such as 5.15.0-198-generic still shows False. For those, trust the vendor page. Kernels older than 4.11 also print False, though the CVE record lists them as unaffected.

import os, platform, re, stat

# First fixed upstream stable release per branch (CVE record, as of 19 Oct 2026)
FIRST_FIXED = {(5, 10): 265, (5, 15): 216, (6, 1): 183, (6, 6): 152,
               (6, 12): 104, (6, 18): 45, (7, 1): 9}

def matches_upstream_fix(release):
    if "-rc" in release:
        return False                            # test kernels: assume not fixed
    m = re.match(r"(\d+)\.(\d+)(?:\.(\d+))?", release)  # copes with 6.18.45+
    major, minor, patch = int(m[1]), int(m[2]), int(m[3] or 0)
    if (major, minor) >= (7, 2):
        return True
    return patch >= FIRST_FIXED.get((major, minor), 10**6)

print(platform.release(), "main-project fix:", matches_upstream_fix(platform.release()))
for dev in ("/dev/vhost-net", "/dev/vhost-vsock"):
    if os.path.exists(dev):
        mode = stat.S_IMODE(os.stat(dev).st_mode)
        print(dev, oct(mode), "OPEN TO ALL USERS" if mode & 0o006 else "restricted")

On a host running 6.18.44 it prints "6.18.44 main-project fix: False", because the first fixed 6.18 release is 6.18.45. On an open build server it also prints "/dev/vhost-vsock 0o666 OPEN TO ALL USERS".

Run it again after the reboot. A fixed main-project kernel prints True, and a host with locked files prints 0o660 and restricted.

Install the fixed kernel package from your vendor, then reboot into it. The package changes nothing until the machine runs the new kernel.

1. 1

   List every Linux machine

   Include VM hosts and every build server. The team's list has 30 machines.

2. 2

   Check the vendor CVE page

   Find the fixed package for your release on your distribution's CVE-2026-74580 page.

3. 3

   Patch the riskiest machines first

   Start with hosts where untrusted users can open vhost files, then hosts running vIOMMU guests.

4. 4

   Move VMs, then reboot

   Move running VMs to another host or stop them, then reboot into the new kernel.

5. 5

   Verify after reboot

   Run uname -r and the check above. Confirm the version and recheck the device file modes.

Some vendors offer live patches, which change the running kernel without a reboot. Use one only if your vendor lists it for this CVE, as Amazon Linux 2023 does.

You can shut the local door today. For the guest door, the real fix is the patched host kernel. These stopgaps come from the researchers and Red Hat.

• Remove access for other users on both vhost files now, with chmod o-rw /dev/vhost-net /dev/vhost-vsock. A file at 666 becomes 660. Anyone who starts QEMU as a normal user then needs to be in the file's group.
• Make it stick with a udev rule, because /dev is rebuilt at every boot and a chmod is lost.
• Treat the kvm group, or any group owning these files, as privileged until you patch.
• Stop untrusted containers from receiving vhost devices through your container runtime's device settings.
• Where VMs do not need vhost, Red Hat suggests blocking the vhost kernel module (a piece of the kernel loaded on demand) from loading. This can slow VM networking and storage, or stop VMs that need vhost from starting.

A safe pattern is to copy your distribution's own vhost lines into a later rules file, with the mode set to 0660. Ubuntu 24.04 already ships them that way, as below. They pass udevadm verify on udev 255.

# /etc/udev/rules.d/99-vhost-lockdown.rules
# Same lines Ubuntu 24.04 ships in 50-udev-default.rules
KERNEL=="vhost-net", GROUP="kvm", MODE="0660", OPTIONS+="static_node=vhost-net"
KERNEL=="vhost-vsock", GROUP="kvm", MODE="0660", OPTIONS+="static_node=vhost-vsock"

For the module block, Red Hat's page gives two commands. The first stops autoloading: echo "install vhost /bin/true" > /etc/modprobe.d/disable-vhost.conf. The second uses modprobe, the tool that loads and unloads modules, to unload the drivers if no guest uses them: modprobe -r vhost_net vhost_vsock vhost_scsi vhost.

Red Hat adds that a reboot, or stopping active VMs, is needed if the driver is loaded and in use. Run lsmod and look for lines starting with vhost to see what is loaded.

To check the block without loading anything, run modprobe -n -v vhost_net, a dry run. In our test with kmod 31, the vhost.ko line became install /bin/true. vhost_net depends on vhost, so it should then fail to load; confirm with lsmod on one host first.

The team's 24 VM hosts run Ubuntu 24.04, still work in progress on Ubuntu's page as of 19 October. Amazon lists fixes for the build servers' Amazon Linux 2023, released on 31 August.

So the team locks the vhost files on the 6 build servers today and patches them first. It audits the kvm group on all 24 VM hosts, and patches the 2 vIOMMU hosts as soon as Ubuntu's fix ships.

Frame it as incident response for a shared fleet of hosts, in five steps.

1. 1

   Name the boundary

   vhost runs in the host kernel. Its device files and its guests are the two ways in from less trusted code.

2. 2

   Find exposure per door

   Local users need device file access. Guests need a vhost device behind a vIOMMU with iommu_platform on.

3. 3

   Rank by reach

   Patch first where many untrusted users or tenants can reach a door, not where the score is highest.

4. 4

   Patch and verify

   Install the fixed kernel, reboot, and confirm the running version on every machine.

5. 5

   Close doors meanwhile

   Restrict device files with udev rules, audit groups and containers, and keep the rules after patching.