Dark Corners: How a Failed Patch Left VMware ESXi VM Escapes Open for Two Years

Dark Corners: How a Failed Patch Left VMware ESXi VM Escapes Open for Two Years

Speakers: Yuhao Jiang, Xinlei, and Ziming (Security Researchers, ANK Group Security Lab)

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: Watch the full talk

Reading time: ~9 minutes

Type: Briefing

TL;DR

Researchers from ANK Group Security Lab discovered that CVE-2021-22050, a VMware ESXi XHCI USB controller vulnerability first disclosed in 2021, was never correctly patched. By exploiting the same root vulnerability through a slightly different code path, they achieved a full VM escape at the Tianfu Cup 2023. The issue was re-assigned CVE-2024-22252 — over two years after the original CVE. In a separate finding, they discovered CVE-2024-22254, an out-of-bounds write vulnerability in ESXi's Changed Block Tracking (CBT) kernel driver, enabling a complete sandbox escape after the initial VM escape.

Introduction

VMware ESXi is among the most critical hypervisor platforms in enterprise environments, and a successful VM escape — where code running inside a guest virtual machine gains control of the ESXi host — represents one of the most severe possible security outcomes. The impact was underscored earlier in 2025 when VMware disclosed that several ESXi vulnerabilities had been exploited in the wild.

At Black Hat USA 2025, researchers Yuhao Jiang and Ziming from ANK Group Security Lab presented the story behind their Tianfu Cup 2023 ESXi exploit: a full two-stage attack that first breaks out of the virtual machine via a vulnerability in the XHCI USB controller, then escapes the ESXi sandbox via a bug in the CBT kernel driver. The talk is notable not just for its technical depth but for the researchers' candid analysis of why a critical vulnerability remained unfixed for two years — and what the security ecosystem can do about it.

Stage One: VM Escape via a "Failed Patch" in the XHCI Controller

The 2021 Vulnerability and Its History

The story begins with a vulnerability reported at the 2021 Tianfu Cup by Wei from Kunlun Lab. The issue resided in VMware's XHCI USB controller implementation — specifically in the interaction between two command ring handler functions. The flaw allowed an attacker to modify a slot context before xhci_clear_string_context executed, causing a use-after-free (UAF) condition where a pipe object and its URB (USB Request Block) data packets remained in memory after the string context they referenced had been freed.

▶ Watch: The ancient vulnerability explained (04:00)

Why the Patch Never Worked

When ANK Group began researching VMware for Tianfu Cup 2023, they examined VMware's latest patched version and made a surprising discovery. VMware had added new code to the xhci_fetch_pipe function, introducing a second code path for fetching pipes based on slot state. Jiang realized this new code path could be abused in the same way as the original vulnerability — by modifying a specific slot member to make xhci_fetch_pipe fail and thus skip the pipe cleanup.

More critically, the researchers discovered that the original patch was not actually complete. The xhci_clear_string_context function accepts an EPID parameter that limits it to clearing the string context of a specific endpoint — but the entire slot context had already been modified by the attacker. By modifying the slot content, clearing one endpoint's string context, and then executing a disable slot command to clear all endpoints, attackers could trigger the same UAF condition in the fully patched version.

▶ Watch: The failed patch revealed (08:01)

"So it's never been successfully patched," Jiang said, noting that the issue was re-assigned CVE-2024-22252 when reported in 2023 — with no public acknowledgment that it was the same underlying flaw as CVE-2021-22050.

Exploitation: HashMap Primitive and Heap Manipulation

The UAF condition itself is highly constrained — it only affects a 4-byte value at offset 0x205C of the freed chunk, and the only available operation is subtraction. This creates a significant exploitation challenge: modifying the high 4 bytes of a pointer is meaningless, and 0x205C is a large offset requiring precise heap layout control.

The breakthrough came from VMware's own XHCI string context HashMap. Each HashMap element stores a pointer to a string context plus a 4-byte ID — exactly 12 bytes. This meant the UAF could target the second element at the +0xC position, modifying the low 4 bytes of a string context pointer to point to attacker-controlled memory (a fake string context).

▶ Watch: HashMap exploitation primitive (10:02)

From there, the team leveraged VMware's MOB_SURFACE and GMR objects from the SVGA graphics subsystem as additional exploitation primitives for heap spraying and grooming. The full chain — information leak, heap address recovery, fake object forgery, heap overlap, and finally control flow hijacking via a forged VUSB device function pointer in a URB — yielded arbitrary code execution in the VMX process. After that, a stack pivot via ROP and shellcode injection completed the virtual machine escape.

Stage Two: ESXi Sandbox Escape via the CBT Driver

How ESXi's Sandbox Works

The VMX process does not run with unrestricted host access. ESXi uses a proprietary security domain system — analogous to Linux's SELinux or seccomp — with over 100 sandbox domains restricting each process's access to files, networks, and system calls. The VMX domain is created fresh for each virtual machine and enforces strict syscall filtering via access class bitmasks applied at the VMware kernel level.

