vhost-crypto TOCTOU out-of-bounds write

https://bugs.dpdk.org/show_bug.cgi?id=2001

Bug ID: 2001
Summary: vhost-crypto TOCTOU out-of-bounds write
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: vhost/virtio
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Group: security

Report date: 2026-03-11
Reported by: Adiel Sol <[email protected]>

Hi DPDK Security Team,
I would like to report a security vulnerability in DPDK vhost-crypto. Summary
The vhost-crypto code has a time-of-check to time-of-use (TOCTOU) bug in the path that finalizes a crypto request. When the host finishes a request, it writes the result into the virtio used ring. The descriptor index for that write is read again from the guest-writable available ring at finalization time, and the code does not check that this index is within the virtqueue size. Between the initial fetch and finalization, a malicious guest can change that value in shared memory. The host then uses the guest-controlled value as an index and writes to vq->used->ring[desc_idx], causing an out-of-bounds write (up to about 524 KB past the used ring when the index is 0xFFFF). The used ring has only 256 entries. A malicious guest with a vhost-crypto device can trigger this to corrupt host DPDK process memory. In practice this can lead to host crash or arbitrary code execution on the host (guest escape). Because the DPDK process usually runs as root, a successful exploit can mean full control of the host.
Affected Component

* lib/vhost/vhost_crypto.c (finalize path; function
vhost_crypto_finalize_one_request() and the code that re-reads desc_idx from vq->avail->ring[used_idx] and writes to vq->used->ring[desc_idx] without validation).
* Versions: DPDK 26.03.0-rc1 and earlier versions that include the
vhost-crypto finalize path. Any product that uses DPDK vhost-crypto in the same way may be affected.

Root Cause
At fetch time the host correctly masks used_idx and reads desc_idx from the available ring. At finalize time the code reads desc_idx again from vq->avail->ring[used_idx] (guest-writable shared memory) and then writes vq->used->ring[desc_idx].id and .len with no check that desc_idx < vq->size. The available ring is writable by the guest at any time. Between fetch and finalize the host is busy with the crypto operation (enqueue to cryptodev, wait for completion), so the guest has a long race window (microseconds to milliseconds) to overwrite vq->avail->ring[used_idx] with any 16-bit value (e.g. 0xFFFF). The host then uses that value as an index. The used ring has only vq->size entries (e.g. 256), so indexing with 0xFFFF causes a write at 65535 * 8 bytes past the start of the ring, i.e. an out-of-bounds write into host process memory. The attacker controls the write offset and partially the written data (the .id value comes from another guest-controlled slot; the .len from the request). So the bug is a TOCTOU with missing input validation (CWE-367, CWE-787, CWE-20).
Impact

* CVSS 3.1: High (e.g. AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H or similar;
guest-to-host escape, host RCE in scope).
* CWE-787 (Out-of-bounds Write), CWE-367 (TOCTOU Race Condition), CWE-20
(Improper Input Validation).
* A malicious guest VM with a vhost-crypto device can trigger the overflow
by submitting a valid crypto request and then overwriting the available ring slot during the crypto operation. No special guest setup is required; the race window is the duration of the crypto operation.
* Successful exploitation can lead to memory corruption in the host DPDK
process, then to arbitrary code execution on the host (guest escape) and full compromise of the host (backdoors, pivot, etc.), often as root.

Proof of Concept

1. We provide two proof-of-concept programs that simulate the vulnerable
pattern (shared virtqueue, host thread, guest thread). They do not run against a full DPDK build but demonstrate the TOCTOU and the resulting out-of-bounds access and control-flow hijack.
2.
OOB detection: In the PoC directory, run ./run_poc.sh. The code is built with AddressSanitizer. The host thread fetches a request (reads desc_idx = 0), then the guest thread overwrites the available ring slot to 0xFFFF. When the host thread finalizes, it re-reads desc_idx and writes to used_ring[0xFFFF]. AddressSanitizer reports a SEGV (or heap-buffer-overflow) in the host thread at the finalize line, proving the out-of-bounds access.
3.
Control-flow hijack (guest escape / RCE): Run make run-rce in the same directory. The layout is set so that used_ring[256] (one past the end) overwrites a function pointer. The guest sets desc_idx = 256 and the two 32-bit halves of the payload address. When the host calls the completion callback after finalize, it runs the attacker-supplied function. The program prints "PWNED: guest escape - host is now running attacker code!" This shows that the same primitive can redirect execution and is sufficient to demonstrate the guest-escape / RCE impact in concept.
4.
The PoC sources, build instructions, and a captured ASan run are in the disclosure package (e.g. poc-dpdk-vhost-crypto-toctou/ with vhost_crypto_toctou_poc.c, vhost_toctou_rce_poc.c, run_poc.sh, PROOF-OUTPUT.txt).

Credit Request
We kindly request that the following researchers be credited for this discovery:
Adiel Sol, Arad Inbar, Erez Cohen, Nir Somech, Ben Grinberg, Daniel Lubel – DREAM Security Research Team

You are receiving this mail because:
You are the assignee for the bug.