Pedal to the Metal: Accelerating to the Host via VirtualBox VMSVGA

Pedal to the Metal: Accelerating to the Host via VirtualBox VMSVGA

Speakers: NiNi Chen (Security Researcher, DEVCORE), Wei Che Kao (Xiaobye) (Security Researcher, DEVCORE)

Conference: OffensiveCon

YouTube: https://www.youtube.com/watch?v=iMZJE2d7ZMU

Overview

In this compelling talk from OffensiveCon, DEVCORE security researchers NiNi Chen and Wei Che Kao (Xiaobai) pull back the curtain on a treasure trove of vulnerabilities discovered within VirtualBox's graphic virtualization component, specifically the VMSVGA (and its Windows counterpart, VBox SVGA). The researchers detail a total of 14 distinct security flaws, including use-after-free conditions, out-of-bounds accesses, and integer overflows, which collectively enable a robust virtual machine escape. Their work, initially aimed at preparing for the Pwn2Own competition, highlights the critical importance of secure graphic virtualization implementations in hypervisors.

The presentation meticulously dissects the architecture of VirtualBox's graphic stack, exposing how seemingly minor inconsistencies and unchecked assumptions can lead to powerful host compromise primitives. Chen and Kao not only explain the theoretical underpinnings of these vulnerabilities but also demonstrate practical exploitation techniques for both Linux and Windows hosts, culminating in arbitrary code execution and a full VM escape. This research serves as a stark reminder of the expanded attack surface introduced by features like 3D acceleration and provides invaluable insights for both defenders seeking to harden their virtualized environments and offensive security practitioners exploring hypervisor exploitation.

Background

▶ Watch: Introduction and motivation for VirtualBox research (0:00)

Modern virtualization software often employs graphic virtualization rather than direct pass-through to allow multiple virtual machines to share a single host GPU without requiring specialized hardware features. This architecture involves the guest machine interacting with an emulated GPU, with an intermediate hypervisor layer managing state and translating requests to the host's real GPU. The speakers identified this intermediate representation as a potentially "fragile" area due to its complexity in managing various objects, resources, and calculations.

In VirtualBox, the guest operating system communicates with the emulated SVGA (Super Video Graphics Array) device via PMIO (Port Mapped I/O) and MMIO (Memory Mapped I/O), akin to a PCI device. These operations are then translated by the hypervisor's DX backend (DirectX backend) into IOCTLs sent to the host GPU. Interestingly, VirtualBox uses a unified DX backend across different host operating systems: native DX11 on Windows, DXVK on Linux, and DXMT on macOS. This standardization means that vulnerabilities found in this shared codebase are likely exploitable across various guest/host combinations, significantly increasing their impact.

The VMSVGA (for Linux guests) and VBox SVGA (for Windows guests) controllers are described as VMware SVGA-compatible devices, sharing a singleton implementation controlled by a flag. This implies a shared codebase and, consequently, shared vulnerabilities. A crucial concept in this architecture is the Memory Object (MOB). MOBs are regions of guest-managed memory registered with VMSVGA, which the host uses as buffers for commands, states, and graphics resources. These can include CO tables (Context Object tables), shader bytecodes, surface backing, and context data. The guest driver can read/write data into a mapped MOB region, and the host synchronizes this data into its own buffer pointed to by PV host.

The host needs to understand how a MOB relates to specific DirectX components. This binding is achieved by the guest sending commands to VMSVGA. A key structure is the VMSVGA 3D DX context, which contains an array, ACOT mobs, with 12 elements, each corresponding to a different DX component (e.g., RT view, DX view). A MOB can be bound to these components. For instance, binding a MOB to an RT view component involves creating a host-side GPU buffer for it and assigning this buffer to COT.pARTView. Similarly, for shaders, a MOB containing valid shader bytecode is prepared, and the DX bind shader from guest command binds it to a shader entry after validation. This intricate interplay between guest-controlled MOBs and host-managed DX components forms the foundation for the vulnerabilities discovered.

