# DF-4111 — tl(4): tl_start ignores tl_encap() failure — mbuf leak, NULL-mbuf BPF tap, non-READY list chained into TX

## What this is

`tl_encap()` has exactly one failure path — the cluster allocation for
the >10-fragment collapse (special case #1):

```c
m_new = m_getl(m_head->m_pkthdr.len, M_NOWAIT, MT_DATA, M_PKTHDR, NULL);
if (m_new == NULL) {
        if_printf(&sc->arpcom.ac_if, "no memory for tx list\n");
        return (1);                 /* if_tl.c:1775-1777 */
}
```

`tl_start()` discards the return value and proceeds as if the descriptor
were armed:

```c
/* Pack the data into the list. */
tl_encap(sc, cur_tx, m_head);       /* if_tl.c:1856 — return ignored */
...
BPF_MTAP(ifp, cur_tx->tl_mbuf);     /* if_tl.c:1865 — tl_mbuf is NULL */
```

On failure `tl_encap` has assigned neither `c->tl_mbuf` (if_tl.c:1806
not reached) nor `tlist_cstat = TL_CSTAT_READY` (if_tl.c:1809 not
reached).  Consequences, all three from one ignored error:

1. **mbuf leak**: `m_head` is neither freed nor stored anywhere — one
   full packet cluster chain leaked per failure; sustained memory
   pressure + traffic converts this into mbuf-pool exhaustion (system
   wide DoS: `m_getcl` failures are exactly the condition that triggers
   more of this path).
2. **NULL mbuf into BPF**: `cur_tx->tl_mbuf` is NULL (tx entries are
   NULLed when recycled, if_tl.c:1493, and never assigned on the failed
   path).  `BPF_MTAP(ifp, NULL)` with at least one listener attached
   calls `bpf_mtap(bp, NULL)` (sys/net/bpf.c:1299), which dereferences
   the mbuf after its `bif_dlist` check — kernel NULL-deref panic.
3. **Garbage TX descriptor chained**: `cur_tx` is linked into the TX
   chain with a stale `tlist_cstat` (after tl_stop's bzero it is 0 — not
   READY) and up to 10 fragment entries pointing at the freed-by-caller
   nothing / previous packet data; if the chip is told to GO on this
   chain (head case) it walks a non-READY list — undefined behavior,
   watchdog recovery at best.

## Trigger

Any transmit through tl(4) while `m_getl(M_NOWAIT)` fails (transient
mbuf exhaustion — e.g. bursty RX under low-memory conditions, or an
attacker-induced mbuf shortage via socket queues).  The BPF panic
additionally needs a bpf listener on the interface.  Root-only BPF and
memory-pressure timing → Low severity.

## PoC status — untested (hardware absent)

Guest has no ThunderLAN device (presence_probe.sh, identical to
DF-4110's); `tl_start` never executes.  Source-level certainty.

## Fix

Check the return: free the packet, return the chain entry to the free
list, continue (fix.diff).