Vulnerability · Published Aug 25, 2026 · Assigned by zephyr

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

Medium 6.1

In plain English

A medium-severity out-of-bounds write in zephyr from zephyrproject. There are no confirmed reports of exploitation so far. The chance it is exploited in the next 30 days is estimated at 0.3% (higher than 17% of all known vulnerabilities).

Severity (CVSS 3.1)6.1Medium
Exploit odds (30 days)0.3%top 82.6% of all CVEs
Exploited in the wildNo reportsCISA SSVC: none
Attack toolingNoneno public tooling known

Official description

The virtio PCI driver (drivers/virtio/virtio_pci.c) parses a device's PCI capability list during driver initialization. In virtio_pci_read_cap() the device-supplied capability length byte cap_len (read from PCI config space via pcie_conf_read()) was only checked with assert(tmp.cap_len == cap_struct_size). That assert resolves to __ASSERT_NO_MSG(), gated by CONFIG_ASSERT, 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 cap_len below the 24-byte base struct virtio_pci_cap underflows the unsigned extra_data_words count to a near-SIZE_MAX 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 cap_len outside [sizeof(struct virtio_pci_cap), cap_struct_size] before any arithmetic or copy.

Affected products (as reported)

VendorProductVersions
zephyrproject zephyr 4.2.0 – before 4.3.24.4.0 – before 4.4.2

Weakness: CWE-787 · Vector: CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

References