# DF-4052 — nfe_alloc_{rx,tx}_ring error paths destroy data[i].map in a loop over j (maps 0..i-1 leak; tag map_count underflows)

## What

`sys/dev/netif/nfe/if_nfe.c`:

```c
static int
nfe_alloc_rx_ring(...)                    /* :1642 */
{
	...
	for (i = 0; i < sc->sc_rx_ring_count; i++) {
		error = bus_dmamap_create(ring->data_tag, BUS_DMA_WAITOK,
					  &ring->data[i].map);
		if (error) {
			...
			goto fail;
		}
	}
	return 0;
fail:
	for (j = 0; j < i; ++j)
		bus_dmamap_destroy(ring->data_tag, ring->data[i].map);   /* :1726 - [i], not [j]! */
	bus_dmamap_destroy(ring->data_tag, ring->data_tmpmap);
	...
```

The cleanup loop iterates `j` but destroys `ring->data[i].map` — the map at
the **failing** index, which `bus_dmamap_create` has already set to NULL on
error (`busdma_machdep.c:430`: `*mapp = NULL` before `return error`). Each
iteration is therefore a NULL no-op while the `i` successfully-created maps
(`data[0].map .. data[i-1].map`) are **leaked**; additionally
`bus_dmamap_destroy` decrements `dmat->map_count` unconditionally
(`busdma_machdep.c:440-448`), so the tag's map count underflows by `i` and
the later `bus_dma_tag_destroy` runs against a bogus count.

The identical typo exists in `nfe_alloc_tx_ring` (`:1987-1989`).

## Reachability

Requires `bus_dmamap_create` (a `kmalloc(M_DEVBUF)`) to fail mid-ring —
i.e. kernel-memory exhaustion during attach of an nfe(4) device — after
which attach aborts with the maps leaked forever (per attempt). Low
severity, OOM-gated, certain.

## Fix

```diff
-		bus_dmamap_destroy(ring->data_tag, ring->data[i].map);
+		bus_dmamap_destroy(ring->data_tag, ring->data[j].map);
```

in both functions (fix.diff).

## Verification

Source-certain (double-checked that a NULL map destroy is a no-op and that
`bus_dmamap_create` NULLs `*mapp` on failure, so this is a leak, not a
double-free). Not runtime-verified: needs nfe hardware + induced
kmalloc failure. Status: untested.