Critical Linux vhost Flaw (CVE-2023-5088) Lets Attackers Gain Root, Escape VMs

Key Takeaways

• A critical vulnerability, CVE-2023-5088, has been disclosed in the Linux kernel’s vhost subsystem.
• The flaw carries a CVSS v3.1 score of 8.8 and can lead to local privilege escalation or, in specific configurations, a virtual machine escape.
• A public proof-of-concept (PoC) demonstrates how attackers can exploit this bug to gain root privileges on affected Linux systems.
• Patched kernel versions are available, and immediate updates are strongly recommended for all administrators.

A severe vulnerability within the Linux kernel’s vhost component, identified as CVE-2023-5088, has been publicly disclosed, accompanied by a functional proof-of-concept. This flaw enables a local attacker to achieve root-level access or, under specific virtual machine (VM) configurations, break out of a guest VM to compromise the host. The issue has been assigned a CVSS v3.1 score of 8.8, indicating its high severity, and has been addressed in recent Linux kernel updates.

Understanding the Vhost Flaw

The vhost system is a critical part of the Linux kernel designed to accelerate network and device traffic handling for virtual machines. It utilizes shared virtual queues, known as virtqueues, to facilitate high-speed data exchange between a guest VM and its host. The vulnerability stems from how vhost manages the caching of IOTLB (I/O Translation Lookaside Buffer) mappings, which are essential for locating these virtqueues in memory.

The core problem arises when a virtual ring is reconfigured. While Linux updates the ring’s address or size, it fails to clear the corresponding cached mapping for the ring’s descriptor or its associated available and used data fields. Consequently, a subsequent cache hit can bypass the necessary address verification, translating the new address using an outdated mapping. This can result in a pointer that directs kernel copy routines to an invalid memory location.

Researchers investigating this vulnerability, as detailed on the Seclists mailing list traced the bug, pinpointed its origin to two distinct kernel modifications. One change introduced the metadata cache, while the other implemented deferred validation for guest I/O addresses.

Proof-of-Concept Demonstrates Exploitation

The released proof-of-concept illustrates two primary attack vectors for CVE-2023-5088.

Local Privilege Escalation

To achieve local privilege escalation, an attacker must first possess permissions to open a vhost device, such as /dev/vhost-net or /dev/vhost-vsock. The PoC works by priming the cache, then altering a ring address without invalidating the cached entry, and finally triggering the queue. This sequence, according to researchers, allows for arbitrary kernel memory read and write operations.

The demonstrated attack chain leverages a kernel memory read to ascertain the kernel’s address space layout randomization (ASLR) offset. Subsequently, it writes to the kernel’s modprobe_path setting. By triggering a kernel module request, the attacker can then execute a controlled helper application with root privileges.

Researchers successfully reproduced this attack on various distributions, including Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Azure Linux 3.0, and Oracle Linux 10.2. Notably, device permissions varied across these systems: the tested Ubuntu system restricted access to the kvm group, whereas other distributions exposed the vhost device to standard users. This highlights the importance of device permissions as an exposure factor, though it does not negate the necessity of patching. Membership in the kvm group or any other group granting access to vhost devices should be considered privileged until systems are updated.

Virtual Machine Escape

The second attack path originates from within a virtual machine. This scenario requires a vhost device configured with a virtual IOMMU (iommu_platform) and the virtio queue-reset feature (VIRTIO_F_RING_RESET). A malicious guest can reset and re-enable a queue, prompting the host to reconfigure its ring while the stale metadata remains in the cache.

When the guest subsequently triggers the queue, the outdated mapping can lead to a “used-ring” write operation that extends beyond the guest’s allocated memory, potentially corrupting the QEMU process heap. Researchers indicate that this corruption can cause QEMU to crash or allow for manipulation of its control flow. It’s crucial to note that this represents a configuration-dependent VM escape risk and does not imply that every virtual machine is vulnerable to escape via this flaw.

Patch and Mitigation

The upstream fix for CVE-2023-5088 addresses the vulnerability by ensuring that the vring metadata cache is cleared whenever the ring address or size is modified. This guarantees that any new configuration undergoes proper IOTLB validation.

The first stable kernel releases incorporating this fix include versions 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9, and 7.2. Administrators are urged to install a patched kernel version or a vendor-provided backport and reboot their systems immediately.

What You Should Do

• Update Immediately: Install the latest patched Linux kernel versions (5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9, 7.2, or newer) or apply vendor-specific backports provided by your distribution. Remember to reboot after applying the kernel update.
• Restrict Vhost Device Access: Until systems are patched, strictly limit access to all vhost device nodes, including /dev/vhost-net, /dev/vhost-vsock, /dev/vhost-scsi, and /dev/vhost-vdpa-*. Treat membership in groups like kvm as privileged.
• Avoid Untrusted Containers: Do not expose vhost devices to untrusted containers.
• Virtualization Host Precautions: For unpatched virtualization hosts, avoid exposing vhost devices utilizing iommu_platform behind a virtual IOMMU to untrusted guest VMs. Be aware that changing file permissions does not revoke file descriptors already opened and does not mitigate the guest-triggered escape path.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.