Summary

nvme_poll_completions() reads completion entries directly from DMA-coherent memory shared with the controller and uses two device-supplied 16-bit fields — res->tail.subq_id and res->tail.cmd_id — as raw array indices into sc->subqueues[NVME_MAX_QUEUES=1024] and subq->reqary[nqe≤256] with no bounds check. The only sanity check present (KKASSERT at lines 722-723) compiles to a no-op in production kernels (it expands to do{}while(0) when INVARIANTS is undefined, per sys/systm.h:117-118).

A malicious or faulty NVMe controller — reachable via the explicitly in-scope "drive firmware responses" attack surface — can supply out-of-range indices to corrupt arbitrary kernel memory, including via the req->callback indirect call that yields kernel RIP control.

Root cause

At nvme.c:675 the loop reads res = &comq->kcomq[comq->comq_tail] — a 16-byte completion entry in DMA-coherent memory that the controller writes. The phase check at :676 only validates the entry is "new", not its contents.

Then at nvme.c:713:

subq = &sc->subqueues[res->tail.subq_id];   /* indexes [1024] with uint16_t */

— values 1024..65535 read memory past the end of the (huge, ~400 KB) softc, interpreting whatever bytes are there as a nvme_subqueue_t.

At :714:

subq->subq_head = res->tail.subq_head_ptr;

writes 4 bytes of device-controlled data into that phantom struct.

At :715:

req = &subq->reqary[res->tail.cmd_id];

computes a pointer from a device-controlled base (subq->reqary read from OOB memory) plus a device-controlled uint16_t index — cmd_id can be 0..65535 but reqary is only nqe (≤256) entries.

At :724 req->res = *res writes 16 bytes of device-controlled data to that computed address; at :727 req->state = NVME_REQ_COMPLETED writes 4 more bytes.

Finally at :728-729:

if (req->callback)
    req->callback(req, lk);

dereferences a function pointer read from the corrupted/OOB req memory — if the attacker can land the OOB req on memory they influence (heap grooming of adjacent kmalloc slabs, or by choosing subq_id so the phantom subqueue's reqary points at a controllable region), this is a controlled kernel indirect-call → RIP hijack.

The KKASSERT(req->state==NVME_REQ_SUBMITTED && req->comq==comq) at :722-723 is the only guard and it (a) only checks state/comq, never array bounds, and (b) is compiled out entirely in non-INVARIANTS production builds (sys/systm.h:118).

Threat model

Attacker position: a malicious NVMe controller reachable via PCIe (Thunderbolt/USB4 NVMe enclosure hotplug, a crafted PCI device in a VM passed through via VFIO, or a drive whose firmware has been compromised — e.g. via the also-in-scope unprivileged NVMEIOCGETLOG surface or a remote firmware-update vector).

The attacker need only cause the controller to emit one completion entry with subq_id >= 1024 or cmd_id >= 256; the host kernel then dereferences it on the next poll — triggered by any disk I/O, the admin thread's 1 Hz poll loop (nvme_admin.c:165-174), or any NVMEIOCGETLOG ioctl.

Impact:

• trivial DoS (any bogus index dereferences a garbage pointer → kernel page fault → panic)
• with slab grooming, arbitrary kernel memory write via req->res = *res (16 controlled bytes)
• full RIP control via req->callback (the driver itself sets req->callback to nvme_disk_callback at nvme_disk.c:332, so a controlled req slot with a non-NULL callback yields a controlled call target)

No privilege is needed beyond the ability to trigger disk I/O (any unprivileged user reading /dev/nvme*X).

Default config: no special kernel options required; the bug is present whenever an NVMe controller is attached.

PoC

Reproduce with a modified QEMU NVMe device emulation (fastest path; works against the unmodified DragonFlyBSD kernel). Steps:

1. In QEMU source hw/nvme/nvme.c, in the completion-path function (nvme_process_sq / nvme_post_cqes), hardcode the first completion entry it emits to: subq_id=0x0500 (1280, > NVME_MAX_QUEUES=1024), cmd_id=0, status=(phase|SUCCESS<<1).
2. Build QEMU: ./configure --target-list=x86_64-softmmu && make -j.
3. Boot a DragonFlyBSD kernel built WITHOUT INVARIANTS (GENERIC):

sh qemu-system-x86_64 -machine q35,accel=kvm \ -drive file=dfly.img \ -device nvme,drive=nvm0,serial=BAD0 \ -drive id=nvm0,file=nvme.dat,format=raw ...

4. Trigger any I/O to the nvme disk from inside the guest: dd if=/dev/nvme0s0 of=/dev/null bs=4k count=1.

Expected: immediate kernel panic — either Fatal trap 12: page fault while in kernel mode from dereferencing the phantom subq->reqary pointer (OOB read past softc), or memory corruption manifesting as a later panic when the corrupted req->callback is invoked.

For the RCE chain: choose subq_id so the phantom subqueue lands on attacker-controlled kernel memory (e.g. via prior spray of NVMEIOCGETLOG-allocated buffers or large kmalloc objects placed adjacent to the softc), set the phantom subq->reqary to point at a crafted fake nvme_request_t whose callback field is a chosen gadget (e.g. pivoting to a stack-shift/copy-from-user gadget), then trigger I/O — the kernel calls req->callback(req, lk) at attacker-chosen RIP.

Evidence pack should include: patched qemu diff, the boot.log showing the panic, and dmesg/db> trace from the crash demonstrating the OOB index in %rdi/%rsi at the fault.

Recommended fix

Add explicit bounds validation of both device-supplied indices before dereferencing, doorbelling the controller past the rejected entry so the queue does not stall.

--- a/sys/dev/disk/nvme/nvme.c
+++ b/sys/dev/disk/nvme/nvme.c
@@ -704,6 +704,28 @@ nvme_poll_completions(nvme_comqueue_t *comq, struct lock *lk)
        cpu_lfence();   /* needed prior to content check */

        /*
+        * Validate device-supplied indices before dereferencing.
+        * The controller writes res->tail.subq_id and res->tail.cmd_id
+        * into DMA-coherent memory; a faulty or malicious controller
+        * can supply out-of-range values that would index outside
+        * sc->subqueues[NVME_MAX_QUEUES] or subq->reqary[subq->nqe].
+        * Drop the entry (advancing the doorbell) and continue rather
+        * than corrupting kernel memory.
+        */
+       if (res->tail.subq_id >= NVME_MAX_QUEUES ||
+           sc->subqueues[res->tail.subq_id].nqe == 0 ||
+           res->tail.cmd_id >= sc->subqueues[res->tail.subq_id].nqe) {
+           device_printf(sc->dev,
+               "nvme: dropping bogus completion "
+               "subq_id=%u cmd_id=%u\n",
+               res->tail.subq_id, res->tail.cmd_id);
+           nvme_write(sc, comq->comq_doorbell_reg, comq->comq_tail);
+           continue;
+       }
+
+       /*
         * Locate the request and related submission queue.  The
         * request could be on a different queue.  A submission
         * queue can have only one completion queue, so we can

This also closes the related UAF-by-confusion path (the KKASSERT at :722-723 is compiled out in production): after the bounds check, subq is guaranteed to be an initialized queue and req is guaranteed to be within its reqary, so req->state / req->comq / req->callback refer to a real request. Consider additionally compiling this file with INVARIANTS in debug builds so the existing KKASSERT provides a second line of defense.

Related findings

• DF-1677 (sibling: nvme queue helpers missing qid bound — latent variant)