# DF-3679 — igb_rxeof trusts NIC-DMA'd RX descriptor length (no buffer bound)

## What
`igb_rxeof()` reads the receive descriptor write-back length
(`cur->wb.upper.length`, 16-bit, DMA-written by the NIC) and assigns it
directly to the freshly posted mbuf without clamping it to the posted
buffer size:

- `sys/dev/netif/igb/if_igb.c:2744` — `len = le16toh(cur->wb.upper.length);`
- `sys/dev/netif/igb/if_igb.c:2768` — `mp->m_len = len;`
- `sys/dev/netif/igb/if_igb.c:2770` / `:2776` — `m_pkthdr.len = len` / `+= len`

The posted buffer (`igb_newbuf`, `sys/dev/netif/igb/if_igb.c:2415-2460`) is a
single `MCLBYTES` (2048-byte) cluster, front-trimmed by `ETHER_ALIGN` (2) when
`max_frame_size <= MCLBYTES - ETHER_ALIGN` (`:2433-2434`), i.e. an effective
capacity of 2046 bytes for MTU <= 2028.

A descriptor length larger than the posted buffer (possible on descriptor
corruption, device fault/erratum, or a malicious device — e.g. SR-IOV VF
assigned to an untrusted guest writing back crafted descriptors, or
Thunderbolt/PCIe attached attack hardware) makes `m_len`/`m_pkthdr.len`
describe up to 65535 bytes. The network stack (`ether_input`, IP/TCP parsing,
BPF taps) then walks past the end of the 2046/2048-byte cluster → kernel heap
OOB read of up to ~63.5 KB (info leak / panic). Chained (jumbo) frames
additionally accumulate unvalidated `len` into `m_pkthdr.len` across the chain.

Same defect family as DF-3604 (bce), DF-3639 (bnx), DF-3663 (bge), DF-3667 (ix).

## Reproduce / verify
Requires an igb(4) NIC (Intel 82575/82576/82580/I210/I211/I350/I354). The
QEMU audit guest has no igb hardware (virtio `vtnet0` only) — see `run.log`
for the module-presence / device-absence proof. Source-level verification
only; see `VERDICT.md`.

## Expected result (on hardware)
Descriptor write-back with `wb.upper.length` > posted buffer size causes the
stack to read past the RX cluster (leak/panic); with the fix the frame is
counted as an input error and discarded.