# DF-3712 — 2-byte DMA heap overflow in em(4) RX when MTU in (1500, 2028]

**File:** `sys/dev/netif/em/if_em.c` (Intel e1000 8254x driver, 7.6.2)
**Lines:** 3376-3379 (`em_newbuf` trim), 3607-3632 (`em_init_rx_unit` RCTL), 684 (`rx_buffer_len`), 1225-1281 (`em_ioctl` SIOCSIFMTU)
**Family:** identical bug pattern to DF-1197 (emx, `sys/dev/netif/emx/if_emx.c:2918`)

## Reproduce on a box with real em(4) hardware

```
# 1. root puts the interface in the dangerous MTU window (any value in
#    (1500, 2028]; jumbo-capable switch path or direct attach):
ifconfig em0 mtu 2000 up

# 2. any unauthenticated peer on the same L2 segment sends one frame
#    larger than 2048 bytes (e.g. a 3000-byte UDP/ICMP datagram):
ping -s 2900 -M do <host-behind-em0>       # or scapy sendp(Ether()/IP()/Raw('A'*2950))
```

**Expected on vulnerable driver:** the NIC (RCTL SZ_2048 + LPE) splits the
frame across receive descriptors; the first descriptor's buffer is filled
with 2048 bytes at `cluster+2` (ETHER_ALIGN front-trim) — the final 2 bytes
of the fill land 2 bytes past the 2048-byte mbuf cluster (attacker-
controlled frame bytes), corrupting the adjacent kernel heap object.

## On this audit guest

No em hardware exists (virtio only). `run.sh` performs the module/device
presence probe; `run.harness.log` is a userspace bound-math replica of the
exact posting/fill arithmetic (compiled and executed on the guest,
`build.sh`), which demonstrates the 2-byte overrun with a poisoned redzone.

## Build (guest)

```
sh build.sh      # cc -O -o em_bounds_harness em_bounds_harness.c
./run.sh         # runs harness + device-absence probe
```