## Summary When the QEMU NVMe controller is reset while a cross-namespace Copy command is being processed asynchronously, new asynchronous I/O can be submitted to a destination namespace whose drain has already completed. The reset path subsequently frees the submission/completion queues and the NvmeRequest array, but the deferred Copy callback continues to reference the freed NvmeRequest. This results in a reproducible heap-use-after-free in nvme_copy_out_cb(). This issue has been verified beyond a simple QEMU crash, including: - Exact reallocation of the freed NvmeRequest - Leaking QEMU PIE and heap addresses - Leaking host libc addresses - A guest-controlled host read/write primitive - Overwriting QEMUBH.cb/opaque control flow - Guest-to-host code execution running with QEMU process privileges - An interactive host shell obtained from an actual KVM guest ## Security Impact A malicious guest root can corrupt the memory of the QEMU host process using only guest-visible PCI/NVMe commands. The verified end impact is arbitrary code execution under the same host UID as the QEMU process. In the test environment, the interactive shell ran as: ```text uid=1001(finder) gid=1001(finder) ``` The parent process executable observed from the interactive shell was: ``` /mnt/e/researchlab/android/qemu/build-layout/qemu-system-x86_64 ``` No host root privilege escalation is claimed. The impact is limited to the privileges and sandbox scope held by the QEMU process. ## Attacker Model The minimal UAF trigger is reachable from a regular Linux guest through the following privileged interfaces: - NVME_IOCTL_ADMIN_CMD - NVME_IOCTL_IO_CMD - Guest-visible PCI function reset or CC.EN=0 Therefore, the currently verified attacker is a guest root process, or one holding equivalent CAP_SYS_ADMIN / raw device privileges. Direct reachability from unprivileged guest userspace is not claimed. The full RCE demonstration uses a small guest kernel transport to precisely control NVMe queue and DMA layout. This transport only exposes the guest's coherent DMA memory, NVMe BAR0 MMIO, and CMB; it does not directly map or modify host memory. ## Affected Versions Cross-namespace Copy support was added in commit d522aef88d42a05e46290c97602936a7f6d307e3 ("hw/nvme: add cross namespace copy support"). The first official release to include this commit is QEMU 9.1.0. Based on code history, the possibly affected range is: from QEMU 9.1.0 up until the fix commit is included. The upstream commit on which reproduction has currently been confirmed is: ad14439be5731e872d8448a04664a9c0e66624a8 QEMU 11.0.90 / v11.1.0-rc0-101-gad14439be5 This range has not yet been individually verified against every release tag; it is based on when the feature was introduced and the current upstream reproduction result. ## Root Cause nvme_ctrl_reset() iterates over namespaces in NSID order, calling nvme_ns_drain() on each before freeing the queues and request pool. In a cross-namespace Copy, the source and destination can belong to different block backends. The reproduced ordering is as follows: 1. A Copy is submitted with destination NSID 1 and source NSID 2. 2. A controller reset begins while the source read is executing asynchronously. 3. The reset drains destination namespace 1 first. 4. While the reset is draining source namespace 2, the source read callback runs. 5. This callback submits a new destination write to destination namespace 1, whose drain has already completed. 6. The reset subsequently frees the submission queue, completion queue, and the NvmeRequest array. 7. The late-completing destination write callback then references the freed NvmeCopyAIOCB::req and req->ns. The first invalid access observed under ASan was: ``` ERROR: AddressSanitizer: heap-use-after-free READ of size 8 nvme_copy_out_cb ../hw/nvme/ctrl.c:2979 ``` That memory was freed along the following reset path: ``` nvme_free_sq() nvme_ctrl_reset() nvme_write_bar() nvme_mmio_write() ``` The core issue is that, while namespaces are drained sequentially one at a time, a cross-namespace callback can submit new I/O to a namespace that has already been drained. The current reset path does not guarantee that all cross-namespace Copy callbacks reach full quiescence before queue/request memory is freed. ## Minimal Reproduction Environment The minimal ASan reproduction requires only two namespaces: - NSID 1: destination, delayed write - NSID 2: source, delayed read - Copy Descriptor Format: 2 The test uses QEMU's built-in null-co,latency-ns block backend to make callback ordering deterministic. This is not a mechanism for externally modifying QEMU memory, but a way to reliably widen a naturally occurring asynchronous I/O window. The attached qtest reproducer can be run against an ASan QEMU build as follows: ``` QTEST_QEMU_BINARY=/absolute/path/to/qemu-system-x86_64 \ ./nvme-copy-reset-uaf-test ``` Expected result: ``` COPY is in flight; resetting the controller ERROR: AddressSanitizer: heap-use-after-free READ of size 8 nvme_copy_out_cb ../hw/nvme/ctrl.c:2979 ``` ## Real KVM Guest Reachability Beyond qtest, the same reset ordering was verified from an actual KVM guest. Guest environment: - Ubuntu guest - Kernel: 7.0.0-27-generic - Attacker privilege: guest root - Acceleration: KVM Using a release build, a trigger based on stock Linux NVMe ioctls and guest-visible PCI function reset also caused QEMU to terminate after the same reset, via an accounting assertion: ``` block_account_one_io: Assertion `cookie->type < BLOCK_MAX_IOTYPE' failed. ``` Therefore this issue is not qtest-only, and is reachable via real guest input. ## Code Execution Verification The full exploit was structured in the following steps: 1. Trigger the cross-namespace Copy/reset UAF. 2. Reclaim the freed NvmeRequest and associated QEMUIOVector allocation via a guest-controlled allocation. 3. Write the stale callback result into a guest-visible namespace to leak NvmeCtrl, PIE, CMB, and admin BH addresses. 4. Read free@GOT to compute the host libc base and the address of system(). 5. Stage a {system, command} payload via a normal guest NVMe WRITE. 6. Overwrite QEMUBH.cb/opaque with {system, command} using a final forged split-iovec. 7. Write the unchanged, existing admin SQ tail value to the doorbell to trigger execution of the BH callback in the QEMU main loop. 8. An interactive host shell inheriting the QEMU process's terminal is spawned. The ASLR base is computed at runtime from a guest-visible leak. However, since symbol and GOT-relative offsets are build-specific, the QEMU and libc Build IDs were verified for reproducibility. Verified release-style build: - QEMU build flags: -O2 -g - PIE: enabled - Stack protector: strong - RELRO: full - NX: enabled - ASan/UBSan: disabled QEMU Build ID: af9d8979979973eebf00d0fb2d82936a0425705f Host libc Build ID: 8e9fd827446c24067541ac5390e6f527fb5947bb Because the full RCE depends on allocator layout, 100% success on every new QEMU process is not claimed. An actual interactive host shell success was confirmed, but on some runs the small QEMUIOVector exact reclaim missed and the exploit aborted cleanly as a result. The currently verified claim boundary is that guest-to-host code execution is achievable on a single clean process. ## Additional Components of the Full RCE Demo The requirements for the minimal UAF reproduction and the full RCE demonstration should be distinguished. Minimal UAF: - 2 namespaces - Cross-namespace Copy format 2 - Asynchronous block I/O - Controller reset Current full RCE demo: - Guest root - Raw guest PCI/DMA transport - 1 MiB NVMe CMB - 5 namespaces - Deterministic block latency - A read-only virtio-blk alias on the same backing file - Verified QEMU/libc Build IDs The additional namespaces and delayed backend are a research configuration used to stabilize allocator grooming and callback ordering. The CMB and read-only alias are currently used in the address-leak and payload-staging chain. Therefore, the current results are not claimed to be a generic exploit applicable to every default-configuration QEMU VM. The precise statement is: > Under a disclosed device configuration and a deterministic I/O timing profile, a verified guest-root-to-host RCE against an unpatched vulnerable QEMU build. ## Suggested Fix Direction One or more of the following approaches appears to be needed: - Explicitly track all NvmeCopyAIOCBs during a controller reset, and free the queues only after they have fully cancelled/completed - Repeatedly drain until all source/destination backends referenced by a cross-namespace Copy no longer generate new child I/O - Apply explicit lifetime/refcounting so that the Copy context cannot outlive the NvmeRequest and namespace - Add a state check so that callbacks cannot submit a new Copy stage or destination I/O during a reset If needed, a proposed patch can be verified against the ASan reproducer, the real KVM trigger, and the full RCE harness. ## Files Available The following individual files can be provided first: - nvme-copy-reset-uaf-test.c — Minimal ASan qtest reproducer - qtest-asan.log — Full ASan diagnostics - nvme-copy-reset.c — Stock Linux guest trigger - run-kvm.sh — Real KVM reachability launcher The full guest-to-host RCE source and the guest kernel transport are also ready. Since it is stated that attachment URLs on a GitLab confidential issue are not fully private, these will be provided as individual files after confirming the maintainer's preferred delivery method.