Digging into CVE-2025-62592 in Oracle VirtualBox for macOS
September 9, 2024 saw a release of VirtualBox 7.1.0 which supports ARM processors for macOS. This version features the QemuRamFB virtual graphics adapter (besides the commonly used VBoxSVGA and VMSVGA). QemuRamFB had been used before as one of the virtual graphics adapters available in VBoxBFE, a utility designed to manage virtual machines for VirtualBox. However, VBoxBFE was declared deprecated in 2016 with terminated support, which equally applied to QemuRamFB. It was not until version 7.1.0 that Oracle decided to bring back the long-forgotten graphics adapter in the ARM version for macOS.
In 2025, our vulnerability researchers Pavel Blinnikov and Andrey Chizhov analyzed QemuRamFB to find a vulnerability that enables unlimited memory reads beyond the array. This article looks into how the vulnerability was detected and how it manifests itself. We also explore how to debug macOS applications and develop respective exploits.
A macOS process can only be debugged with specific permissions. There are two ways to enable the debugging for an executable file:
- Patching the entitlements (upon completion, the application needs resigning).
- Disabling the SIP (System Integrity Protection) through Recovery Mode.
The first one modifies the executable and hence cannot be used due to the VirtualBox hardening specifics: the kernel driver verifies the signature of the application it interacts with. As the modified signature is no longer correct, VirtualBox won’t be able to function. We are left only with the second option which requires a physical Mac device rather than a cloud.
Disabling the SIP requires entering Recovery Mode. To do this, we turn off the Mac and then hold down Command (⌘) + R. Finally, we open the terminal and enter the command: csrutil disable
The next issue we faced was an unintuitive LLDB. Once you are used to GDB, switching to LLDB is a real test of your patience. Fortunately, the pwndbg debugger extension (2025.01.20) now supports LLDB. This is how we can use a familiar tool when debugging Mach-O.
Let us explore the code for QemuRamFB. This device registers the MMIO region along with its read and write handler:
The qemuFwCfgItemSelect function allows us to select one of the configuration items:
Once the item is selected, communication can continue via the qemuFwCfgMmioRead handler. We can read the data from the selected item with the pfnRead functions. For example, the qemuFwCfgR3ReadSimple function would be called for QEMU_FW_CFG_ITEM_SIGNATURE.
The function code:
Thus, qemuFwCfgR3ReadSimple simply copies the data from some pThis->u.ab array in response to a read from the MMIO region. the array size is specified in the pfnSetup function and is set to 4 for QEMU_FW_CFG_ITEM_SIGNATURE.
This is how qemuFwCfgR3ReadSimple is called by the MMIO handler:
After a successful read, the cbRead value equal to cb is deducted from the cbCfgItemLeft variable. the value is determined by the qemuFwCfgR3ReadSimple function. Note that cb is the size of a read from the MMIO region. In this case, it cannot exceed 8 but can equal 1, 2, or 4.
This brings us to the core of the vulnerability: there are no checks at the time of reading to verify that cb is not greater than cbCfgItemLeft. Besides the standard overflow (4 < 8), sequential reads are possible, for example: 4 − 1 = 3, 3 − 4 < 0. We can thereby deduct a greater value from cbCfgItemLeft than that of the variable, and trigger an integer underflow. As a result, offCfgItemNext virtually becomes an arbitrary value enabling unlimited reads beyond the pThis->u.ab array. This triggers an ASLR (address space layout randomization) leak and opens up opportunities for VirtualBox exploitation (e.g., through CVE-2025-61760 uncovered by our team, also patched on October 21, 2025).
We opted for Ubuntu Server for ARM as a guest OS. Exploitation requires reading and writing into guest physical memory which is only possible at the kernel level. While chipsec is commonly used for such purposes, we had earlier crafted a small driver for working with physical memory. Dubbed phyzone and posted to GitHub, the driver enables communication with physical memory through ioctl calls.
Once phyzone is compiled and installed, we can get started on creating the exploit. But first, we need to obtain the base address of the QemuRamFB MMIO region.
To do this, we run the following command:
Perfect, our base address is 0xffddf000.
The exploit will look like that:
When run, it will output the following:
the only thing left is to check the output for real addresses of the VirtualBox process.
To this end, let us use pwndbg-lldb:
Addresses 0×114810280 and 0×16fbe3000 are adjacent to those of the VirtualBoxVM executable and DLLs. Hence, with these addresses at hand, you can calculate the base values for all process executables. Accordingly, this opens up broad opportunities for further exploitation.
We spotted CVE-2025-62592 when reading the patches for VirtualBox 7.1.6: without any fuzzing and static analysis, just by staring really closely. We believe that the vulnerability sprang to life with Oracle pulling its good old virtual device straight out of 2016. Hidden from researchers’ scrutiny for years, the device was repurposed as one of the graphics adapters available in the macOS version of VirtualBox. After leaping over nearly a decade of application security evolution, QemuRamFB landed in 2025 as deprecated as nine years ago.