CVE-2021-45464 - Out-of-Bounds Write in kvmtool Lets Guest OS Attack Host

If you’re running virtual machines (VMs) using kvmtool, you need to know about CVE-2021-45464. This serious vulnerability allows a user inside a guest OS to write to memory outside its allocated buffer on the host. In plain English: a hacker in a virtual machine might run code directly on the host, bypassing key security boundaries.

This flaw affects kvmtool up to commit 39181fc. It’s part of the “virtio balloon” functionality, which lets VMs tell the hypervisor to change their memory size. Let’s break it down, look at the code, and see how an attacker would exploit this.

What is kvmtool?

kvmtool is a lightweight, userspace tool for managing VMs on Linux using KVM (Kernel-based Virtual Machine). While not as popular as QEMU, it’s favored for simplicity and quick boot times.

The issue exists in two files

- virtio/balloon.c
- virtio/pci.c

These files handle the VirtIO Balloon device, which lets a VM request more or less memory from the host. The problem is that they don’t properly check the size of some memory operations. This allows a buffer overflow (writing past the end of an array in C code).

All an attacker needs is a regular user account in a guest VM—they don’t need higher privileges. By carefully crafting requests to the balloon device, they can overwrite host memory, possibly running their own code on the host.

Code Under the Microscope

Let’s look at a simplified version of the vulnerable code. The bug comes from not doing bounds checking on memory region and array access.

Vulnerable Code Snippet (Simplified)

// In virtio/balloon.c
static void virtio_balloon_handle_write(struct virtio_device *dev, struct virtqueue *vq)
{
    struct virtio_balloon *balloon = to_balloon(dev);
    u16 num_pages;
    u32 page_frame_number;
    int i;

    // Fetch the number of pages to update from the guest
    num_pages = get_unaligned_le16(vq->desc); // No bounds check!

    // Each page index is 4 bytes. Guest supplies data.
    for (i = ; i < num_pages; i++) {
        page_frame_number = get_unaligned_le32(vq->desc + (i * 4)); // Vulnerable read
        balloon->pfns[i] = page_frame_number; // Vulnerable write (out-of-bounds!)
    }
}

What’s wrong? The guest can provide a num_pages value larger than the size of balloon->pfns. No one is checking if i exceeds the array size! That means the guest can write past the end of memory it controls.

Start a VM as a normal (non-root) user.

2. Exploit the balloon driver: Use custom code to send a balloon increment/decrement request with a huge (malicious) num_pages, plus carefully chosen values for the pages array.
3. Overflow and overwrite: When the buggy code runs on the host, it writes outside the pfns array, potentially overwriting important memory (function pointers, control structures).
4. Execute arbitrary code: With careful memory layout and the right data, the attacker could trigger execution of their code on the host.

No privilege escalation required in the guest OS—it’s enough to have a user inside the guest.

Proof-of-Concept (PoC) Snippet

*Due to safety, here's only a mockup PoC showing what an attack in the guest OS might try:*

import struct
import os

# Hypothetical balloon device
BALLOON_DEV = "/dev/vballoon"

# Send a huge num_pages to overflow buffer
num_pages = x100000  # Too big!
payload = struct.pack("<H", num_pages)
for _ in range(num_pages):
    payload += struct.pack("<I", xdeadbeef)  # Malicious page vals

with open(BALLOON_DEV, "wb") as f:
    f.write(payload)

*In reality, more reverse engineering is needed to target a working exploit for your specific host system.*

Original References

- CVE page on NVD
- kvmtool commit 39181fc
- oss-security mailing list


## Fix / Mitigation

The fix is (relatively) simple: Always check user-supplied indices and lengths. kvmtool patches add strict bounds checks to ensure user requests can’t go beyond what’s allowed.

Apply all recent patches.

- If you use kvmtool "as is" from git, ensure you’re using a version later than the vulnerable commit.

Conclusion

CVE-2021-45464 shows even “small” hypervisors can open big security holes. Always keep VM hosts updated, and never trust guest OS code to be harmless. Boundaries like virtual memory devices must be locked down tight, or you risk giving attackers a free ride to your main host OS!


*Remember: never test kernel or hypervisor exploits on systems where you don’t have explicit permission or on production systems. Stay safe and patch early.*

Timeline

Published on: 04/15/2023 23:15:00 UTC
Last modified on: 04/26/2023 14:46:00 UTC