# DF-3639 — bnx(4) RX length trust (bge_len) — evidence pack

**What:** `bnx_rxeof()` (sys/dev/netif/bnx/if_bnx.c:2848) assigns
`m->m_pkthdr.len = m->m_len = cur_rx->bge_len - ETHER_CRC_LEN` from the
NIC-DMA'd return-ring descriptor with **no bound against the 2046-byte
usable cluster** and no lower bound.

**Impact (hardware-conditional):** faulty/malicious BCM5717/5719/5720/577xx
hands the stack an mbuf describing up to 65531 bytes in a 2048-byte cluster →
kernel heap OOB read of up to ~63.5 KB disclosed via bpf
(sys/net/if_ethersubr.c:1512) and the IP stack. `bge_len < 18` variant is
dropped harmlessly by ether_input (if_ethersubr.c:1499-1503).

**Reproduce (audit guest — honest negative):**
```
  cc -O -Wall -o trigger trigger.c     # guest; builds clean
  ./run.sh                             # via dfbsd-qemu/vm.sh run_root
```
Expected on the audit guest: trigger prints the hardware precondition;
evidence block shows `pci/if_bnx` in the kernel, `NO_BROADCOM_DEVICE`,
`ifconfig -l` = `vtnet0 lo0`, `sysctl hw.bnx` unknown oid, and
`/usr/src/sys/dev/netif/bnx/if_bnx.c` md5 identical to the audited tree
→ runtime verdict `inconclusive` (source-level certainty).

**On real hardware:** force the device to write `bge_len = 65535` (error flag
clear) into an RX return-ring BD (modified firmware / malicious peripheral /
erratum), then `tcpdump -i bnx0 -w out.pcap` — captured frames exceed 2046
bytes and contain adjacent kernel heap.

**Fix:** `fix.diff` (drop out-of-range frames, bounded by the mbuf's own
posted length). Not runtime-validatable on this guest (no bnx hardware).

Files: VERDICT.md (full narrative), trigger.c, build.sh/run.sh,
build.log/run.log (untrimmed guest transcripts), env.txt, manifest.json,
verdict.json.