DF-3667 — ix(4) ix_rxeof trusts NIC-DMA'd descriptor length: unbounded m_len → heap OOB read

File: sys/dev/netif/ix/if_ix.c · Severity: Medium · Class: RX-descriptor length trust (DF-3604/DF-3639/DF-3663 family)

Build / Run (bound-math demonstration harness)

cc -O2 -Wall -o df3667_sim df3667_sim.c
./df3667_sim

The harness is a userspace simulation (clearly labeled in source) replicating the exact assignment chain of ix_rxeof() with the real cluster sizes. It is evidence for the bound arithmetic, NOT a kernel reproduction — the guest has no ixgbe NIC, so the kernel path cannot run there.

Expected output

DF-3667 ix_rxeof descriptor-length trust — bound math
cluster(MCLBYTES)=2048      desc len=0xffff  claimed m_len=65535  OOB read span=63487 bytes
cluster(MJUMPAGESIZE)=4096  desc len=0xffff  claimed m_len=65535  OOB read span=61439 bytes
redzone bytes a consumer would hand to the stack (2K cluster): 63487
m_pkthdr.len accumulator (single desc): 65535  (chain adds per desc, if_ix.c:3044)
modest lie 3000 -> 2048 cluster: OOB span=952

Fix validation (compile-level)

fix.diff was applied to the guest's /usr/src (byte-identical to the audit tree, md5-verified) and the driver built as a module with -Werror:

cd /usr/src/sys/dev/netif/ix && make obj && make     # baseline: build_baseline.log
patch -p1 < fix.diff (from /usr/src)                 # patched: build_patched.log
cd /usr/src/sys/dev/netif/ix && make clean && make   # -> if_ix.ko, 0 errors/0 warnings

Runtime behavioral validation is impossible on this guest (no 10GbE hardware).

Guest state

env.txt — ix(4) compiled into the running X86_64_GENERIC kernel (config line 217), no Intel 82598/X540/X550 PCI device present, dev.ix.* sysctl count 0. Verdict: inconclusive (hardware absent), source-level certain.

DF-3667 — VERDICT

Status: inconclusive (runtime) / source-level certain. Impact class: kernel info leak (heap OOB read) via malicious-NIC DMA. No guest reproduction possible — no ixgbe hardware.

Root cause (path:line into the audited tree)

ix_rxeof() reads the NIC-written RX completion descriptor and publishes its 16-bit length into the mbuf with no bound against the cluster actually posted for that descriptor:

• sys/dev/netif/ix/if_ix.c:2974 — len = le16toh(cur->wb.upper.length); (wb.upper.length is DMA'd by the NIC into the descriptor ring.)
• sys/dev/netif/ix/if_ix.c:3031 — mp->m_len = len;
• sys/dev/netif/ix/if_ix.c:3040 — mp->m_pkthdr.len = len;
• sys/dev/netif/ix/if_ix.c:3044 — rxbuf->fmp->m_pkthdr.len += len; (chain)

The backing cluster is allocated at:

• sys/dev/netif/ix/if_ix.c:4142 — m_getjcl(flags, MT_DATA, M_PKTHDR, rxr->rx_mbuf_sz);
• sys/dev/netif/ix/if_ix.c:2635-2638 — rx_mbuf_sz = MCLBYTES (2048) when max_frame_size <= MCLBYTES, else MJUMPAGESIZE (4096). Note: SIOCSIFMTU allows MTU up to IX_MAX_MTU = 9710 (if_ix.h:101), so 4096 is the largest cluster ever posted — there is no MJUM9BYTES/MJUM16BYTES branch in this driver.

There is no len > rx_mbuf_sz (or len - ETHER_CRC_LEN) guard anywhere in ix_rxeof — contrast the bge/bnx/bce family fixes from this same audit (DF-3663:3138, DF-3639:2848, DF-3604:4396).

Threat model

The descriptor write-back is produced by the NIC via DMA. A compromised or malicious peripheral (Thunderclap-style DMA attack, malicious FW/NVM on the card, or a buggy NIC erratum writing an inconsistent wb.upper.length) fully controls len. Nothing on the host validates it. mp->m_len = len then hands the network stack an mbuf claiming up to 65535 valid bytes inside a 2048/4096 byte cluster; every downstream consumer (ether_demux, ip_input, BPF taps, forwarding, m_copydata-style parsers) reads kernel heap beyond the cluster: up to 63,487 bytes of adjacent kernel heap per descriptor are exposed to parsing/leak paths, and m_pkthdr.len accumulation (3044) compounds it for multi-descriptor frames.

This is not remotely triggerable by a packet alone — the NIC must misreport the length; the NIC is the trust boundary being violated. Same treatment as the bge/bnx/bce family findings (Medium, certain, kernleak).

What was verified, and how

1. Source-level certainty: full read of ix_rxeof() (if_ix.c:2948-3100) — no bound exists between the length read (2974) and the mbuf publication (3031/3040/3044). Cluster sizing confirmed at 2635-2638/4142 and sys/sys/param.h:473,497 (MCLBYTES=2048, MJUMPAGESIZE=4096).
2. Bound-math demonstration (userspace, guest): df3667_sim.c replicated the assignment chain with poisoned redzones; ran on the audit QEMU guest (run.log): desc len=0xffff -> m_len=65535 in a 2048 cluster ⇒ 63,487-byte OOB span. This is arithmetic evidence only — the kernel path itself did not execute.
3. Module presence: ix(4) is compiled into the running kernel (X86_64_GENERIC line 217, env.txt), so the vulnerable code ships in the default kernel of this system; no Intel 10GbE PCI device exists on the guest (pciconf -l, dev.ix.* count 0), so ix_attach/ix_rxeof never runs.
4. Fix validation (compile-level): fix.diff adds if (len > rxr->rx_mbuf_sz) { ierrors++; ix_rx_discard(...); goto next_desc; } after eop is computed. Applied to the guest's /usr/src copy (md5-identical to the audit tree) → if_ix.ko rebuilt with -Werror, zero errors/warnings (build_patched.log vs build_baseline.log). The local sys/ tree was never modified. An earlier draft of the hunk placed the check before eop is computed and the -Werror build caught it (maybe-uninitialized) — final hunk placement is after the --count line.

Why not reproduced / why no exploit chain

Escalation to uid=0 requires the memory-corruption primitive to be exercisable; exercising it requires a DMA-capable adversary on the PCIe bus (or a NIC whose firmware misreports lengths). The guest has no such device and QEMU (TCG/KVM q35) has no 82599/X540 model to instantiate, so neither a leak nor a panic can be triggered at runtime. Verdict is therefore inconclusive per the honest status taxonomy (device absent), with confidence: certain on the source-level defect and its impact class.

Recommended fix

fix.diff in this pack (bound the descriptor length to rx_mbuf_sz, discard the frame on violation). Mirrors the fixes already carried for bge/bnx/bce in this audit.

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.