# DF-3663 — bge_rxeof trusts NIC-DMA'd return-ring bge_len with no buffer bound

## Build / Run / Expected

```
./build.sh          # cc -O -Wall -o trigger trigger.c   (in a DragonFly guest)
./run.sh            # runs the trigger + records the guest-side reachability proof
```

**Expected on real BCM57xx hardware** (NOT available in this environment):
the device DMAs an RX return-ring BD with `bge_len` larger than the posted
buffer (2046 std / 9016 jumbo usable bytes) and error flags clear;
`bge_rxeof` (sys/dev/netif/bge/if_bge.c:3144) hands the stack an mbuf whose
`m_len`/`m_pkthdr.len` is up to 65531 inside that small buffer. Any bpf(4)
listener (`tcpdump -i bge0 -w out.pcap`) then receives up to ~63.5 KB of
kernel heap adjacent to the RX cluster — a kernel info disclosure. On i386
builds the `BGE_FLAG_RX_ALIGNBUG` path (if_bge.c:3138-3141) first *writes*
that many bytes past the cluster (heap overflow).

**Actual on the audit guest**: no Broadcom PCI device exists (virtio-net
only), so `bge_attach`/`bge_rxeof` are unreachable — the trigger builds
clean and prints its hardware-precondition notice (run.log). Verification
is therefore honestly **inconclusive** (source-level certain; see
VERDICT.md).

## Files
- `trigger.c` — annotated hardware-precondition trigger
- `run.log` — guest proof: `pci/if_bge` compiled into the kernel,
  `NO_BROADCOM_DEVICE`, `ifconfig -l` = `vtnet0 lo0`, `sysctl hw.bge`
  unknown, /usr/src md5 == audited tree, clean build, trigger output
- `fix.diff` — git-apply-able clamp-and-drop (bounds the NIC length by the
  mbuf's own posted length before ANY use, including the i386 ALIGNBUG
  bcopy)
- `verdict.json` / `manifest.json` — machine verdict