# DF-4052 VERDICT — [i]-vs-[j] typo in ring-allocation error paths

## Status: untested (source-certain; Low severity; OOM + hardware gated)

- `if_nfe.c:1725-1726` and `:1988-1989`: cleanup loops
  `for (j = 0; j < i; ++j) bus_dmamap_destroy(ring->data_tag, ring->data[i].map);`
  destroy the *failing* slot's map (`[i]`) `i` times instead of the `i`
  successfully-created maps (`[0..i-1]`).
- Verified semantics that bound the impact:
  - `bus_dmamap_create` writes `*mapp = NULL` before returning error
    (`sys/platform/pc64/x86_64/busdma_machdep.c:425-433`) → destroying
    `data[i].map` is a NULL no-op → **leak**, not double-free (an early
    audit hypothesis, refuted by reading busdma).
  - `bus_dmamap_destroy` still does `dmat->map_count--` for NULL maps
    (`busdma_machdep.c:440-448`) → tag map-count underflow by `i`.
- Trigger: kmalloc failure inside `bus_dmamap_create` mid-ring during
  `nfe_attach` (memory-pressure-gated) → attach fails, `nfe_detach` runs,
  and `i` dmamaps (~64-88 bytes each) plus the bogus tag count persist.
  Repeatable per attach attempt.
- No memory-safety consequence demonstrated; classic error-path resource
  leak. Low severity, confidence certain, not runtime-verifiable on this
  guest (no nForce NIC; inducing the OOM inside attach is not possible
  without the device).

## 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.