Linux vhost IOTLB cache bug enables kernel read/write and guest escape

A new vulnerability named Vghost has been disclosed in the Linux kernel vhost subsystem. The flaw stems from a stale IOTLB metadata cache that allows attackers to escalate privileges and escape virtual machines.

What happened

Fourie posted an advisory to the oss-security mailing list on October 13 regarding CVE-2026-74580. The issue affects Linux vhost frontends due to how they cache IOTLB mappings for descriptor, available, and used rings. The `vq->meta_iotlb[]` array retains stale data that can be exploited by local users or guest systems.

A local user with access to `/dev/vhost-*` devices can leverage this flaw to perform arbitrary kernel read and write operations. This access path ultimately grants the attacker root privileges on the host system. The vulnerability is inherent in the way the frontend manages memory mapping caches.

Guest virtual machines can also exploit the bug under specific conditions. If a guest uses vIOMMU combined with `iommu_platform` and `VIRTIO_F_RING_RESET`, it can trigger a QEMU heap overwrite. This overwrite allows for control-flow hijacking, effectively enabling a guest-to-host escape.

Why it matters

This vulnerability provides two distinct attack vectors for compromising host integrity. The local privilege escalation path requires only access to the vhost device interface. The virtual machine escape path requires a specific combination of virtualization features and configurations within the guest environment.

The ability to write arbitrarily to kernel memory represents a severe risk to system security. Attackers can bypass standard isolation boundaries and gain full control over the underlying host. This undermines the trust model of virtualized environments where guests are expected to remain isolated.

What to watch

• Monitor oss-security and vendor advisories for official patches addressing CVE-2026-74580.
• Check internal logs for unusual access patterns to `/dev/vhost-*` devices.
• Review virtual machine configurations for use of vIOMMU and VIRTIO_F_RING_RESET.
• Audit user permissions for access to vhost device nodes on all Linux hosts.

Who needs to act first

Teams should prioritize auditing systems that expose vhost devices to untrusted users or multi-tenant environments. Verify which virtual machines utilize the specific IOMMU and VIRTIO reset features mentioned in the advisory. Implement strict access controls on device nodes to limit local exploit potential. Test any available mitigations in isolated environments before applying them to production workloads. Ensure backup procedures are current in case remediation requires system reconfiguration.

Background: Virtual machines

Virtual machines create isolated execution environments using a hypervisor to separate guest operating systems from the underlying hardware. This architectural boundary contains malware, simplifies patch management, and enables rapid recovery from incidents without exposing adjacent systems or requiring physical hardware replacement.

Read the full guide: Why Virtual Machines Matter for Security Posture

What to do and how to stay safe: Linux

• Restrict permissions on `/dev/vhost-*` devices to authorized users and processes only.
• Disable `VIRTIO_F_RING_RESET` in guest configurations where it is not strictly required.
• Monitor system logs for indicators of kernel memory corruption or unauthorized vhost access.
• Isolate compromised virtual machines immediately to prevent lateral movement or host takeover.

Step-by-step guide: Spot Privilege Escalation Warning Signs Before Breach

General security guidance from the Patch Gazette newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

What is the CVE ID for the Vghost vulnerability?

The CVE ID for the Vghost vulnerability is CVE-2026-74580.

Which Linux components are affected by this flaw?

The Linux vhost frontends are affected by the stale IOTLB metadata cache vulnerability.

How can a guest virtual machine escape to the host?

A guest can escape by using vIOMMU, iommu_platform, and VIRTIO_F_RING_RESET to overwrite the QEMU heap.