DF-3604 — bce(4) bce_rx_intr trusts NIC-reported l2_fhdr_pkt_len (no MCLBYTES bound) → kernel heap OOB read / unsigned underflow

• File: sys/dev/netif/bce/if_bce.c (pass 2, GLM 5.3)
• Severity: Medium · Confidence: certain (code fact) · CWE-125 / CWE-191
• Status: inconclusive (runtime) — the audit guest has no Broadcom NetXtreme II hardware; the trigger is device-dependent. Source-level verification is complete and certain.

Build / Run

./build.sh     # cc -o trigger trigger.c  (documentation/canary skeleton)
./run.sh       # guest-side environment proof (module present, no device)

Expected output (on hardware-less guest)

run.sh shows:

• pci/if_bce registered in the kernel (driver code compiled in),
• kldload if_bce → "module already loaded or in kernel",
• NO_BROADCOM_DEVICE / NO_BCE_PCIID — only virtio PCI devices,
• ifconfig -l → vtnet0 lo0,
• NO_BCE_SYSCTL — no attach happened, no hw.bce.* tree exists.

On a guest with a BCM5706–5716 NIC, a device reporting l2_fhdr_pkt_len > MCLBYTES (or < ETHER_CRC_LEN) yields an mbuf whose m_len exceeds the 2048-byte cluster ⇒ heap over-read of up to ~63.5 KB into packets handed to the stack (info leak) or an immediate panic (underflow case / unmapped-page walk).

Root cause (path:line)

