# DF-4698 — nvme(4): queue-creation retry path re-allocates live subqueues/comqueues → double `lockinit` + permanent DMA/request-pool leak

## Where
`sys/dev/disk/nvme/nvme_admin.c` `nvme_admin_state_make_queues()` — error unwind asymmetry
between the completion-queue and submission-queue loops (lines 453–515) interacting with
`nvme_alloc_subqueue`/`nvme_free_subqueue` (`sys/dev/disk/nvme/nvme.c:126–299`).

## Trace
1. comq creation fails at index k → the comq unwind loop (nvme_admin.c:498-501) frees
   comqueues k..1 (correct, `comq_err_idx` includes the failed one via the `++i` at :465).
2. The **subq loop still runs** (nvme_admin.c:471-485): `nvme_alloc_subqueue(sc,1)` succeeds
   (pure memory op), `nvme_create_subqueue(sc,1)` fails because its completion queue no
   longer exists → `break` at :482 with `i = 1` and **no** `++i` → `subq_err_idx = 1` →
   the unwind loop `for (i = subq_err_idx - 1; i >= 1; --i)` (nvme_admin.c:494-497) runs
   **zero iterations** → subqueues[1] stays allocated (reqary kmalloc + sque/prps/adm DMA
   maps) but uncreated.
3. `goto tryagain` (nvme_admin.c:514) with 1/1 queues → `nvme_alloc_subqueue(sc,1)` runs
   again on the still-allocated queue:
   * `nvme.c:135` `lockinit(&queue->lk, …)` on an already-initialized lock;
   * `nvme.c:145/163` `bus_dmamem_alloc` overwrites `queue->ksubq`/`queue->kprps` and
     `nvme.c:197` overwrites `queue->reqary` **without freeing the previous allocations**
     → one full set of queue DMA buffers + request array leaks permanently (the old
     pointers are gone; teardown frees only the current ones).
   The identical asymmetry exists for the comq loop if `nvme_alloc_comqueue` itself fails
   after a prior successful retry-less attempt.

## Threat
Requires a controller that fails an I/O-queue creation and then succeeds on the 1/1 retry
("device lied to us" path, nvme_admin.c:503-514) — firmware malfunction or a malicious
device. Impact: permanent kernel/DMA memory leak (repeatable on every controller reset
cycle) and re-initialization of a live lock. No direct memory-safety violation on the
leaked objects (they are simply lost).

## PoC
Not runnable on the audit guest: stock QEMU 7.2 always succeeds queue creation, and no
mechanism exists to make it fail selectively. `untested` (analysis-certain).

## Fix sketch
* unwind the subq loop with the same `++i`-inclusion convention as the comq loop, and
* before re-allocating a queue in the `tryagain` path, `nvme_free_subqueue()`/`nvme_free_comqueue()`
  any still-allocated queue in 1..N (or track allocation state and refuse double alloc).