DF-1410 — xe(4) RX length missing upper bound (heap overflow)

Verdict

REPRODUCED (source-level harness). The bug is real; impact ceiling is remote (unauthenticated, same-L2-segment) heap overflow of a 2 KiB mbuf cluster, with overflow sizes from ~6 KiB (long packet) up to ~63 KiB (RBC<4 unsigned wrap). The kernel code path cannot be exercised on this guest because QEMU does not emulate any PCMCIA bridge or the Xircom CE hardware — xe0 does not exist in pciconf -lv. The fix.diff applies cleanly and nativekernel succeeds (rc=0); no run-time exercise is possible because the device is absent.

Mechanism (sys/dev/netif/xe/if_xe.c)

1. Line 750: u_int16_t len;
2. Line 752: len = XE_INW(XE_RBC) - ETHER_CRC_LEN; — no mask against XE_RBC_BYTE_COUNT (if_xereg.h:269, 0x1FFF) so the 3 flag bits in the high half contaminate the count; no upper-bound check vs MCLBYTES (2048); no lower-bound check that RBC >= ETHER_CRC_LEN, so an RBC value of 0..3 wraps to len = 0xFFFC..0xFFFF.
3. Lines 775-782: MCLGET attaches a 2 KiB cluster; line 784 m_data += 2 reduces the usable window to MCLBYTES - 2.
4. Lines 822/826: bus_space_read_multi_2(bst, bsh, XE_EDP, ehp, (len+1)>>1) copies 2*ceil(len/2) bytes from the card into that cluster window — for any oversized or wrapped len, this writes thousands of bytes past the cluster into the adjacent kernel heap.

Sibling drivers (dc, fxp, rl, etc.) all mask their RX-length register and bound against MCLBYTES; xe is the outlier.

Harness proof (harness.c)

Uses the genuine register layout (XE_RBC_BYTE_COUNT = 0x1fff), the genuine len = RBC - ETHER_CRC_LEN arithmetic, and the genuine (len+1)>>1 word count. 4 of 7 representative inputs (silicon-long 8184 B packet, plus RBC=0/1/3 wraps) produce overflows of 6 KiB..63 KiB. The fixed variant (mask + range-check) accepts the legitimate packets and rejects the oversized/wrapped ones:

case                                RBC  bug_len    oob_B  fix_len    oob_B
silicon long 8184B packet          8184     8180     6134       -1        0
RBC=0  (wrap to 0xFFFC)               0    65532    63486        0        0
RBC=1  (wrap to 0xFFFD)               1    65533    63488        0        0
RBC=3  (wrap to 0xFFFF)               3    65535    63490        0        0
Buggy driver: 4/7 cases overflow the 2KiB mbuf cluster

Exploit-chain note

This is a remote unauthenticated heap-overflow primitive on real hardware. QEMU has no Xircom PCMCIA device, so the kernel-side chain cannot be exercised here. On a deployed Xircom CE2 system, every received long packet (8 KiB) or underflowed RBC corrupts adjacent heap deterministically; this is a credible remote heap-grooming → kernel-code-exec primitive in a real deployment. Documented as primitive characterization; impact ceiling is remote heap corruption.

PoC changes

• Original PoC folder had no source (build.sh/run.sh were placeholders).
• Added harness.c plus repro scripts, env, build/run logs, fix.diff, VERDICT.md, manifest.json.

Fix

fix.diff masks XE_RBC against XE_RBC_BYTE_COUNT, requires len >= ETHER_CRC_LEN, and rejects len - ETHER_CRC_LEN > MCLBYTES - 2 - 1 before attaching the cluster. This matches the pattern every sibling NIC driver uses. Matches the finding markdown proposal.

Fix-validation

patch -p1 --forward succeeds (hunk #1 at line 749). nativekernel completes with rc=0 (saved as fix_build.log). The kernel-side before/after cannot be exercised because the device is absent → fix_status: "not_testable". The diff is verified to apply and compile, and the changed logic is traced to close the cited overflow.