# DF-4234 — txp(4) attach error path leaks the 256 `rb_sd` swdesc allocations (and ifmedia)

**File:** `sys/dev/netif/txp/if_txp.c` (pass 2)
**Severity:** Low (kernel memory leak, no attacker-reachable trigger — needs
a card whose firmware boots far enough to allocate rings but then fails the
boot-record handshake)

## The bug

`txp_alloc_rings()` (`if_txp.c:948-956`) kmallocs one `struct txp_swdesc`
per receive-buffer slot (256 × 16 B) and stores the pointers **only inside
the DMA-shared ring** (`sc_rxbufs[i].rb_sd`, which is `&sc->sc_ldata->
txp_rxbufs`). If the function later fails (`fw not running` /
`not waiting for boot`, `if_txp.c:972-991`), `txp_attach()` does
`goto fail` → `txp_release_resources()` (`if_txp.c:358-374`) frees irq, res
and the whole `sc_ldata` block — but not the 256 kmalloc'd swdescs, whose
only references lived inside `sc_ldata`. ~4 KB leaked per failed attach;
repeated reprobe cycles (devctl/`kldload` loops on a half-broken card)
accumulate.

Secondary asymmetry: after `ifmedia_init()` at `if_txp.c:284`, the
`bus_setup_intr` failure path (`if_txp.c:315-322`) calls `ether_ifdetach()`
but never `ifmedia_removeall()` (compare `txp_detach()` `:346`).

No PoC (Low, hardware-gated error path — trigger needs a 3c990 that fails
boot-record registration). Status `untested` per convention; the guest probe
run.log (shared with DF-4231) shows the driver is in the kernel and no 3Com
device exists.

## Fix

Free the swdescs in `txp_release_resources()` before freeing `sc_ldata`
(guarded by `sc_rxbufs != NULL`), and `ifmedia_removeall()` on the late
attach-failure path.
