DF-4420 — oce_mq_create leaks the CQ (ring DMA + struct) on two error paths

File: sys/dev/netif/oce/oce_queue.c (pass 2) Severity: Info (correctness/resource leak; no unprivileged reachability)

What happens

oce_mq_create() (sys/dev/netif/oce/oce_queue.c:663) creates its completion queue FIRST (line 675) and only assigns mq->cq = cq on the SUCCESS path (line 744). On two of the three failure paths the cq created at the top is never destroyed:

1. mq->ring = oce_create_ring_buffer(...) fails -> goto error (oce_queue.c:689-691) -> oce_mq_free(mq): - mq->ring == NULL -> ring block skipped (oce_queue.c:782) - mq->cq == NULL (still M_ZERO; never assigned on this path) -> CQ block skipped (oce_queue.c:796) - result: cq (kmalloc'd struct + oce_create_ring_buffer DMA ring created inside oce_cq_create, oce_queue.c:892-896) leaks, and sc->cq[sc->ncqs-1] (assigned in oce_cq_create:910) keeps pointing at it.

2. oce_mbox_post() / firmware status fails -> goto error (oce_queue.c:735-741) -> same oce_mq_free(mq) path: - the mq ring IS destroyed, but mq->cq is still NULL, so the CQ again leaks.

Only the third failure path (kmalloc of mq itself, oce_queue.c:681-685) correctly calls oce_cq_del(sc, cq) before jumping to error.

Consequences

• One-time leak of sizeof(struct oce_cq) + a CQ DMA ring (CQ_LEN_256 x sizeof(struct oce_mq_cqe) = 256 x 16 = 4 KiB DMA memory plus bus_dma tag/map) per failed oce_mq_create invocation.
• sc->ncqs stays incremented with a live pointer to the leaked CQ; nothing in the tree iterates sc->cq[] after oce_queue_release_all (checked: the for_all_cq_queues consumer macro has no callers in the teardown path), so this is a leak, not a UAF.
• Trigger: requires the Emulex OneConnect firmware to fail CREATE_MQ_EXT (or a DMA ring alloc failure) during driver attach. No unprivileged-user reachability; no network reachability (mailbox command, attach-time only).

Why PoC was not run

• The audit QEMU guest has no Emulex BE2/BE3/Lancer hardware, so oce(4) never attaches (pciconf -l shows no Emulex vendor 0x19a2 device) — the failure path cannot be entered on the guest.
• Severity is Info (error-path resource leak, no security impact), which the audit contract exempts from mandatory PoC verification.
• Root cause is established by direct code reading with line-accurate accounting of every goto path (see VERDICT.md).

Fix

One-line move: assign mq->cq = cq immediately after the CQ is created so that oce_mq_free()'s existing if (mq->cq != NULL) oce_cq_del(...) (oce_queue.c:796-799) handles every error path. See fix.diff.

DF-4420 VERDICT

Status: untested (Info-severity leak; PoC exempt per contract — no oce hardware on the verification guest). Confidence in the bug itself: certain (every goto path traced below).

Path-by-path trace of oce_mq_create (sys/dev/netif/oce/oce_queue.c:662-762)

cq = oce_cq_create(sc, eq, CQ_LEN_256, sizeof(struct oce_mq_cqe), 1, 1, 0, 0); (oce_queue.c:675-678) -> on success cq owns a DMA ring and is registered in sc->cq[sc->ncqs++] (oce_queue.c:910 inside oce_cq_create).

mq->cq = cq is only executed on the success path (oce_queue.c:744), which is why the CQ block in oce_mq_free never fires on the two leaking paths.

Downstream: sc->mq = oce_mq_create(...) in oce_queue_init_all (oce_queue.c:150) receives NULL, goto error -> oce_queue_release_all — sc->mq is NULL so mq_free is skipped there too (oce_queue.c:189-190). The leaked cq is never referenced again: the only iterators of sc->cq[] are for_all_cq_queues (no callers — verified by grep across sys/) and oce_hw_update_multicast-style paths that do not run on this failure path. No UAF; pure leak.

Not-testable-on-guest justification

• Guest uname: DragonFly dfbsd 6.5-DEVELOPMENT #0 ... X86_64_GENERIC
• pciconf -lv / dmesg on the guest: no vendor 0x19a2 (Emulex) device; oce driver never attaches, so neither the happy path nor the error path is reachable on the verification guest.
• Per the audit contract, Low/Info findings are exempt from mandatory PoC; this is filed as Info precisely because the only trigger is a firmware/mailbox failure during attach on real hardware.

Fix validation

fix.diff moves mq->cq = cq up to right after the CQ creation so the existing cleanup in oce_mq_free covers all paths (the !mq path still deletes cq itself before mq exists, so no double-free). Not built on the guest for the same hardware reason — the change is a one-line pointer assignment reorder with no control-flow change, reviewed against all four paths in the table above.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.