VirtualBox main currently vendors DXMT 0.60 under src/libs/dxmt-0.60.
In that version, ArgumentEncodingContext::allocate_cpu_heap() uses one fixed CPU encoding heap and only logs after the offset crosses the heap size:
if (cpu_buffer_offset_ >= kEncodingContextCPUHeapSize) {
ERR(cpu_buffer_offset_, " - cpu argument heap overflow, expect error.");
}
return ptr_add(cpu_buffer_, aligned);A sufficiently large encoded command chunk can therefore continue with an out-of-bounds CPU-side command allocation after the warning.
Observed failure
While stress-testing a Windows 11 Arm guest with VMSVGA 3D on a macOS/Arm host, VBox.log showed repeated cpu argument heap overflow, expect error. messages followed by Metal command-buffer failures including MTLCommandBufferErrorDomain Code=8 / kIOGPUCommandBufferCallbackErrorOutOfMemory. Guest display updates then stopped behaving correctly.
Upstream status
DXMT already fixed this in the original upstream repository:
- upstream commit: 3Shain/dxmt@9987143
- title:
feat(dxmt): dynamically grow & shrink cpu encoding buffer
- first release tag containing the commit:
v0.71
- latest release rechecked on 2026-07-16:
v0.80, which also contains the fix
VirtualBox main was rechecked at 5ac81eda707fcf3fcb49f9281401ceac0fc70f4a; src/libs/dxmt-0.60/version.h still identifies the vendored snapshot as 0.60, and the vulnerable fixed-heap implementation remains present. The report is therefore still current.
Minimal resolution
A full DXMT v0.60 -> v0.80 refresh is much larger than this one defect. The smallest practical VirtualBox-side resolution is to backport the upstream commit with its original authorship/attribution, or update the vendored DXMT snapshot to a release that contains it.
The former PR #766 was closed because it copied the exact upstream-authored change under the wrong submission/OCA basis; this issue intentionally remains open for the vendored defect itself.
VirtualBox
maincurrently vendors DXMT 0.60 undersrc/libs/dxmt-0.60.In that version,
ArgumentEncodingContext::allocate_cpu_heap()uses one fixed CPU encoding heap and only logs after the offset crosses the heap size:A sufficiently large encoded command chunk can therefore continue with an out-of-bounds CPU-side command allocation after the warning.
Observed failure
While stress-testing a Windows 11 Arm guest with VMSVGA 3D on a macOS/Arm host,
VBox.logshowed repeatedcpu argument heap overflow, expect error.messages followed by Metal command-buffer failures includingMTLCommandBufferErrorDomain Code=8/kIOGPUCommandBufferCallbackErrorOutOfMemory. Guest display updates then stopped behaving correctly.Upstream status
DXMT already fixed this in the original upstream repository:
feat(dxmt): dynamically grow & shrink cpu encoding bufferv0.71v0.80, which also contains the fixVirtualBox
mainwas rechecked at5ac81eda707fcf3fcb49f9281401ceac0fc70f4a;src/libs/dxmt-0.60/version.hstill identifies the vendored snapshot as0.60, and the vulnerable fixed-heap implementation remains present. The report is therefore still current.Minimal resolution
A full DXMT
v0.60 -> v0.80refresh is much larger than this one defect. The smallest practical VirtualBox-side resolution is to backport the upstream commit with its original authorship/attribution, or update the vendored DXMT snapshot to a release that contains it.The former PR #766 was closed because it copied the exact upstream-authored change under the wrong submission/OCA basis; this issue intentionally remains open for the vendored defect itself.