# DF-3593 — Duplicate firmware TX-done re-completes a freed TX slot (NULL-deref / KASSERT panic + ring accounting underflow)

## Build / Run / Expected

No runtime trigger exists on the audit guest (virtio-only, no Broadcom card):

```
# on the DF guest, as root:
sh probe.sh
```

Expected output (what we got): driver resident (`hw.bwn.*` sysctls live, compiled into
X86_64_GENERIC), INVARIANTS enabled, **NO Broadcom wireless PCI device** — the
TX-completion interrupt path cannot execute. Verification is therefore
source-level certain; runtime classification is `inconclusive` (hardware absent).

On a machine with a BCM43xx card whose firmware emits a duplicate TX-done event
(the driver's own comment, `if_bwn.c:7088-7091`, states this happens in the
field), the expected observation is an immediate kernel panic:

* INVARIANTS kernels (stock DF `X86_64_GENERIC`, `sys/config/X86_64_GENERIC:56`):
  `panic: kassert "/sys/dev/netif/bwn/bwn/if_bwn.c:5996: fail"` (DMA mode) or
  `if_bwn.c:6021: fail`.
* non-INVARIANTS kernels: NULL-pointer dereference fatal page fault in
  `bwn_dma_handle_txeof` (`meta->mt_ni->ni_vap`, `if_bwn.c:6012`) or
  `bwn_pio_handle_txeof` (`tp->tp_m->m_pkthdr.len`, `if_bwn.c:6052`).

## Trigger precondition

1. bwn(4) attach of a BCM43xx device (DMA or PIO mode — PIO via PCMCIA or
   `hw.bwn.usedma=0`).
2. Firmware raises `BWN_INTR_TX_OK` a second time for a cookie whose slot pair
   was already completed — i.e. two `bwn_intr_txeof` iterations delivering the
   same cookie. The in-tree comment at `if_bwn.c:7088-7091` documents exactly
   this hardware behavior ("sometimes H/W returns TX DONE events duplicately").
   A malicious/compromised mini-PCIe card can synthesize it at will.