DPDK vhost-crypto EUVD-2026-101510

Exploitation requires (1) the DPDK vhost-crypto backend to be enabled and exposed to a guest via a virtio-crypto device - this is not a default configuration and is specific to NFV/crypto-offload deployments; and (2) the attacker to already control a guest VM authorized to issue vhost-crypto requests (PR:L). The attacker triggers the bug by supplying an avail-ring descriptor index that the host uses without bounds validation. Limiting factors: the attack vector is local to the virtualization host (AV:L) - it cannot be reached directly from the network; it requires an existing foothold in a guest; and it depends on the vhost-crypto feature being active, so hosts that do not use crypto offload are not exposed. Realistic impact is host datapath denial of service (A:H), not data disclosure or modification per the vendor scoring.

This is a moderate-severity guest-to-host escape in DPDK's vhost-crypto backend. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H, base 6.5) tells a consistent story: the attack originates from a local context (AV:L) - specifically a malicious or compromised guest VM that already has low-level access to its own virtio-crypto device (PR:L) - requires no user interaction, has low complexity, and crosses a scope boundary (S:C) from guest into the host vhost-crypto process. Impact is availability-only (A:H) with no stated confidentiality or integrity effect, meaning the vendor assessed the realistic outcome as a host-side crash/DoS of the datapath rather than code execution. There is tension worth flagging: the underlying weakness is CWE-787 (out-of-bounds WRITE), which frequently carries integrity/RCE potential, yet Red Hat scored C:N/I:N - this suggests the OOB write is constrained (e.g., limited offset/controlled-crash) rather than a freely controllable write primitive; treat the A:H-only scoring as the vendor's view and do not assume RCE. There is no EPSS score, no CISA KEV listing, and no public exploit in the provided data, so exploitation status is 'no public exploit identified at time of analysis.' Net: this is a real but second-tier priority - it matters most for multi-tenant NFV/telco hosts running OVS-DPDK with vhost-crypto enabled, and far less for environments that do not expose that feature to untrusted guests.

A tenant with control of a guest VM on a shared DPDK host crafts a malicious virtio-crypto avail-ring entry containing an out-of-range descriptor index. Because the host vhost-crypto backend uses that index without bounds checking, processing the request triggers an out-of-bounds write in the host process, crashing or corrupting the DPDK datapath and denying service to co-located tenants. No public proof-of-concept is identified in the available data.