# QEMU NVMe Copy DIF/PRACT Heap Out-of-Bounds Write — Guest-to-Host Escape [00_REPORT.md](/uploads/0e9735fd95aa9e983d04a3b5a0f15b3b/00_REPORT.md) [01_guest_exploit.c](/uploads/1955818d0216997f59b48728b7d459e0/01_guest_exploit.c) [02_guest_exploit.bin](/uploads/92d0396c24d2c7cf500f4cf50c5062c1/02_guest_exploit.bin) **Submitter:** independent security researcher **Classification:** CWE-787 (Out-of-bounds Write) / CWE-125 (Out-of-bounds Read) — combined with an info-leak, leading to remote code execution on the QEMU host process. **Severity:** Critical (CVSS estimate 8.8–9.8 depending on environment; see Impact). Proof-of-concept achieves full host command execution. **Affected:** QEMU with the NVMe emulated controller (`-device nvme`), Copy command (opcode `0x19`) with cross-namespace DIF/PRACT. **Tested and exploited on v11.1.0-rc3** (commit `3e3ccab106f879b1512f8e0d51a827dd4de30e22`). The vulnerable logic is present in all releases carrying the NVMe Copy + DIF implementation; exact boundaries per release need confirmation (see "Affected versions"). **Not default:** does NOT trigger on a default QEMU machine; requires a specific NVMe configuration (see "Triggering configuration"). **Reported By: Feng Xue and XGPT of ThreatBook** --- ## Summary QEMU's NVMe **COPY** command handler allocates a single bounce buffer sized from the **source** namespace geometry, but then computes the **destination** metadata pointer inside that buffer using the **destination** namespace geometry. When the source logical block size is smaller than the destination's, the destination-metadata window lands far **past the end of the allocation**. QEMU then: 1. **writes** generated DIF (protection-information) tuples into that out-of-bounds region (`hw/nvme/ctrl.c` `nvme_copy_in_completed_cb`, `hw/nvme/dif.c` `nvme_dif_pract_generate_dif*`), and 2. **reads** that region back to disk as destination metadata (`hw/nvme/ctrl.c` `nvme_copy_out_cb`), then the guest can read it back via a normal READ with a metadata buffer. The result is two primitives from one bug: - **OOB read → info leak** of live QEMU host heap: E1000State pointer, PIE (QEMU binary) pointer, and libc pointer. This defeats ASLR entirely **in-band, from the guest**. - **OOB write → controlled heap corruption**: the 8 bytes per leaked cell are fully controlled by the guest (guard = CRC16 of controlled source data, apptag = cdw15, reftag = cdw14+j), landing one cell on a function pointer of the e1000 device state → control-flow hijack. The full chain is **guest-only, single boot, ASLR fully on, zero host participation** (host only launches QEMU and reads the proof files afterwards). It achieves **arbitrary host command execution** as the QEMU process user. --- ## Triggering configuration (not default) The bug is reachable only with an NVMe device exposing **two namespaces on the same controller** with mismatched geometry + DIF: ``` -device nvme,id=nvme0,serial=deadbeef,max_ioqpairs=4,ioeventfd=off \ -device nvme-ns,drive=da,nsid=1,logical_block_size=512,physical_block_size=512,ms=0,pi=0,share-rw=on \ -device nvme-ns,drive=db,nsid=2,logical_block_size=1024,physical_block_size=1024,ms=8,pi=1,pif=0,share-rw=on ``` Required conditions: - **ns1**: `logical_block_size=512`, `ms=0`, `pi=0` (source, no metadata). - **ns2**: `logical_block_size=1024`, `ms=8`, `pi=1`, `pif=0` (destination, DIF type 1, 8-byte tuples). - Cross-namespace **Copy** with `format=2` (requires **Host Behavior Support** feature, set via Set Features `fid 0x16`, byte 4 = `0x04`, enabling `cdfe` bit 2 — see `hw/nvme/ctrl.c` `nvme_copy`, format gate). - `control = 0x2000` in cdw12 → `prinfow = NVME_PRINFO_PRACT` (PRACT on). A default `qemu-system-x86_64` VM (single disk, no DIF) does not trigger it. --- ## Root cause ### The bounce buffer is sized from the source namespace `hw/nvme/ctrl.c` `nvme_do_copy` (\~line 3335): ```c g_free(iocb->bounce); assert(g_size_checked_mul(&blen, le16_to_cpu(sns->id_ns.mssrl), sns->lbasz + MAX(sns->lbaf.ms, dns->lbaf.ms))); iocb->bounce = g_malloc(blen); ``` With `mssrl` default 128 (`hw/nvme/ns.c`), ns1→ns2: `blen = 128 * (512 + 8) = 66560` bytes. ### The destination metadata pointer is computed with the destination geometry `hw/nvme/ctrl.c` `nvme_copy_in_completed_cb` (\~line 3060): ```c mlen = nvme_m2b(dns, nlb); /* = 8*nlb */ mbounce = iocb->bounce + nvme_l2b(dns, nlb); /* = bounce + 1024*nlb */ if (prinfow & NVME_PRINFO_PRACT) { nvme_dif_pract_generate_dif(dns, iocb->bounce, len, mbounce, mlen, apptag, &iocb->reftag); /* OOB write */ } ``` `len = nvme_l2b(sns, nlb) = 512*nlb` (source geometry), but `mbounce` advances by `1024*nlb` (destination geometry). For `nlb=99`: `mbounce = bounce + 101376`, which is **34816 bytes past the 66560-byte allocation**. ### The generation loop iterates over source length with destination stride `hw/nvme/dif.c` `nvme_dif_pract_generate_dif_crc16` (\~line 63): ```c for (; buf < end; buf += ns->lbasz, mbuf += ns->lbaf.ms) { /* ns = destination */ ... crc = crc16_t10dif(0x0, buf, ns->lbasz); /* buf advances by 1024 */ dif->g16.guard = cpu_to_be16(crc); dif->g16.apptag = cpu_to_be16(apptag); dif->g16.reftag = cpu_to_be32(*reftag); (*reftag)++; } ``` `end = buf + len` (source length), but `buf += 1024` (destination stride): only `ceil(512*nlb/1024) = ceil(nlb/2)` cells are **generated**; the remaining cells in the window are **stale heap left unmodified**. For nlb=99 → 50 generated cells (0..49), cells 50..98 stale heap → both leak (read) and can be targeted. ### OOB window summary | copy | window start (past 66560 B buffer end) | width | |------|----------------------------------------|-------| | dslba=1000, nlb=98 (leak A) | bounce+100352 (−33792 B past end) | 784 B | | dslba=2000, nlb=97 (leak B) | bounce+99328 (−32768 B past end) | 776 B | | dslba=0, nlb=99 (exploit) | bounce+101376 (−34816 B past end) | 792 B | The OOB write lands one fully-controlled DIF cell (j=11 for the tested build) on `E+0x518`, the e1000 `PCIDevice.config_write` function pointer. --- ## Exploit chain (PoC) All in-guest, single boot, ASLR on (`randomize_va_space=2`), **zero host participation**: 1. **Leak copies**: two cross-namespace Copy commands (`ns1→ns2`, `dst_nsid=2`) with `dslba=1000,nlb=98` and `dslba=2000,nlb=97`, `cdw12=FMT2_PRACT_CDW12`, `cdw14=cdw15=0`. The OOB metadata window dumps live host heap (E1000State self-refs `E`, `PIE+0x69b560`, `libc+0x203b60`) to the destination disk metadata region. 2. **In-guest read-back**: the guest issues NVMe READs on ns2 with a metadata buffer and `prinfo=0`. QEMU's `nvme_dif_rw_check_cb` passes `nvme_check_prinfo` (prinfo=0), skips all PRCHK checks, and `nvme_bounce_mdata` copies the **raw** leaked bytes back to the guest. 3. **In-guest parse**: E = the value appearing ≥2× among heap-range cells (E1000State self-references); PIE = candidate with `PIE < E < PIE+0x50000000`; libc = `0x7f…`-range candidate with `(v & 0xfff)==0xb60` low-bits signature. 4. **Controlled write**: guest builds a 1024-byte source block whose `crc16_t10dif` equals `bswap16(g_free@plt & 0xffff)` (2-byte brute force preimage, \<1s), writes it to ns1 sectors 22-23, then issues copy `dslba=0,nlb=99` with `cdw14 = bswap32(g_free@plt>>32) - 11`, `cdw15 = bswap16((g_free@plt>>16)&0xffff)`. Cell j=11 becomes `g_free@plt` at `E+0x518`. 5. **Trigger free**: an `outl` config-space write to the e1000 invokes the overwritten `config_write` = `g_free@plt` with the device pointer → `g_free(E)`. 6. **Reclaim**: a WRITE to ns2, `nlb=384`, `control=PRACT` allocates `g_malloc(393216)` which reuses the freed E chunk; the guest's 393216 bytes (fake image at `IMG_OFF=0x50`) land on E. The fake image has `fops` → `system`, CMD string at `E+0x200`. 7. **Fire**: an `outl` to the e1000 IO BAR dereferences the reclaimed state → calls `system(E+0x200)` → **host command execution**. ### Provenance of constants The offsets `LIBC_OFF_SYSTEM=0x58750`, `LIBC_OFF_LEAK=0x203b60`, `PIE_OFF_GFREE_PLT=0x33e050`, `PIE_OFF_MR_DESTRUCTOR=0x69b560`, `E+0x518`, `IMG_OFF=0x50`, `RECLAIM_NLB=384` are **\[calibrated\]** against the tested QEMU build and host glibc; they are build-dependent, not portable to other builds without recalibration (the bug itself is build-independent). --- ## Proof of concept (PoC) Files (also attached): | File | Purpose | |------|---------| | `CrossOver_guest_full_v11.c` | Guest exploit source (single boot, guest-only, ASLR on) | | `CrossOver_guest_full_v11.bin` | Compiled static binary (710672 B) | | `CrossOver_verify_v11_clean.sh` | Reproduction harness: preps disks, launches QEMU, checks proof files | | `CrossOver_expdev.md` | Full technical write-up with per-claim source cross-references | **PoC payload** (non-destructive, proof-of-command-execution): ``` /bin/sh -c 'id > /tmp/escape_pwned; echo PWNED > /tmp/escape_out' ``` **Verification result** (remote VM, Ubuntu, ASLR on, non-ASAN QEMU v11.1.0-rc3): - `4/4` development runs + `3/3` independent clean runs → `ESCAPED`. - `/tmp/escape_out` = `PWNED`; `/tmp/escape_pwned` = `uid=1000(ubuntu) gid=1000(ubuntu) …` (executed on the host, as the QEMU process user). - Expected post-RCE SIGSEGV of QEMU after `system()` (benign; heap around the reclaimed device state is intentionally inconsistent). A PoC was also verified against the **ASAN build** (heap out-of-bounds write reported by ASAN on the copy path). --- ## Impact - **Guest → host escape**: full RCE in the QEMU process, as the user running QEMU. In multi-tenant / VMM-cloud configurations this is a VM escape. - **Requires**: an attacker who can run a guest that reaches an NVMe Copy with the DIF/PRACT cross-namespace geometry (i.e., a guest with the right NVMe device config), plus knowledge of the target QEMU build + glibc (offsets are build-calibrated). - **Not default**: a default `-machine pc` with a single non-DIF disk does not trigger. - **Defense in depth that does NOT stop it**: ASLR (leaked in-band), non-root QEMU (executes as the QEMU user), TCG (no KVM needed — PoC uses `-accel tcg`). --- ## Suggested fix The root cause is a geometry mismatch: the bounce buffer and the metadata window are indexed with inconsistent namespace geometry. Minimum fixes (any one): 1. **Size the destination metadata window correctly**: allocate the bounce buffer to accommodate the **destination** metadata based on destination geometry, or reject/validate the copy when `sns->lbasz != dns->lbasz` (or when destination metadata window exceeds `blen`). 2. **Bounds-check `mbounce`/`mlen` against `blen`** in `nvme_copy_in_completed_cb` before `nvme_dif_pract_generate_dif`/`nvme_dif_check`, mirroring the `assert(len <= blen)` already present for data. 3. **Cap `nlb` by the destination-consistent size** or enforce same-format (DIF) compatibility between source and destination namespaces for cross-namespace Copy with PRACT. The PoC depends on the OOB metadata window reaching at least \~35 KB past the allocation; a correct size/bounds check eliminates both the leak and the write. --- ## Affected versions - **Confirmed vulnerable:** `v11.1.0-rc3` (commit `3e3ccab106f879b1512f8e0d51a827dd4de30e22`) — exploited. - **Likely affected:** all releases where `nvme_copy_*` computes `mbounce` with destination geometry and sizes the bounce from source geometry (the same structural pattern). The Copy command and DIF handling have been present across recent NVMe support; **exact first/last affected boundaries need maintainer confirmation**. - **Not affected:** configs without the above NVMe device setup. --- ## Contact & responsible disclosure - Submitted to **`qemu-security@nongnu.org`** (QEMU's designated security contact, listed in MAINTAINERS). - No public disclosure prior to maintainer acknowledgement and a coordinated embargo. - PoC is non-destructive (writes two proof files in /tmp); full details and repro steps in the attached `CrossOver_expdev.md`. --- ## Embargo & coordinated disclosure This report and all attached material are provided **in confidence** to the QEMU security team for the purpose of fixing this vulnerability before it becomes public knowledge. - **Response deadline**: we ask for an **acknowledgement of receipt within 14 days** of this report (by **2026-08-25**). If we receive no reply by then, we will send one follow-up notice, and if there is still no response we reserve the right to proceed with public disclosure. We understand that a full fix may take longer than 14 days and will grant reasonable additional time once the maintainers are engaged. - **Requested embargo period (after acknowledgement)**: treat this as embargoed until a **mutually agreed coordinated-disclosure date**. As a default we suggest the common convention of **\~14 days after an embargoed fix is publicly released**; if you prefer a longer or shorter window, or have a specific date in mind, please state it in the reply and we will follow it. We are happy to align with the QEMU security process's standard timeline. - **No unilateral disclosure**: while the coordinated-disclosure process is active (i.e. after acknowledgement), we will not publish any technical detail in this report until we mutually agree on a disclosure date, and we will not publish a working PoC or reproducer before the fix has been released and downstream distributions have had time to update. - **We commit** to the QEMU coordinated-disclosure process: no unilateral disclosure except the 14-day response-deadline fallback above, and we will coordinate the advisory, CVE description, and publication date with you. - **We are available** to: provide additional reproducer or build details, help validate any proposed fix against the attached PoC, or jointly draft the CVE advisory. Contact for the researcher: reply to the submitting email address. Plaintext reply is acceptable; if you prefer PGP, we can exchange keys. --- _Prepared 2026-08-11. All source citations refer to `hw/nvme/ctrl.c`, `hw/nvme/dif.c`, `hw/nvme/ns.c` in the tested tree. This report is embargoed per the section above._