▶ Watch: ESXi sandbox architecture (20:04)

The VMware kernel adds over 700 custom syscalls beyond the standard Linux table (for syscall numbers under 400, standard Linux semantics apply). Each syscall belongs to an access class, and each domain carries a bitmask of permitted classes, making it possible to map which syscalls are available within the VMX sandbox.

CVE-2024-22254: Out-of-Bounds Write in the CBT Driver

While auditing the VMX sandbox's allowed access rules, researcher Ziming noticed that the VMX process has read and write access to the Changed Block Tracking (CBT) device driver — a small kernel module used to track which blocks of a VM's virtual disk have changed between snapshots.

The CBT driver has only 15 functions, making it a compact target. The vulnerability lives in the update_bitmap function, which performs an out-of-bounds write based on user-controlled offset and size values. While an earlier check validates these values against the file size, the bitmap's size is computed when the file is first opened — and if the file is subsequently enlarged, the bitmap remains small while the file size check passes against the newer, larger size. An attacker can therefore write past the end of the bitmap.

▶ Watch: CBT vulnerability walkthrough (26:05)

Exploitation: Kernel Address Leak and Arbitrary Write

The exploitation path uses the bitmap object itself as the primitive. The CBT driver's heap is isolated from the main VMware kernel heap — but within that isolated space, the bitmap object (bitmap_pointer + bitmap_size fields) is a perfect target. By using the out-of-bounds write to inflate the bitmap_size field, the attacker gains an out-of-bounds read, leaking kernel addresses via copy_out. By overwriting bitmap_pointer to zero (possible via the OR-only write primitive when the current value has zero bits that need flipping) and then resetting it to an arbitrary address, the attacker achieves arbitrary write. The attack chain:

1. OOB write to expand bitmap_size → OOB read → kernel address leak
2. OOB write to corrupt the next chunk's size → free the chunk → heap merging clears bitmap_pointer to zero
3. Write bitmap_pointer to arbitrary address → arbitrary write primitive
4. Modify the syscall access mask table to call the domain-clearing syscall
5. Sandbox closed — full ESXi host control

▶ Watch: Demo video from Tianfu Cup 2023 (32:05)

Why VMware Vulnerabilities Stay Unfixed: A Structural Problem

Jiang uses the two-year lifespan of CVE-2021-22050 as a starting point for a broader industry critique.

"VMware's bounty program is significantly lower than the actual value of these vulnerabilities," he said, explaining that this creates a market incentive for researchers to use ESXi vulnerabilities in competitions like Tianfu Cup or Pwn2Own rather than disclosing them — and competitions held once a year inevitably extend the window during which those vulnerabilities remain unpatched.

Two additional factors compound the problem: VMware is closed-source with high barriers to entry, so relatively few researchers study it; and the community lacks VMware-specific technical knowledge sharing. ANK Group cites this as their motivation for presenting ESXi research at Black Hat for two consecutive years.

Notable Quotes

"So it's never been successfully patched."

— Yuhao Jiang, on CVE-2021-22050 [[▶ 08:01]](https://www.youtube.com/watch?v=MhQmaK8Zsfw&t=481s)

"A vulnerability from 2021 wasn't truly fixed until 2024. This phenomenon deserved reflection."

— Yuhao Jiang [[▶ 16:02]](https://www.youtube.com/watch?v=MhQmaK8Zsfw&t=962s)

"Even small drivers can be dangerous. Hope more researchers will focus on VMware kernel security."

— Ziming, on the CBT driver vulnerability [[▶ 30:05]](https://www.youtube.com/watch?v=MhQmaK8Zsfw&t=1805s)

Key Takeaways

• "Patched" does not mean "fixed." CVE-2021-22050 received a patch in 2021 and a new CVE (CVE-2024-22252) in 2024 — for what was fundamentally the same vulnerability exploitable via a different code path. Patch verification must include testing for logically equivalent exploitation paths, not just the specific PoC submitted.
• Small, obscure kernel components are high-value targets. The CBT driver — a 15-function module with a narrow purpose — contained a critical out-of-bounds write that enabled full ESXi sandbox escape. Reduced code complexity does not imply reduced risk.
• The VMware security ecosystem has a market-failure problem. Below-market bounties redirect high-severity ESXi research toward competitions and gray markets, extending vulnerability lifespans and increasing the probability of in-the-wild exploitation.
• VM escapes typically require guest root. Most VMware attack surface (virtual devices) requires root privileges in the guest to interact with, limiting practical exploitation to scenarios where the guest OS is already fully compromised.
• ESXi provides two layers of defense. The sandbox escape via CVE-2024-22254 was necessary because the VM escape alone still left the attacker confined to the VMX process sandbox. Defenders should understand that even a full VM escape does not automatically equal host-level compromise on ESXi.

Slides PDF not available for this talk.