Summary

nvme_alloc_subqueue(), nvme_alloc_comqueue(), nvme_free_subqueue(), nvme_free_comqueue(), nvme_create_subqueue(), nvme_create_comqueue(), and nvme_delete_comqueue() all take a uint16_t qid (range 0..65535) but immediately use it to index sc->subqueues[NVME_MAX_QUEUES=1024] or sc->comqueues[1024] with no bounds check.

All current callers (solely the admin thread state machine in nvme_admin.c and the attach path) pass values bounded to < NVME_MAX_QUEUES, so there is no exploitable path today, but the API offers no defensive boundary — any future caller passing an unchecked qid (e.g. from a device response or a new ioctl) would produce a direct out-of-bounds access into the multi-hundred-KB softc.

Root cause

nvme_alloc_subqueue nvme.c:128:

nvme_subqueue_t *queue = &sc->subqueues[qid];

— qid is uint16_t, subqueues is [NVME_MAX_QUEUES=1024]. nvme_alloc_subqueue:139 then computes NVME_REG_SUBQ_BELL(qid, sc->dstrd4) which for qid>=1024 produces a doorbell MMIO offset 0x1000 + (qid*2)*dstrd4 far beyond the BAR — writing this could fault the PCI config/MMIO path.

nvme_alloc_comqueue nvme.c:235 and nvme_free_subqueue nvme.c:276 / nvme_free_comqueue nvme.c:304 have the identical unchecked &sc->{sub,com}queues[qid] dereference.

nvme_create_subqueue nvme.c:790, nvme_create_comqueue nvme.c:814, nvme_delete_comqueue nvme.c:891 likewise.

The contract explicitly calls out "Missing bounds on queue array indexing" as a focus area.

Threat model

No current exploit path — all callers (nvme_admin_state_make_queues bounded by NVME_MAX_QUEUES-1 at nvme_admin.c:296-299, nvme_admin_thread cleanup loop bounded by sc->niosubqs/niocomqs at nvme_admin.c:193-200, and nvme_attach.c:401/407 for qid=0) pass in-range values.

The risk is regression: a future patch that introduces a qid sourced from device data or an ioctl would have no guardrail. Filed as hardening/defense-in-depth.

Recommended fix

Add a one-line guard at the entry of each of the seven helpers. Example for nvme_alloc_subqueue (apply identically to the other six):

--- a/sys/dev/disk/nvme/nvme.c
+++ b/sys/dev/disk/nvme/nvme.c
@@ -126,6 +126,8 @@ nvme_enable(nvme_softc_t *sc, int enable)
 int
 nvme_alloc_subqueue(nvme_softc_t *sc, uint16_t qid)
 {
+   if (qid >= NVME_MAX_QUEUES)
+       return EINVAL;
    nvme_subqueue_t *queue = &sc->subqueues[qid];
    int error = 0;

For the void-returning free_* variants, use if (qid >= NVME_MAX_QUEUES) return;. For create_*/delete_* which currently always succeed the qid indexing before issuing the admin command, returning EINVAL early is the safe choice.

This converts a latent OOB into an explicit, documented API contract.

Related findings

• DF-1676 (sibling: live nvme_poll_completions OOB via device-controlled indices — different sink, same "queue array missing bounds" theme)