Zephyr RTOS EUVD-2026-65597

Exploitation requires the attacker to control the virtio device backend - specifically, to supply a crafted cap_len byte via the PCI configuration space of a virtio PCIe device. This condition is met in two concrete scenarios: (1) a bare-metal Zephyr system where a physical or PCIe passthrough virtio device is untrusted or attacker-supplied, or (2) a confidential computing deployment where the Zephyr guest is explicitly defending against a potentially malicious hypervisor acting as the virtio device backend. The vulnerability is NOT exploitable for privilege escalation in the standard case where Zephyr runs as a guest under a trusted hypervisor, because the host backend already has full control over the guest. Triggering occurs during boot-time driver initialization (device probe), not during runtime I/O operations. The CVSS Physical attack vector (AV:P) confirms no network-based exploitation path exists. No kernel-side privileges are required (PR:N) - the constraint lies entirely on the attacker's need for device-level access, not on kernel authentication.

The CVSS 3.1 vector (AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H, score 6.1) is the dominant framing signal: the Physical attack vector accurately reflects that exploitation requires controlling the virtio device backend itself, not a network path. In the most common Zephyr deployment - running as a hypervisor guest against a trusted host - the host already fully outranks the guest, so kernel stack corruption yields no practical escalation and the CVE description explicitly confirms this. The exploitable threat model is narrow: bare-metal systems with untrusted physical or PCIe passthrough hardware, or confidential computing environments. No EPSS score was supplied in the intelligence; no CISA KEV listing exists; no public exploit or POC has been identified. The integrity and availability impacts are correctly marked High because unbounded or large stack writes during kernel probe can produce code execution or a hard crash. Given the physical attack vector, the 6.1 Medium score is well-calibrated - this is not a network-exploitable mass-exploitation risk, and most Zephyr deployments in typical embedded or guest-VM postures are not exposed to the triggering condition.

An attacker who controls a virtio PCIe device - either malicious physical hardware attached to a bare-metal Zephyr system, or a compromised hypervisor in a confidential computing environment - crafts a PCI capability structure with a malformed cap_len value (either below 24 bytes to trigger unsigned underflow or above the stack buffer ceiling to write up to ~228 bytes of controlled data). When Zephyr boots and the virtio PCI driver probes the device, it reads the attacker-supplied cap_len without runtime validation and executes the copy loop, corrupting the kernel stack with device-controlled content in kernel mode. Depending on stack layout, the result is a kernel crash or potential arbitrary code execution within the Zephyr kernel context.