CVE-2026-13216: Out-of-bounds stack write in Zephyr virtio PCI driver from unvalidated device-supplied capability length

Published Aug 25, 2026
·
Updated

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

1 affected component
Zephyr Project Zephyr

Event History

Aug 25, 2026
CVE Published
via MITRE·04:05 PM
Data Sourced
via MITRE·04:05 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·05:17 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

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.

2

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.

3

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203