• sys/dev/netif/bce/if_bce.c:4396 — len = l2fhdr->l2_fhdr_pkt_len; (l2fhdr lives at the start of the RX mbuf cluster and is written by the NIC via DMA; the only "validation" is the hardware's own error bits checked at :4402).
• sys/dev/netif/bce/if_bce.c:4399 — len -= ETHER_CRC_LEN; on an unsigned int: pkt_len ∈ {0..3} wraps to ~4×10⁹.
• sys/dev/netif/bce/if_bce.c:4437-4439 — m_adj(m, 18) then m->m_pkthdr.len = m->m_len = len; — no comparison against MCLBYTES (2048) or against the posted BD length anywhere on the path.
• The RX cluster is allocated/programmed at:
• sys/dev/netif/bce/if_bce.c:3851-3855 (m_getcl, m_len = MCLBYTES),
• sys/dev/netif/bce/if_bce.c:2298-2301 (RX DMA tag maxsize = MCLBYTES),
• sys/dev/netif/bce/if_bce.c:3905 (rx_bd_len = MCLBYTES posted to the NIC).

Why this matters even though the NIC is "trusted"

A compliant NIC cannot DMA more than the posted BD length, but the driver's job on the receive path is to not hand the stack an mbuf that describes more data than the buffer holds. One faulty firmware push, a malicious peripheral (PCIe attach / Thunderclap class), or a chip erratum converts this into a kernel heap info leak (leaked bytes are deliverable to an unprivileged user via a raw socket / pcap) or a trivial panic (underflow). The DragonFly tree itself treats the identical pattern as a finding in every comparable driver (pass-1 DF-1478 my, DF-1481 vr, DF-1490 tx, DF-1514 ste, DF-1519 lge, DF-1562 pcn, DF-1351 nfe — all "NIC length trusted without MCLBYTES bound", all Medium). Linux's sibling driver (bnx2) clamps before skb_put; this driver does not.

Fix

fix.diff — drop the frame (count ierrors, recycle the buffer) when pkt_len is outside [sizeof(l2_fhdr) + ETHER_ALIGN + ETHER_CRC_LEN, MCLBYTES], before the subtraction. Zero-cost in the common case (two compares).

DF-3604 VERDICT — bce_rx_int trusts l2_fhdr_pkt_len (heap OOB read path)

Status: inconclusive (runtime) · source-level: certain Impact ceiling: kernel heap OOB read (info leak, up to ~63.5 KB per frame) / panic via unsigned underflow.

What was verified, and how

1. Source-level verification (certain)

Read the full RX path in sys/dev/netif/bce/if_bce.c (guest /usr/src copy is byte-identical to the audited tree — md5 786cd4c4a8e26f5eab0c12c3987f68b9 both sides):

• RX buffers are single 2048-byte mbuf clusters:
• if_bce.c:3851 m_new = m_getcl(...) / :3855 m_new->m_len = m_new->m_pkthdr.len = MCLBYTES;
• sys/sys/param.h:497 MCLBYTES = (1 << 11) == 2048
• if_bce.c:2298-2301 RX DMA tag created with maxsize/nmaxseg = MCLBYTES, MCLBYTES; :3905 posts rx_bd_len = MCLBYTES.
• The only length source for the handed-up frame is the DMA'd header:
• if_bce.c:4394 l2fhdr = mtod(m, struct l2_fhdr *);
• if_bce.c:4396 len = l2fhdr->l2_fhdr_pkt_len; (16-bit field, NIC-written; if_bcereg.h:845)
• if_bce.c:4399 len -= ETHER_CRC_LEN; — len is unsigned int; pkt_len < 4 wraps to ≈4 GB.
• if_bce.c:4402-4414 the only sanity gating is the NIC's own l2_fhdr_status error bits — i.e. trusting the same producer.
• if_bce.c:4437-4439 m_adj(m, sizeof(struct l2_fhdr) + ETHER_ALIGN) (=18) then m->m_pkthdr.len = m->m_len = len;
• No clamp exists anywhere on this path. A pkt_len of 65535 yields m_len = 65531 on a 2048-byte cluster ⇒ up to 63507 bytes of heap over-read when the stack consumes the mbuf (ether_input → IP reassembly/forwarding/socket copy; bytes land in user-visible packets). A pkt_len of 0–3 yields m_len ≈ 4 GB ⇒ immediate OOB walk → panic (local DoS from the frame's mere presence).

Cross-checked ring math so nothing else bounds it: sw indices are masked (RX_CHAIN_IDX, if_bcereg.h:5678, TOTAL_RX_BD = 256*pages ⇒ clean power-of-two masks), and bce_get_hw_rx_cons (if_bce.c:4301-4309) normalizes pointer slots — none of this constrains pkt_len.

2. Guest runtime verification (why inconclusive, not reproduced)

Audit guest: DragonFly 6.5-DEVELOPMENT #0 (X86_64_GENERIC), virtio-net only. run.sh / run.log evidence:

• driver code present in the running kernel (kldstat -v → pci/if_bce; kldload if_bce → "module already loaded or in kernel"),
• no Broadcom PCI device: pciconf -lv shows only QEMU virtio devices (NO_BROADCOM_DEVICE, NO_BCE_PCIID),
• ifconfig -l → vtnet0 lo0; sysctl hw.bce.* → none (no attach).

⇒ bce_attach() never runs ⇒ bce_rx_intr() is unreachable on this guest. The trigger requires BCM5706/5708/5709/5716 silicon with device-side control of l2_fhdr_pkt_len (malicious/faulty NIC firmware, hostile peripheral, or chip erratum). Per the honest-status table this is "guest reachable but the target device/feature is absent" ⇒ inconclusive (source-certain, hardware-absent).

3. Exploit chain (what it would look like on hardware)

1. Compromised/malicious NIC DMAs a frame with l2_fhdr_pkt_len = 65535 (error bits clear) into a posted 2048-byte cluster.
2. bce_rx_intr hands the stack an mbuf with m_len = 65531 (if_bce.c:4439).
3. Unprivileged local user runs a packet sniffer (raw bpf socket on bce0) and receives up to ~63 KB of kernel heap following the cluster — heap info leak (slab metadata, other packets, pointers ⇒ defeats no-KASLR is irrelevant, but leaks live object data). OR pkt_len = 0 ⇒ m_len ≈ 4 GB ⇒ guaranteed panic (DoS).

Not further escalatable to a write primitive from this bug alone (the over-read is consumer-side; the NIC's own DMA is bounded by the posted BD). Ceilings: info leak + local DoS, exactly the class of the pass-1 peer findings (DF-1478/DF-1481/DF-1490/DF-1514/DF-1519/DF-1562).

Fix validation

fix.diff applies the clamp (drop + recycle on out-of-range pkt_len). Not runtime-testable on this guest (no device — same reason as above); kernel build validation also skipped: the GENERIC kernel already compiles this driver, and the patch adds two compares + an error branch using only existing symbols (MCLBYTES, ierrors, bce_setup_rxdesc_std, bce_rx_int_next_rx) — reviewed against the surrounding error paths at if_bce.c:4402-4414 which use exactly this recovery idiom. fix_status = not_testable (hardware absent).

Artifacts

• trigger.c — annotated trigger/canary skeleton (documents the exact device-side precondition).
• build.sh, run.sh — exact commands.
• run.log — full untrimmed guest output proving driver-present / device-absent.
• env.txt — guest uname, PCI inventory, kldstate, source md5.
• fix.diff — the clamp.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.