CVE-2026-13216

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 cap_len 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), capstruct_size] before any arithmetic or copy.