Description

The Zephyr virtio driver does not validate the descriptor-chain head id that the virtio device writes into the used ring. In virtio_isr() (drivers/virtio/virtio_common.c), the device-written vq->used->ring[idx].id is used directly as an index into vq->recv_cbs[] and vq->desc[], which are both allocated with exactly vq->num entries. recv_cbs[] holds {cb, opaque} callback entries, and the indexed callback pointer is then invoked as cbe.cb(cbe.opaque, used_len). Because the id is consumed as a 16-bit value with no bound check, a malicious or compromised virtio backend (an untrusted hypervisor, or an untrusted hardware/peer-processor virtio device on a PCI or MMIO transport) can supply an id far beyond vq->num. This causes an out-of-bounds read of a {function pointer, argument} pair from heap memory beyond recv_cbs[], after which the driver calls that attacker-shaped pointer in the guest's interrupt context. No guest privileges or user interaction are required; the backend triggers it by writing the shared used ring and raising the queue interrupt. The result is an arbitrary / attacker-influenced function-pointer call in the Zephyr guest, i.e. a control-flow-hijack primitive that can lead to code execution or, at minimum, a reliable crash. The fix rejects any used-ring id >= vq->num before indexing recv_cbs[]/desc[] or invoking the callback. This affects builds using CONFIG_VIRTIO with the PCI or MMIO transport.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-24T16:16:55.393Z",
  "pubdate": "2026-08-24T16:16:55.393Z",
  "executiveSummary": "An out-of-bounds read and control-flow hijack vulnerability exists in the Zephyr virtio driver when handling descriptor-chain head IDs written by virtio devices into the used ring. The vulnerability arises because the virtio_isr() function in drivers/virtio/virtio_common.c uses the device-provided vq->used->ring[idx].id directly as an index into the vq->recv_cbs[] and vq->desc[] arrays without validating whether the ID exceeds the allocated bounds of vq->num. An untrusted hypervisor, malicious hardware, or peer-processor virtio device operating over PCI or MMIO transport can supply an arbitrarily large 16-bit ID. This results in an out-of-bounds read of a function pointer and argument pair from heap memory, which is subsequently dereferenced and executed in the guest's interrupt context. The impact includes arbitrary code execution or a reliable system crash within the Zephyr guest. No guest privileges or user interaction are required for exploitation, as the attack is triggered entirely by the malicious virtio backend writing to the shared used ring and asserting the queue interrupt. Systems utilizing CONFIG_VIRTIO with PCI or MMIO transport are affected.",
  "technicalDetails": "The root cause of the vulnerability is a missing bounds validation check on the descriptor-chain head identifier supplied by the virtio device within the used ring. Specifically, inside virtio_isr() located at drivers/virtio/virtio_common.c, the driver processes the device-written vq->used->ring[idx].id value and consumes it directly as an array index. Both the vq->recv_cbs[] array (containing {cb, opaque} callback structures) and the vq->desc[] array are allocated to contain precisely vq->num entries. Because the driver treats the 16-bit ID as trusted without verifying if the ID is strictly less than vq->num, supplying an out-of-bounds ID forces the driver to read outside the allocated memory bounds of recv_cbs[].\nThe exploitation method relies on a compromised or malicious virtio backend, such as an untrusted hypervisor or an untrusted hardware/peer-processor virtio device interfacing via PCI or MMIO transport. The attack flow initiates when the backend crafts a malicious descriptor-chain head ID far beyond the legitimate vq->num limit and writes this value into the shared used ring. The backend then asserts the queue interrupt, forcing the Zephyr guest to execute virtio_isr(). Upon handling the interrupt, the vulnerable driver reads the attacker-controlled ID and performs an out-of-bounds read from the heap, retrieving an attacker-shaped function pointer and opaque argument pair. The driver then invokes this arbitrary pointer directly within the guest's interrupt context via cbe.cb(cbe.opaque, used_len).\nAuthentication and privilege requirements are minimal; no guest-level privileges, authentication, or user interaction are required. The attack vector depends entirely on the guest's trust relationship with the virtio transport layer and backend device. The post-exploitation impact includes a complete control-flow hijack of the Zephyr guest, enabling arbitrary code execution under the high-privilege interrupt context, or alternatively causing a denial of service via a reliable system crash."
}