## Host environment - Operating system: macOS 26.5.1 (25F80) - OS/kernel version: Darwin 25.5.0, XNU 12377.121.6, arm64 - Architecture: Apple M4 Pro (arm64) - QEMU flavor: `qemu-system-aarch64`, Hypervisor.framework (`kern.hv_support=1`) - QEMU version: 11.0.90, upstream `master` commit `bd6079a7a1d14de0918a7715ef6db85dc32de3bb` (fetched 2026-07-21) - QEMU binary SHA-256: `10f5a31b8ce5096ac09e7f6db065ed1e046c60064abbacf4fc2c73ccd3f5e974` - QEMU command line: ```sh QEMU_BIN=/path/to/qemu-system-aarch64 \ KERNEL_IMAGE=/path/to/vmlinuz-virt \ INITRD_IMAGE=/path/to/initramfs-nvme-hvf \ ./run_nvme_hvf.sh mmio attack1 ``` The attached launcher contains the complete command line. The relevant topology is an `e1000` foreign-MMIO target plus an NVMe controller with a fast raw namespace 1 and delayed `null-co` namespace 2. ## Emulated/Virtualized environment - Operating system: Alpine Linux 3.24.1 minirootfs - OS/kernel version: Linux 6.18.35 - Architecture: aarch64 ## Description of problem A guest-controlled NVMe read can be parked in `dma_blk_io()` when a PRP points into foreign PCI MMIO and exhausts the bounce-buffer budget. The parked DMA is registered as an address-space map client but is not an in-flight block request visible to `blk_drain()`. If the guest clears `CC.EN` while request A holds the bounce budget and request B is parked, `nvme_ctrl_reset()` drains namespace 1 before namespace 2. Draining namespace 2 completes A, releases the bounce budget, and revives B after namespace 1 has already been drained. Reset then calls `nvme_free_sq()` and frees `sq->io_req` while B still holds a pointer into that array. B later completes through the freed `NvmeRequest`. On that upstream commit this produced a guest-triggered `SIGSEGV` in `nvme_rw_cb()` in 2/2 macOS HVF runs. The RAM-only control changed only the PRP destinations, produced no `dma_map_wait`, and survived in 2/2 runs. ### Trigger and privilege boundary The crash path is driven entirely by a privileged guest process through an unbound NVMe PCI function. It requires guest root or equivalent PCI device-programming authority because this PoC maps PCI resources and reads `/proc/self/pagemap`. It requires no QMP command, device removal, or host-side action. ### Security impact At minimum, an authorized guest can crash the QEMU process, crossing the VM boundary as a host-process denial of service. A separate bounded host-assisted validation demonstrated a control-flow consequence under HVF. A Darwin interposer intercepted the exact `g_free`, preserved the stale request, and deliberately returned the same 656-byte chunk for a guest-controlled 41-range DSM allocation. Under that injected allocator/address condition, the stale QTAILQ removal replaced a recreated SQ's `bh`; the next guest SQ doorbell invoked a fixed callback that only wrote one line to stderr and called `_exit(86)`. This succeeded in 2/2 attack runs. The matched no-trigger control performed the same injected allocation delivery and stale completion but omitted the final doorbell, invoked no callback, and left QEMU alive in 2/2 runs. The validation harness supplies ASLR-dependent host addresses, the stale request snapshot, and deterministic same-address allocation delivery. It demonstrates a control-flow consequence once those prerequisites are injected; it does **not** demonstrate natural allocator reuse or standalone guest-only RCE. The directly established guest-only impact is a repeatable QEMU process crash. ## Steps to reproduce 1. Build the current QEMU master for `aarch64-softmmu` with HVF, debug symbols, and the trace events used by the attached launcher. 2. Build the static aarch64 `nvmepoke` from `nvmepoke_hvf.c` and place it at `/nvmepoke` in a small Linux initramfs, as described in `poc.tar.gz/README.md`. 3. Supply the kernel/initramfs paths, then run: ```sh QEMU_BIN=/path/to/qemu-system-aarch64 \ KERNEL_IMAGE=/path/to/vmlinuz-virt \ INITRD_IMAGE=/path/to/initramfs-nvme-hvf \ ./run_nvme_hvf.sh mmio attack1 ``` 4. Observe one `dma_map_wait`, followed by QEMU `SIGSEGV`/exit 139. The symbolized crash stack begins at `nvme_rw_cb()` and continues through `dma_complete()`, `dma_blk_cb()`, and `reschedule_dma()`. 5. Run the negative control: ```sh QEMU_BIN=/path/to/qemu-system-aarch64 \ KERNEL_IMAGE=/path/to/vmlinuz-virt \ INITRD_IMAGE=/path/to/initramfs-nvme-hvf \ ./run_nvme_hvf.sh ram control1 ``` It should contain no `dma_map_wait`, complete both NVMe requests, and remain alive until harness cleanup. ## Additional information ### Root-cause confirmation - `system/dma-helpers.c:169-173`: when no mapping is available, `dma_blk_cb()` sets `dbs->bh`, registers an address-space map client, and returns before creating an underlying block AIO request. - `hw/nvme/ns.c:694-697`: `nvme_ns_drain()` only calls `blk_drain(ns->blkconf.blk)`. - `hw/nvme/ctrl.c:8009-8028`: `nvme_ctrl_reset()` drains namespaces in ascending NSID order, then calls `nvme_free_sq()`. - `hw/nvme/ctrl.c:4825-4837`: `nvme_free_sq()` frees `sq->io_req`. - The revived callback reaches `nvme_rw_cb()` with the freed request and later `nvme_enqueue_req_completion()`, which uses stale SQ/CQ/list fields. The two independent crash reports resolved the same fault: ```text EXC_BAD_ACCESS / SIGSEGV at 0x98 nvme_rw_cb hw/nvme/ctrl.c:2222 dma_complete system/dma-helpers.c:107 dma_blk_cb system/dma-helpers.c:129 reschedule_dma system/dma-helpers.c:85 ``` The MMIO/RAM pair is also a toggle proof: redirecting only the data PRPs from foreign PCI MMIO to guest RAM changes `dma_map_wait` from 1 to 0 and removes the crash in both matched controls. ### Related public reports checked QEMU issue #782 / CVE-2021-3929 is a synchronous DMA reentrancy reset from `nvme_tx()`; this report instead parks an asynchronous block DMA as an address-space map client that is invisible to the later per-namespace `blk_drain()`. Exact-string searches of the public QEMU issue tracker and qemu-devel/Patchew on 2026-07-21 found no public NVMe report matching this map-wait/reset lifetime sequence. Open IDE issues #3465 and #3957 reach `dma_blk_cb()` through different IDE request/SG-list mechanisms. ### Attachments - [poc.tar.gz](/uploads/9d9af1dda8ca5037371eb39b444551cf/poc.tar.gz) - [qemu.log](/uploads/bb652f6737b6ee1fa631f668199c1e1f/qemu.log) The PoC archive contains the guest trigger, launchers, and source for the exit-only host-assisted validation. The log contains the minimized crash/control/assisted-result evidence. ### AI disclosure This report and the PoC were prepared with assistance from OpenAI Codex. All security claims above were validated against current QEMU source and the attached retained logs.