A collaborator of ours (Emma Kirkpatrick at Apple's SEAR) ran Mythos against QEMU, and sent us the reports to triage and send upstream. Given that this was found by several agents, it's plausible that this is a dupe of things you've already found, though I don't see anything specific that's already public (it is similar but not 100% a dupe of https://gitlab.com/qemu-project/qemu/-/work_items/4068 based on my quick skim). Given that this had an ASAN report and a repro generator, it seemed to pass the basic sniff test. Although the Robot is convinced this is a vulnerability, I don't believe it is. It's a non-virtualization device (NVME), so I'm treating this as a bug instead of a security issue, obviously feel free to lock this down if I have misinterpreted that. Robot filled out the template based on the raw report (which is at the bottom): ## Host environment - Operating system: Linux / macOS (reproduced on Linux & macOS ASAN/UBSAN debug builds) - OS/kernel version: Linux 6.x / Darwin - Architecture: x86_64 / arm64 - QEMU flavor: qemu-system-x86_64 - QEMU version: QEMU master (`commit 282771e1f9`) - QEMU command line: ``` ./qemu-system-x86_64 -M pc -accel tcg -m 256M -display none -no-reboot -nodefaults \ -drive id=d1,if=none,file=null-co://,file.read-zeroes=on,format=raw,file.size=64M,file.latency-ns=1000000000 \ -device nvme,id=nvme0,serial=poc,addr=04.0 \ -device nvme-ns,drive=d1,bus=nvme0,nsid=1,logical_block_size=512,ms=8 \ -kernel guest.bin ``` Or via qtest: ``` ./qemu-system-x86_64 -M pc -m 256M \ -drive id=d1,if=none,file=null-co://,file.read-zeroes=on,format=raw,file.size=64M,file.latency-ns=1000000000 \ -device nvme,id=nvme0,serial=poc,addr=04.0 \ -device nvme-ns,drive=d1,bus=nvme0,nsid=1,logical_block_size=512 \ -accel qtest ``` ## Emulated/Virtualized environment - Operating system: Bare metal / Custom guest reproducer payload (`guest.bin`) - OS/kernel version: N/A - Architecture: x86_64 ## Description of problem A heap use-after-free (UAF) read/write vulnerability exists in `hw/nvme/ctrl.c` during controller reset (`nvme_ctrl_reset()`) combined with asynchronous block request draining (`blk_drain()`). A guest can free an NVMe I/O submission queue's request array (`sq->io_req[]`) while a `blk_aio_*()` operation referencing one of those requests is still in flight in the host backend. This is achieved by writing to an SQ doorbell immediately followed by clearing `CC.EN = 0` (controller reset) back-to-back while at least one earlier I/O is outstanding: 1. `nvme_ctrl_reset()` calls `nvme_ns_drain(ns)` (`blk_drain()`) to quiesce ongoing guest I/O before freeing resources. 2. Inside `blk_drain()`, `bdrv_drained_begin()` runs a nested `aio_poll()`, which dispatches the guest's just-scheduled bottom half (`sq->bh`), submitting a **new** AIO request mid-drain. 3. That request's coroutine reaches `blk_wait_while_drained()`, sees `quiesce_counter > 0`, decrements `in_flight`, and parks on `blk->queued_requests` — allowing `blk_drain()` to exit early under the belief that `in_flight == 0`. 4. `bdrv_drained_end()` -> `blk_root_drained_end()` then **resumes** the parked coroutine, which submits real I/O to the backend and yields. `blk_drain()` returns while `in_flight == 1`. 5. `nvme_ctrl_reset()` immediately proceeds to free all SQ and CQ allocations (`g_free(sq->io_req)`, `g_free(sq)`, `g_free(cq)`). 6. When the backend I/O later completes, callback handlers (`dma_blk_cb` -> `nvme_rw_cb` -> `nvme_rw_complete_cb` -> `nvme_enqueue_req_completion`) dereference freed `NvmeRequest`, `NvmeSQueue`, and `NvmeCQueue` pointers on the heap, triggering AddressSanitizer heap-use-after-free crash/memory corruption. ## Steps to reproduce 1. Build QEMU with AddressSanitizer (`--enable-sanitizers` or `--enable-debug`). 2. Run QEMU with the emulated NVMe controller configured with simulated backend IO latency: ```bash ./qemu-system-x86_64 -M pc -accel tcg -m 256M -display none -no-reboot -nodefaults \ -drive id=d1,if=none,file=null-co://,file.read-zeroes=on,format=raw,file.size=64M,file.latency-ns=1000000000 \ -device nvme,id=nvme0,serial=poc,addr=04.0 \ -device nvme-ns,drive=d1,bus=nvme0,nsid=1,logical_block_size=512,ms=8 \ -kernel guest.bin ``` 3. Inside the guest, submit an initial asynchronous read/write I/O request to an I/O Submission Queue (SQ1). 4. While that initial command is in flight, issue a second doorbell write to SQ1 and immediately write `CC.EN = 0` to the controller configuration register (MMIO write). 5. AddressSanitizer immediately triggers a `heap-use-after-free` crash in `dma_blk_cb` / `nvme_free_sq`. ## Additional information ### AddressSanitizer Crash Trace (excerpt) ``` ================================================================= ==26048==ERROR: AddressSanitizer: heap-use-after-free on address 0x61c0000109f8 at pc 0x000101e264fc bp 0x000120dd24f0 sp 0x000120dd24e8 READ of size 4 at 0x61c0000109f8 thread T6 #0 0x000101e264f8 in dma_blk_cb dma-helpers.c:128 0x61c0000109f8 is located 376 bytes inside of 1728-byte region [0x61c000010880,0x61c000010f40) freed by thread T6 here: #0 0x000107e8b80c in free+0x7c (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3f80c) #1 0x0001016e18e8 in nvme_free_sq ctrl.c:4806 #2 0x000101675fec in nvme_ctrl_reset ctrl.c:7908 #3 0x00010166e8b4 in nvme_write_bar ctrl.c:8164 #4 0x00010166cd1c in nvme_mmio_write ctrl.c:8531 #5 0x000101e51c8c in memory_region_write_accessor memory.c:492 ... previously allocated by thread T6 here: #0 0x000107e8ba04 in calloc+0x80 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fa04) #1 0x000107886ea8 in g_malloc0+0x20 (libglib-2.0.0.dylib:arm64+0x36ea8) #2 0x00010167cf48 in nvme_init_sq ctrl.c:4866 #3 0x0001016d200c in nvme_create_sq ctrl.c:4929 #4 0x00010168cc88 in nvme_admin_cmd ctrl.c:7599 #5 0x000101688d20 in nvme_process_sq ctrl.c:7839 ... SUMMARY: AddressSanitizer: heap-use-after-free dma-helpers.c:128 in dma_blk_cb ``` - Workspace tracking info: Internal bug reference `532601022` (PoC identifier `C2`). - Affected source files: `hw/nvme/ctrl.c`, `block/block-backend.c`, `system/dma-helpers.c`. <!-- The line below ensures that proper tags are added to the issue. Please do not remove it. --> ## Raw Report # QEMU NVMe: Use-after-free on controller reset via drained-request requeue **Component:** `hw/nvme` (emulated NVMe controller) + `block/block-backend.c` **Files:** `hw/nvme/ctrl.c`, `block/block-backend.c`, `system/dma-helpers.c` **Affected:** QEMU master @ `282771e1f9` **Class:** Heap use-after-free (read, then write via `QTAILQ_INSERT_TAIL`) **Severity:** High (guest → host QEMU process; default device configuration) **Discovered by:** Apple SEAR, static analysis + qtest reproducer --- ## Summary A guest can free an NVMe I/O submission queue's request array (`sq->io_req[]`) while a `blk_aio_*()` operation referencing one of those requests is still in flight, by writing the SQ doorbell and `CC.EN = 0` back-to-back while at least one earlier I/O is outstanding. `nvme_ctrl_reset()` calls `blk_drain()` for each namespace and then unconditionally frees every SQ/CQ. The drain is intended to guarantee that no I/O is in flight when the queues are freed, but the interaction between three mechanisms defeats it: 1. `bdrv_drained_begin()`'s nested `aio_poll()` dispatches the just-scheduled `sq->bh`, which submits a **new** AIO request mid-drain; 2. that request's coroutine reaches `blk_wait_while_drained()`, sees `quiesce_counter > 0`, decrements `in_flight`, and parks on `blk->queued_requests` — so the drain's `in_flight == 0` condition becomes true; 3. `bdrv_drained_end()` → `blk_root_drained_end()` then **resumes** the parked coroutine, which submits real I/O to the backend and yields. `blk_drain()` returns with `in_flight == 1`. `nvme_ctrl_reset()` proceeds to `g_free(sq->io_req)` / `g_free(sq)` / `g_free(cq)`. When the backend I/O later completes, `blk_aio_complete()` invokes the DMA callback chain (`dma_blk_cb` → `dma_complete` → `nvme_rw_cb` → `nvme_rw_complete_cb` → `nvme_enqueue_req_completion`), each of which dereferences the freed `NvmeRequest` and the freed `NvmeSQueue`/`NvmeCQueue`. --- ## Root cause ### `nvme_ctrl_reset()` assumes drain quiesces all device I/O `hw/nvme/ctrl.c:7890-7915`: ```c static void nvme_ctrl_reset(NvmeCtrl *n, NvmeResetType rst) { ... for (i = 1; i <= NVME_MAX_NAMESPACES; i++) { ns = nvme_ns(n, i); if (ns) { nvme_ns_drain(ns); /* -> blk_drain(ns->blkconf.blk) */ } } for (i = 0; i < n->params.max_ioqpairs + 1; i++) { if (n->sq[i] != NULL) { nvme_free_sq(n->sq[i], n); /* g_free(sq->io_req); g_free(sq) */ } } for (i = 0; i < n->params.max_ioqpairs + 1; i++) { if (n->cq[i] != NULL) { nvme_free_cq(n->cq[i], n); /* g_free(cq) */ } } ``` ### Nested poll dispatches the pending SQ bottom-half `sq->bh` is created with `qemu_bh_new_guarded(nvme_process_sq, sq, &DEVICE(n)->mem_reentrancy_guard)` (`ctrl.c:4875`). The reentrancy guard is **trace-only for BHs** — `aio_bh_call()` (`util/async.c:159-178`) emits `trace_reentrant_aio` when the guard is engaged but **still calls** `bh->cb()`. The guard only blocks **MMIO** re-entry (`system/memory.c:546-555`). `blk_drain()` (`block/block-backend.c:2073-2091`): ```c void blk_drain(BlockBackend *blk) { ... bdrv_drained_begin(bs); /* sets blk->quiesce_counter, * then BDRV_POLL_WHILE(...) */ AIO_WAIT_WHILE(blk_get_aio_context(blk), qatomic_read(&blk->in_flight) > 0); bdrv_drained_end(bs); /* resumes queued_requests */ } ``` `BDRV_POLL_WHILE` / `AIO_WAIT_WHILE` call `aio_poll(qemu_get_aio_context(), true)` while their condition is true. With at least one earlier I/O outstanding (`in_flight > 0`), `aio_poll()` runs and `aio_bh_poll()` dispatches the `sq->bh` that the guest's doorbell write scheduled. ### The new request parks, then escapes the drain `nvme_process_sq()` → `nvme_read()`/`nvme_write()` → `dma_blk_read()` → `blk_aio_preadv()` → `blk_aio_prwv()` does `blk_inc_in_flight()` and enters a coroutine that calls `blk_co_do_preadv_part()` → `blk_wait_while_drained()` (`block/block-backend.c:1309-1326`): ```c static void coroutine_fn blk_wait_while_drained(BlockBackend *blk) { assert(blk->in_flight > 0); if (qatomic_read(&blk->quiesce_counter) && !qatomic_read(&blk->disable_request_queuing)) { ... blk_dec_in_flight(blk); qemu_co_queue_wait(&blk->queued_requests, &blk->queued_requests_lock); ... } } ``` NVMe never calls `blk_set_disable_request_queuing()`, so the request parks. `in_flight` drops back to its prior value; once the *earlier* I/O completes, `in_flight == 0` and `BDRV_POLL_WHILE`/`AIO_WAIT_WHILE` exit. `bdrv_drained_end()` → `blk_root_drained_end()` (`block/block-backend.c:2768-2789`): ```c if (qatomic_fetch_dec(&blk->quiesce_counter) == 1) { ... while (!qemu_co_queue_empty(&blk->queued_requests)) { blk_inc_in_flight(blk); qemu_co_enter_next(&blk->queued_requests, ...); /* synchronous */ } } ``` The coroutine resumes, returns from `blk_wait_while_drained()`, and proceeds into the block driver. For any backend with non-zero latency (real disk, `null-co,latency-ns=N`, throttled, network block device, etc.), the driver coroutine **yields**. `qemu_co_enter_next()` returns; `blk_root_drained_end()` returns; `blk_drain()` returns. **`in_flight == 1`.** ### Free, then use `nvme_free_sq()` (`ctrl.c:4794-4810`): ```c qemu_bh_delete(sq->bh); ... g_free(sq->io_req); /* <- frees the live NvmeRequest */ if (sq->sqid) { g_free(sq); } ``` When the backend I/O completes, `blk_aio_complete()` calls `dma_blk_cb(dbs, ret)`. `dbs->sg` points at `&req->sg.qsg` inside the freed `io_req[]` (`dma-helpers.c:128`, first UAF read). The chain continues through `dma_complete()` → `nvme_rw_cb(req, ret)` (`ctrl.c:2189-2190` reads `req->ns`, `req->sq`) → `nvme_rw_complete_cb()` → `nvme_enqueue_req_completion(nvme_cq(req), req)` (`ctrl.c:1561-1569`), which reads freed `req->sq->cqid`, indexes freed `n->cq[cqid]`, and does `QTAILQ_INSERT_TAIL(&cq->req_list, req, entry)` — a write through a freed `cq` and a write into the freed `req->entry` linked-list pointers. --- ## Reachability / preconditions | Gate | Status | Reference | |---|---|---| | `sq->bh` on `qemu_aio_context` | Always (`qemu_bh_new_guarded`) | `ctrl.c:4875` | | Reentrancy guard blocks BH? | **No** — trace only | `util/async.c:166-173` | | `blk->disable_request_queuing` | `false` for NVMe (never set) | grep: no `blk_set_disable_request_queuing` in `hw/nvme/` | | `BDRV_POLL_WHILE` enters `aio_poll` | Only if `in_flight > 0` at entry → **need ≥1 earlier I/O outstanding** | `include/qemu/aio-wait.h` | | `sq->bh` scheduled when `nvme_ctrl_reset` runs | **OR** any chained-aio command (Read/Write with `ms>0`+MPTR, Copy, Compare, Verify) whose first aio is in flight — the second aio is submitted from inside drain's poll. This is the race-free guest-reachable path (see guest PoC). The pending-BH path also works but is not winnable from a real vCPU under MTTCG (BQL waiter handoff). | `ctrl.c:2209-2229` | | Backend yields after resume | Any real disk / network / throttled / `latency-ns` backend | — | **Host configuration required:** `-device nvme` with one `nvme-ns` on a backend with non-zero I/O latency. **Default device properties.** No experimental flags. Reachable from any guest code that can submit NVMe I/O and write controller registers (i.e., a guest NVMe driver). --- ## Proof of concept ### Bare-metal guest reproducer (`poc/C2/gen-guest.py` → `c2-guest.bin`, 21 KiB) The qtest "pending `sq->bh` when `CC.EN=0` lands" condition is **not reproducible from a real guest under MTTCG**: `qemu_bh_schedule()`'s `aio_notify()` wakes the main-loop thread, which then deterministically wins the BQL handoff between the doorbell MMIO and the `CC=0` MMIO. The guest PoC therefore uses a **race-free** variant that does not need a pending BH at all: A single NVMe Read on a namespace with metadata (`ms=8`) and `MPTR` set performs **two chained `blk_aio_pread`s** — `nvme_rw_cb()` (`hw/nvme/ctrl.c:2215-2226`) issues the metadata read from the data-read completion callback. With a 1 s `null-co,latency-ns` backend: 1. Guest submits one Read, spins briefly so `sq->bh` runs → data read in flight (`in_flight=1`). 2. Guest writes `CC=0` → `nvme_ctrl_reset` → `blk_drain`: - `BDRV_POLL_WHILE(in_flight>0)` polls ~1 s; data read completes; `nvme_rw_cb` runs **inside the poll** and submits the metadata read. - `blk_wait_while_drained()` sees `quiesce_counter>0` and parks it on `queued_requests`; `in_flight→0`; poll exits. - `bdrv_drained_end` → `blk_root_drained_end` resumes the parked coroutine → `null-co` arms a 1 s timer and yields → `blk_drain()` returns with `in_flight=1`. 3. `nvme_free_sq()` frees `sq->io_req[]` (containing this `NvmeRequest`). 4. ~1 s later the metadata read completes → `dma_blk_cb` / `nvme_rw_complete_cb` on the freed request → **heap-use-after-free**. 215 B of code; admin SQEs / IO SQE / queues are pre-baked at page-aligned offsets in the multiboot image. Deterministic (5/5 runs, identical fault address). ``` $ build-asan/qemu-system-x86_64 \ -M pc -accel tcg -m 256M -display none -no-reboot -nodefaults \ -drive id=d1,if=none,file=null-co://,file.read-zeroes=on,format=raw,\ file.size=64M,file.latency-ns=1000000000 \ -device nvme,id=nvme0,serial=poc,addr=04.0 \ -device nvme-ns,drive=d1,bus=nvme0,nsid=1,logical_block_size=512,ms=8 \ -kernel poc/C2/c2-guest.bin ==62769==ERROR: AddressSanitizer: heap-use-after-free on address 0x61c000020120 READ of size 4 at 0x61c000020120 thread T4 #0 dma_blk_cb dma-helpers.c:128 freed by thread T3 here: #1 nvme_free_sq ctrl.c:4806 #2 nvme_ctrl_reset ctrl.c:7908 #4 nvme_mmio_write ctrl.c:8531 #12 helper_stl_mmu ldst_common.c.inc:100 #14 cpu_tb_exec cpu-exec.c:439 previously allocated by: #2 nvme_init_sq ctrl.c:4866 ``` Full guest-PoC ASAN report: `poc/C2/asan-report-guest.txt`. Any chained-aio NVMe command is an equivalent vector: Write/Write-Zeroes with metadata (ctrl.c:2209/2229), Copy (read→write), Compare, Verify, DSM. The metadata-Read variant is the minimal one. ### qtest reproducer (`tests/qtest/nvme-c2-poc-test.c`) Uses the original two-I/O / pending-`sq->bh` sequence. To reproduce the "BH scheduled but not yet dispatched when `CC.EN=0` is processed" condition under qtest, the PoC adds `qtest_writel_batch2()` to libqtest: it sends both `writel` lines in a single socket write so the qtest server's `qtest_process_inbuf()` (`system/qtest.c:768-788`, processes all buffered lines in one chardev dispatch) handles both before returning to the main loop. Sequence: 1. Bring up controller, create I/O CQ1/SQ1. 2. Submit I/O #1 (Read, 1 LBA) on SQ1 → `in_flight=1` on a 1-second `null-co,latency-ns` backend. 3. Stage I/O #2 in SQ1 slot 1. 4. Batched: `writel SQ1_DB 2` + `writel CC 0`. 5. `nvme_ctrl_reset` runs as described above; `sq->io_req[]` is freed with I/O #2 in flight. 6. ~1 s later, I/O #2 completes → ASAN heap-use-after-free. ``` $ cd build-asan $ env TMPDIR=/tmp QTEST_QEMU_BINARY=./qemu-system-x86_64 \ ./tests/qtest/nvme-c2-poc-test --tap ==25769==ERROR: AddressSanitizer: heap-use-after-free on address 0x61c0000109f8 READ of size 4 at 0x61c0000109f8 thread T6 #0 dma_blk_cb dma-helpers.c:128 0x61c0000109f8 is located 376 bytes inside of 1728-byte region freed by thread T6 here: #1 nvme_free_sq ctrl.c:4806 #2 nvme_ctrl_reset ctrl.c:7908 #3 nvme_write_bar ctrl.c:8164 #4 nvme_mmio_write ctrl.c:8531 ... previously allocated by thread T6 here: #2 nvme_init_sq ctrl.c:4866 #3 nvme_create_sq ctrl.c:4929 ``` Full ASAN report: `asan-report.txt`. Under a real (multi-threaded) accelerator the doorbell + `CC.EN=0` are simply two consecutive MMIO stores from one vCPU; the priming I/O is any outstanding read/write. --- ## Security impact | | | |---|---| | **Attack vector** | Malicious or compromised guest with NVMe register access. | | **Primitive** | Heap **use-after-free** of an `NvmeRequest` (≈216 B) inside a `g_new0(NvmeRequest, qsize)` array, plus the parent `NvmeSQueue`/`NvmeCQueue`. The completion path performs both **reads** (`req->ns`, `req->sq`, `req->sg.qsg.*`, `sq->cqid`) and **writes** (`req->status`, `QTAILQ_INSERT_TAIL` link pointers into `cq->req_list` and `req->entry`) through freed memory. | | **Exploitability** | Moderate-High. The free→use window is the backend I/O latency (guest-influenceable: choose a large transfer, or target a slow LBA). The freed chunks are in well-defined glibc/macOS-malloc size classes (`io_req[]` size = `qsize × sizeof(NvmeRequest)`, guest chooses `qsize`; `NvmeSQueue`/`NvmeCQueue` are fixed). The guest can heap-spray during the window via other device DMA paths or by re-enabling the controller and creating fresh queues. The `QTAILQ_INSERT_TAIL` write gives a constrained write-what-where (`*(freed_cq->req_list.tqh_last) = freed_req`; `freed_req->entry.tqe_prev = freed_cq->req_list.tqh_last`). With control of the reclaimed `cq` contents, this is a classic linked-list-unlink-style primitive. | | **Reliability** | Timing-dependent on the BH-vs-MMIO ordering, but that ordering is **deterministic** when both writes come from one vCPU (BQL serialises MMIO; main-loop BHs cannot interleave). The PoC reproduces it on every run. | | **Confidential-VM relevance** | Direct guest→host escape primitive against the QEMU process; independent of memory-encryption. | | **Mitigations bypassed** | `mem_reentrancy_guard` (BHs are not blocked by it); `blk_drain()` (the very mechanism intended to make this safe). | **Suggested CVSS 3.1:** `AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H` → **7.8 (High)**. `AC:H` reflects the heap-groom requirement for full code execution; the UAF itself is `AC:L`. --- ## Fix The invariant `nvme_ctrl_reset()` needs is "no NVMe AIO callback can fire after this point." `blk_drain()` does **not** provide that when device BHs can submit new requests during the drain. **Recommended fix (two parts):** **1. Stop new submissions before draining.** Delete (or at least cancel) every SQ BH **before** calling `nvme_ns_drain()`, so the drain's nested `aio_poll()` cannot dispatch `nvme_process_sq()`: ```c static void nvme_ctrl_reset(NvmeCtrl *n, NvmeResetType rst) { ... + for (i = 0; i < n->params.max_ioqpairs + 1; i++) { + if (n->sq[i]) { + qemu_bh_delete(n->sq[i]->bh); + n->sq[i]->bh = NULL; + } + } for (i = 1; i <= NVME_MAX_NAMESPACES; i++) { ns = nvme_ns(n, i); if (ns) { nvme_ns_drain(ns); } } ``` (and make `nvme_free_sq()` tolerate `bh == NULL`). **2. Disable request queuing on the namespace `BlockBackend`.** This makes `blk_wait_while_drained()` a no-op so a request submitted under drain runs to completion (or fails) synchronously instead of parking and being resumed after `blk_drain()` returns: ```c /* hw/nvme/ns.c: nvme_ns_init_blk() or nvme_ns_realize() */ + blk_set_disable_request_queuing(ns->blkconf.blk, true); ``` This is what `hw/ide`, `hw/scsi`, and `hw/block/virtio-blk.c` already do for the same reason. Either part alone closes this specific bug; both together are defence-in-depth and also close the related `nvme_del_sq()` livelock (round-3 finding M6) which has the same "nested `aio_poll` dispatches `sq->bh`" root. **Alternative / additional hardening:** - After `nvme_ns_drain()`, assert that every `sq->out_req_list` is empty before freeing. - In `block/block-backend.c`, have `blk_drain()` re-check `in_flight` after `bdrv_drained_end()` and loop — but this changes generic block-layer semantics and may have wider effects; the device-side fix is preferable. --- ## Related issues with the same root | Location | Issue | |---|---| | `ctrl.c:4828-4833` (`nvme_del_sq`) | `blk_aio_cancel()` → `AIO_WAIT_WHILE` nested poll dispatches the victim SQ's BH, which (with shadow-doorbell) re-reads `sq->tail` from guest RAM and re-submits → cancel loop never empties → BQL-holding livelock. Same fix (1) applies. | | `ctrl.c:4765-4774` | `nvme_sq_notifier()` calls `nvme_process_sq()` directly (no guard at all). With `ioeventfd=on`, an SGL spanning into BAR0 can re-enter `nvme_mmio_write` → `nvme_ctrl_reset` mid-`process_sq` → UAF on the *current* `sq`. Gated on non-default `ioeventfd=on`. |