CVE-2026-13216: Out-of-bounds stack write in Zephyr virtio PCI driver from unvalidated device-supplied capability length
The virtio PCI driver (drivers/virtio/virtiopci.c) parses a device's PCI capability list during driver initialization. In virtiopcireadcap() the device-supplied capability length byte caplen (read from PCI config space via pcieconfread()) was only checked with assert(tmp.caplen == capstructsize). That assert resolves to ASSERTNOMSG(), gated by CONFIGASSERT, which defaults off in production builds, so the value reached the copy logic completely unvalidated.
The length then drives a loop that copies extra capability dwords into a fixed-size stack buffer supplied by the caller. A caplen below the 24-byte base struct virtiopcicap underflows the unsigned extradatawords count to a near-SIZEMAX value, producing an effectively unbounded stack write; a caplen above the caller's buffer (up to 255) writes up to roughly 228 bytes of device-controlled data past the buffer. Both are out-of-bounds writes of attacker-controlled content executed in kernel mode during boot-time device probe.
The input originates from the virtio device. In the common deployment where Zephyr runs as a guest under a hypervisor, the device backend is the host, which already fully outranks the guest, so the bug yields no privilege escalation. The exploitable case is a virtio device that is untrusted relative to the Zephyr kernel — an untrusted or physical/passthrough virtio PCIe device on a bare-metal system, or a confidential-computing posture where the guest must defend against the host — where a malicious device can corrupt the kernel stack and potentially achieve code execution or a crash.
The fix replaces the compiled-out assert with a runtime range check rejecting caplen outside [sizeof(struct virtiopcicap), capstructsize] before any arithmetic or copy.
Affected Software
Event History
Frequently Asked Questions
Are production builds affected even though the capability length is asserted?
Yes. The check uses __ASSERT_NO_MSG() and is gated by CONFIG_ASSERT, which defaults to off in production builds. In those builds, device-supplied capability lengths reach the copy logic without validation.
What attacker control is required to trigger the overwrite?
An attacker needs control of the virtio device's PCI capability data, specifically the capability length and copied capability contents, during driver initialization. The writes occur in kernel mode while the device is probed at boot.
Which deployments are most realistically exposed?
Zephyr guests using virtio PCI are exposed to input from their virtio device. In the common hypervisor deployment, the device backend is controlled by the host, which already fully outranks the guest.