Key Findings

▶ Watch: VM SVGA: A unified and powerful attack surface (4:10)

The researchers uncovered a significant number of vulnerabilities within VirtualBox's graphic virtualization component, totaling 14 distinct security flaws. These findings were reported to the Zero Day Initiative (ZDI) in August, leading to an unexpected discovery: 10+ collision with other researchers in September. Notably, there was a collision with the "VM breakers" team (part of Team Prison Break), who had successfully exploited VirtualBox at a previous Pwn2Own event. Despite the overlaps, the DEVCORE team identified three entirely new vulnerabilities, one of which remains unpublished.

The vulnerabilities can be broadly categorized into several classes:

1. MOB Lifetime Management Issues: These include situations where a single MOB is shared across different DX components, leading to use-after-free (UAF) when one component frees the MOB's GPU buffer while others still hold dangling pointers. Another UAF scenario arises from inconsistencies between layers, where a destroy GB mob command frees a MOB without informing the DX components still bound to it.
2. Missing Bound Checks: Several instances were found where VirtualBox failed to validate buffer sizes or array indices. Examples include the DX grow seal table command, which neglected to check the source buffer size during migration, and the DX define stream output function, which failed to validate num output stream entries controlled by the guest, leading to out-of-bounds writes.
3. Inconsistency in DX Context: Problems were identified in how the frontend and backend DX contexts synchronize, specifically when the backend's DX shader array was shrunk without updating the frontend's shader states, resulting in out-of-bounds access.
4. Surface Calculation Flaws: Two significant vulnerabilities were found in the surface creation and manipulation logic:

• CVE-2025-30712: An integer overflow in surface map buffer size allowed a large depth value to cause CB blocks and CB surface to become zero, leading to a zero-size memory allocation and subsequent out-of-bounds read/writes. This was reported by "Jiaozi from Google."
• CVE-2026-21957: A similar vulnerability, discovered by the speakers, bypassed the patch for the previous CVE. By directly setting depth to zero, a zero-size memory allocation was again triggered, leading to out-of-bounds read/writes in surface operations that failed to validate the depth dimension (e.g., DX buffer copy).

While many of these vulnerabilities could be easily exploited on Linux due to its more deterministic heap allocation, migrating exploits to Windows presented challenges, primarily due to the Low Fragmentation Heap (LFH). The researchers, however, developed powerful primitives to overcome these challenges, demonstrating a comprehensive understanding of hypervisor exploitation.

Technical Deep Dive

▶ Watch: Key concept: Memory Objects (MOBs) in VM SVGA (5:00)

The core of the research lies in the detailed understanding and exploitation of VirtualBox's graphic virtualization stack. The vulnerabilities leverage flaws in memory management, state synchronization, and input validation.

MOB Lifetime Management Issues

1. Sharing MOBs Across DX Components (Use-After-Free):

• Scenario: A MOB is initially bound to a DX component (e.g., as an RT view) in the DX context. Later, an attempt is made to bind this same MOB to a different DX component (e.g., a shader entry).
• Vulnerability: The VMSVGA backend attempts to validate the MOB's buffer for the new component (e.g., checking for valid shader bytecode). Since the buffer contains data for the previous component (RT view entries), this validation fails. Crucially, upon failure, VMSVGA frees the GPU buffer associated with the MOB and clears PV host, but it fails to update the COT.pARTView pointer in the DX context that still points to the now-freed memory.
• Result: A dangling pointer is created, leading to a use-after-free (UAF) condition. Any subsequent operation using the original RT view binding will access freed memory.

1. Inconsistency Across Layers (destroy GB mob UAF):

• Scenario: A MOB is used by a DX component. The guest then issues the destroy GB mob command to free the MOB.
• Vulnerability: The destroy GB mob command frees the MOB's GPU buffer. However, the binding between the MOB and the DX component is one-directional; the MOB has no knowledge of which components are using it. Therefore, it cannot inform the corresponding DX components to unbind.
• Result: The DX component continues to hold a pointer to the freed MOB buffer, resulting in another use-after-free (UAF).

