CVE-2026-101310 in bhyve
Summary
by MITRE • 10/15/2026
The HDA audio device model did not check for zero-length Buffer Descriptor List (BDL) entries when starting a stream. A zero-length entry caused an out-of-bounds read or write during DMA transfer processing. BDL fields were also subject to modification by the guest after validation.
A malicious guest can crash the bhyve process or potentially execute arbitrary code in the host userspace context running the virtual machine, subject to bhyve's Capsicum sandbox.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified involves a critical logic error within the High Definition Audio (HDA) device model emulation layer of the bhyve hypervisor. Specifically, the emulator fails to perform adequate validation checks on Buffer Descriptor List entries before initiating an audio stream transfer. In standard HDA operation, the guest operating system provides a list of buffer descriptors that define how data is transferred between host and guest memory via Direct Memory Access. The flaw arises when one or more of these descriptor entries contain zero-length buffers. Instead of rejecting such invalid configurations during the initial setup phase, the emulation logic proceeds to process them as valid DMA transfers. This oversight leads directly to out-of-bounds read or write operations because the hardware simulation attempts to access memory regions that are either unmapped or outside the intended buffer boundaries defined by the descriptor.
This technical flaw is classified under CWE-125, which denotes Out-of-Bounds Read, and potentially CWE-787, Out-of-Bounds Write, depending on the specific direction of the DMA transfer triggered by the malformed descriptors. The root cause lies in a Time-of-Check to Time-of-Use (TOCTOU) race condition or insufficient state validation. Although initial parameters may be checked upon stream start, the BDL fields remain subject to modification by the guest after this initial validation point. This allows a malicious actor running inside the virtual machine to alter descriptor lengths or addresses dynamically during execution, effectively bypassing static checks and forcing the host-side emulation code into an unsafe memory access state.
The operational impact of this vulnerability is severe, as it compromises the isolation boundary between the guest environment and the host system. A malicious guest user can exploit this flaw to crash the bhyve process by triggering a segmentation fault or general protection fault within the hypervisor's userspace context. More critically, if memory corruption occurs in a manner that allows for controlled overwrites, an attacker could potentially achieve arbitrary code execution on the host machine. This would grant the attacker full control over the virtualization infrastructure running bhyve, effectively breaking out of the guest sandbox and gaining access to all other VMs or services hosted on the same physical system.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary fix involves implementing strict validation logic within the HDA emulation code to reject any Buffer Descriptor List entries that specify zero-length buffers before DMA transfers are initiated. Additionally, developers should enforce immutability of BDL fields after initial validation or implement rigorous runtime checks for every descriptor access during stream processing. From a defense-in-depth perspective, ensuring that bhyve operates with the most restrictive Capsicum capabilities is essential to limit the blast radius if an exploit succeeds. Regular updates to the hypervisor software and strict monitoring of guest-to-host memory interactions are also recommended to detect anomalous behavior indicative of such exploitation attempts.