CVE-2026-45782: Cloud Hypervisor Use-After-Free Flaw

CVE-2026-45782 Overview

Cloud Hypervisor is a Virtual Machine Monitor (VMM) for Cloud workloads written in Rust. A use-after-free vulnerability ([CWE-416]) affects versions 21.0 through versions prior to 51.2. A malicious guest can trigger memory corruption in the host cloud-hypervisor process by submitting two virtio-block descriptor chains that reuse the same head_index while asynchronous block I/O is enabled, such as io_uring or aio. When the kernel completes the duplicate operation before the original, the completion path frees a bounce buffer that the kernel is still actively reading from or writing to. The issue has been patched in versions 51.2 and 52.0.

Critical Impact
A guest-initiated use-after-free in the host VMM process can corrupt freed memory and break the guest-host isolation boundary, putting confidentiality, integrity, and availability of the host at risk.

Affected Products

Cloud Hypervisor versions 21.0 through 51.1
Cloud Hypervisor deployments using virtio-block with async I/O backends (io_uring, aio)
Multi-tenant virtualization hosts running vulnerable Cloud Hypervisor builds

Discovery Timeline

2026-06-10 - CVE-2026-45782 published to NVD
2026-06-10 - Last updated in NVD database

Technical Details for CVE-2026-45782

Vulnerability Analysis

The vulnerability resides in the virtio-block device implementation within Cloud Hypervisor. The device processes I/O requests from guests through virtqueues, where each request is identified by a head_index that maps the descriptor chain to in-flight buffer state. When async I/O backends such as io_uring or aio are enabled, multiple operations can be in flight simultaneously. The VMM does not adequately validate that a guest-supplied head_index is not already associated with an active request.

A guest with the ability to craft raw virtqueue submissions can submit two descriptor chains that reuse the same head_index. When the second operation completes before the first, the completion handler frees the bounce buffer associated with that index. The kernel async I/O thread still references the buffer for the original outstanding operation, leading to a read or write into freed memory in the host process address space.

Root Cause

The root cause is missing uniqueness enforcement on the head_index used to track in-flight async block requests. The completion path assumes a one-to-one mapping between head_index and live bounce buffer state, but a malicious guest can break that invariant. The result is a classic use-after-free ([CWE-416]) where one code path frees the buffer while another path still holds a live reference.

Attack Vector

Exploitation requires local access from within a guest VM. The attacker controls the guest virtio driver and crafts duplicate descriptor submissions targeting the virtio-block queue. No host-level privileges or user interaction are required. Successful exploitation corrupts host memory in the cloud-hypervisor process, enabling potential code execution within the VMM, sandbox escape from the guest, or compromise of co-located tenants. The attack complexity is low, but the technique depends on async I/O being enabled on the target block device.

No public proof-of-concept code has been released. Technical details are documented in GitHub Security Advisory GHSA-f47p-p25q-83rh and GitHub Pull Request #8220.

Detection Methods for CVE-2026-45782

Indicators of Compromise

Unexpected crashes or aborts of the cloud-hypervisor host process, particularly with heap corruption signatures from the Rust allocator
Host kernel logs showing io_uring or aio completion errors tied to a specific guest's block device
Guest virtio-block drivers issuing anomalously high rates of overlapping or malformed descriptor submissions

Detection Strategies

Monitor the cloud-hypervisor process for SIGSEGV, SIGABRT, or AddressSanitizer-style abort signatures across the fleet
Inventory all Cloud Hypervisor instances and flag versions between 21.0 and 51.1 running with io_uring or aio block backends
Correlate guest virtqueue activity patterns with host-side VMM stability events to identify suspicious tenants

Monitoring Recommendations

Enable core dump collection for cloud-hypervisor processes and forward stack traces to centralized logging
Track VMM restart counts and crash frequency per tenant as a behavioral signal
Alert on host kernel messages referencing block I/O completion anomalies tied to guest virtio devices

How to Mitigate CVE-2026-45782

Immediate Actions Required

Upgrade Cloud Hypervisor to version 51.2 or 52.0 on all virtualization hosts
Audit running VMs for tenant isolation requirements and prioritize multi-tenant hosts first
Restart guest workloads against patched VMM binaries to ensure no vulnerable processes remain in memory

Patch Information

The issue is fixed in Cloud Hypervisor 51.2 and 52.0. The remediation is tracked in GitHub Pull Request #8220 and committed in commit 1314ac88. Release artifacts are available at Cloud Hypervisor v51.2 and Cloud Hypervisor v52.0.

Workarounds

Disable asynchronous block I/O backends and fall back to synchronous I/O on the virtio-block device until patches are deployed
Restrict the deployment of untrusted guests on hosts that cannot be immediately patched
Apply strict per-tenant resource isolation and limit block device exposure for guests where async I/O is required

bash

# Configuration example: launch a guest without async block I/O backends
# Avoid io_uring/aio by selecting the synchronous backend until upgrading to 51.2 or 52.0
cloud-hypervisor \
  --kernel /path/to/vmlinux \
  --disk path=/path/to/disk.img \
  --cpus boot=2 \
  --memory size=2G
# Note: omit `io_uring=on` or `aio=on` parameters on the --disk argument