Missing Bound Checks

1. DX grow seal table Out-of-Bounds:

• Scenario: The CO table can be extended if its buffer is too small. The guest prepares a larger MOB and sends the DX grow seal table from guest command to migrate the data.
• Vulnerability: VirtualBox checks that the copy size does not exceed the size of the destination buffer. However, it fails to check the copy size against the size of the source buffer.
• Result: This oversight allows the guest to specify a copy size larger than the source buffer, leading to an out-of-bounds read during the copy operation.

Inconsistency in DX Context

1. DX set seal table Array Shrink Out-of-Bounds:

• Scenario: The DX context has both a frontend representation (SVGA DX context with shader states array) and a backend representation (P backend DX context with DX shader array). A shader state in the frontend can point to an element in the backend array (e.g., shader ID 2 points to the third element).
• Vulnerability: The guest can use DX set seal table to shrink the size of the DX shader array in the backend. Crucially, the shader states in the frontend are not updated to reflect this change.
• Result: When VMSVGA later attempts to manipulate a shader state that now points beyond the shrunken backend array, it results in an out-of-bounds access.

Missing Bound Checks (DX Front-end/Back-end)

1. DX define stream output Out-of-Bounds Write:

• Scenario: Operations related to stream output involve DX stream output (backend) and DX stream output entry (frontend). The DX define stream output function copies declarations from the frontend to the backend.
• Vulnerability: The number of entries to copy is determined by num output stream entries, a value stored within a MOB's GPU buffer and thus controlled by the guest OS. The DX define stream output function never checks if this value is within valid bounds.
• Result: An attacker can provide an excessively large num output stream entries, leading to an out-of-bounds write during the copy operation.

Surface Calculation Flaws

1. CVE-2025-30712 (Integer Overflow to Zero-Size Allocation):

• Vulnerability: In the surface map buffer size function, which calculates CX blocks, CY blocks, and CZ blocks based on guest-provided width, height, and depth. If a very large depth value is provided, adding depth of block size can cause an integer overflow. This overflow results in CB blocks (and consequently CB surface) becoming zero.
• Result: When memory is allocated for the surface, the argument to the allocation function is zero. This leads to the allocation of a minimal chunk of heap memory (e.g., 8 bytes). Subsequent surface operations, however, still treat this minimal chunk as a huge surface with the original large depth, leading to out-of-bounds reads and writes.

1. CVE-2026-21957 (Zero-Size Allocation without Overflow):

• Vulnerability: This vulnerability bypassed the patch for CVE-2025-30712, which introduced clamped at divide to prevent integer overflows from leading to negative results. The fix ensured allocation would fail if an overflow occurred. However, the researchers found that by directly setting the depth to zero, CZ blocks and CB surface still became zero.
• Result: Memory allocation is again called with zero, resulting in a minimal heap chunk. Although the system now "knows" the depth is zero, some surface operations, such as DX buffer copy, only validate width and height but never check depth. This allows for out-of-bounds writes (and reads by swapping source/destination buffers) on the minimal chunk.

The GPA to HVA Table Primitive

A crucial primitive for exploitation, particularly on Windows, is the GPA to HVA table. This table maintains mappings between Guest Physical Addresses (GPAs) and Host Virtual Addresses (HVAs). When the host accesses guest memory via a MOB, it uses this table to convert GPAs to HVAs. The table's size is variable and controlled by guest input, allowing attackers to dictate its allocation size. This level of control is invaluable for targeting specific Low Fragmentation Heap (LFH) buckets on Windows, which is often a prerequisite for reliable exploitation. The speakers noted that this primitive was introduced in VirtualBox in July 2025, right after they began their research, significantly enhancing their capabilities.

By manipulating entries in the GPA to HVA table, attackers can redirect HVA lookups to arbitrary host memory addresses. This forms the basis for constructing powerful arbitrary read and write primitives on the host, which are essential for achieving full VM escape.

Demo / Proof of Concept

▶ Watch: Binding a MOB to a shader entry example (9:30)

The exploitation strategy described by Xiaobai centers around leveraging a single vulnerability: the MOB GPU buffer use-after-free. This UAF is particularly potent because the GPU buffer's size is variable and guest-controlled, allowing it to be placed into any desired LFH bucket on Windows, thus expanding the available primitives for heap manipulation.

The exploitation process is broken down into three main steps:

1. Information Leak:

• The UAF condition is triggered, leaving pARTView pointing to a freed memory chunk.
• On Windows, due to LFH randomness, a single allocation might not reclaim the freed chunk. Therefore, the guest "sprays" a large number of MOBI objects (Memory Object Information) using define mobi commands.
• One of these MOBI objects reclaims the freed GPU buffer. The CB total (size of the MOBI's GPU buffer) is initially small (e.g., 104 bytes).
• The define runtime view command is then used to modify the CB total of the reclaimed MOBI object to a much larger value (e.g., 4096 bytes), effectively turning the UAF into a limited out-of-bounds read.
• By allocating another MOBI object directly after the (oversized) GPU buffer (by spraying more MOBIs), the read back contest table command, with its expanded read size, can leak the contents of the adjacent MOBI object, which contains interesting pointers. This provides the crucial information leak.

1. Arbitrary Address Read and Write:

• The next step is to transform the UAF into arbitrary read/write primitives using the GPA to HVA table.
• The freed GPU buffer (from the UAF) is now reclaimed by a newly created GPA to HVA table. Again, spraying a large number of GPA to HVA objects ensures successful reclamation into the target LFH bucket.
• The define runtime view command is then used to manipulate this reclaimed table. By controlling the contents of the GPA to HVA table, the attacker can overwrite the HVAs within it, redirecting them to any arbitrary address on the host.
• Arbitrary Read: The guest sends a VMSVGA command that triggers the host to read guest memory into its GPU buffer. However, because the GPA to HVA table has been manipulated, the host's GPA-to-HVA translation resolves to the attacker's target address on the host. The host then reads data from this target address into the GPU buffer. Finally, the guest issues another VMSVGA command to read the GPU buffer contents back to guest memory, thus retrieving the arbitrary host data.
• Arbitrary Write: The guest first sends a command to place the desired payload into the GPU buffer. Then, using the UAF, the GPA to HVA table is manipulated to redirect an HVA entry to the target write address on the host. A final VMSVGA command triggers the host to flush the GPU buffer's contents to the (now-redirected) target address, achieving arbitrary write.

1. Arbitrary Code Execution and VM Escape:

• With arbitrary read/write primitives, the final step is to achieve code execution.
• The leaked MOBI object (from step 1) is used to leak the SVGA ring three state and device instance pointers.
• A function pointer is leaked from a helper table. This pointer allows the calculation of the library base address.
• With the library base, the address of WinExec (on Windows) or a similar function (on Linux) can be calculated.
• A fake helper function table is forged in host memory, with a specific function entry overwritten with the address of WinExec.
• A fake device instance is also forged, containing the command payload and pointing its helper table pointer to the forged table.
• Finally, the device instance pointer in the SVGA ring three state is overwritten with the address of the forged device instance.
• Invoking the define a mobi command (which internally calls a hijacked function) then triggers WinExec with the attacker's payload (e.g., "calc.exe"), resulting in a calculator popping up on the host machine, demonstrating a full VM escape.

The Windows demo was noted to be "a bit slow" due to the need to walk through the import library to resolve WinExec. The Linux exploitation was described as easier due to more deterministic heap allocation, but followed a very similar logical flow using the same core primitives. Both demos successfully showed a calculator popping up on the host, confirming the VM escape.

Defensive Implications

▶ Watch: Introducing the first class of VM SVGA vulnerabilities (10:30)

The most critical defensive implication highlighted by the speakers is a direct recommendation to avoid enabling 3D acceleration in VirtualBox unless absolutely necessary. As demonstrated by the extensive list of vulnerabilities, enabling this feature significantly expands the attack surface of the hypervisor, introducing complex code paths and inter-component interactions that are prone to security flaws. Disabling 3D acceleration substantially reduces the risk of exploitation through the VMSVGA component.

Beyond this primary recommendation, the talk also shed light on the mitigations implemented by VirtualBox developers following the responsible disclosure of these vulnerabilities:

1. Changed Memory Access Model (MOB Indexing): The original design relied on direct raw pointers to MOBs, leading to significant lifecycle management problems and dangling pointers when MOBs were freed. The revised implementation now uses a MOB index instead of raw pointers. This index-based access approach effectively prevents dangling pointer issues, as an index refers to a stable entry in an array rather than a direct memory address that can become invalid.
2. Reduced GPU Buffer Usage (Decoupling State Sharing): The original implementation shared GPU buffer resources across different layers, creating tight coupling between components like the CO table and a MOB's GPU buffer. This made safe lifecycle management challenging. The new design allocates an independent buffer solely owned by the MOB CO table. This decoupling improves isolation and strengthens cross-layer security, ensuring the CO table state remains stable even if the underlying MOB is modified or freed.
3. Strengthened State Verification: Developers introduced dedicated helper functions specifically designed to validate shared state across different layers of the graphic virtualization stack. This proactive validation helps catch inconsistencies and invalid states before they can be leveraged for exploitation.
4. Strict Surface Dimension Checks: To address vulnerabilities like CVE-2025-30712 and CVE-2026-21957, the surface creation logic was enhanced with strict checks to ensure all surface dimensions (width, height, depth) are at least one. This prevents the creation of zero-size buffers, which were a root cause for subsequent buffer overflows and out-of-bounds accesses during surface operations.

These mitigations collectively represent a significant hardening effort in VirtualBox's graphic virtualization component, addressing the fundamental categories of flaws identified by the researchers.

Key Takeaways

• Graphic Virtualization is a Rich Attack Surface: The complexity of emulating GPU hardware and managing graphic resources in a hypervisor creates a fertile ground for security vulnerabilities, especially in the intermediate translation layers.
• VMSVGA's Shared Architecture Increases Impact: VirtualBox's VMSVGA and VBox SVGA, being VMware SVGA-compatible and sharing a unified DX backend, mean that vulnerabilities often affect multiple guest and host OS combinations, making them highly impactful.
• MOB Lifetime Management is Critical: Flaws related to the lifecycle of Memory Objects (MOBs), including use-after-free due to shared MOBs or inconsistent freeing, are a primary source of powerful exploitation primitives.
• Input Validation and State Synchronization are Paramount: Missing bound checks on guest-controlled sizes/indices and inconsistencies in state synchronization between frontend and backend components are recurring vulnerability patterns.
• The GPA to HVA Table is a Powerful Primitive: The ability to manipulate the Guest Physical Address to Host Virtual Address (GPA to HVA) table offers a robust mechanism for achieving arbitrary read/write on the host, crucial for reliable VM escape, particularly on Windows with its Low Fragmentation Heap.
• 3D Acceleration Poses Significant Risk: Users are strongly advised to disable 3D acceleration in VirtualBox to reduce the attack surface, as this feature directly exposes the vulnerable graphic virtualization components.

About the Speaker(s)

NiNi Chen and Wei Che Kao (Xiaobai) are esteemed Security Researchers at DEVCORE. Their work often focuses on cutting-edge vulnerability research and exploitation, with a notable history in competitive hacking events like Pwn2Own. As mentioned in the talk, they aimed to participate in the VirtualBox category of Pwn2Own, demonstrating their expertise in hypervisor exploitation. Their successful discovery and exploitation of multiple critical vulnerabilities in VirtualBox's VMSVGA component underscore their deep technical knowledge and contribute significantly to the security community's understanding of virtual machine escape techniques.