DF-4325 — sf(4) TX completion index OOB (arbitrary m_freem)

File: sys/dev/netif/sf/if_sf.c:998-1013 (sf_txeof)

cur_cmp->sf_index is a 15-bit byte-offset DMA-written by the AIC-6915 into the TX completion queue. The driver does cur_tx = &sf_tx_dlist[sf_index >> 7] with no bounds check against SF_TX_DLIST_CNT (128). Values >= 16384 (possible up to 32767) index entries 128..255 — 16..32KB from the ring base — reading an sf_mbuf "pointer" from unrelated ring memory and feeding it to m_freem(), NULL-writing it, and decrementing sf_tx_cnt below zero.

Build (guest with /usr/src)

cp /usr/src/sys/dev/netif/sf/if_sfreg.h /root/kmod/sfring/
cd /root/kmod/sfring && make SYSDIR=/usr/src/sys
kldload ./sf_ring_harness.ko

Run / expected

sysctl kern.sfrh.run=1   # log-only: OOB read value, NULL write, tx_cnt -1
sysctl kern.sfrh.run=2   # REAL m_freem(0xdeadc0de0000) -> kernel panic

Expected (mode 2, captured in panic.txt): sfrh[tx]: mode 2: calling REAL m_freem(0xdeadc0de0000) ... Fatal trap 9: general protection fault while in kernel mode Stopped at m_free+0x10: movswq 0x20(%rdi),%rax

gcc itself proves the index OOB at build time (-Warray-bounds, build.log).

No sf(4) hardware exists on the audit guest; the harness reproduces the exact descriptor-processing code path with DMA-provided values planted directly.

DF-4325 — verdict: REPRODUCED (harness on live kernel; hardware-gated path)

Root cause (path:line)

• sys/dev/netif/sf/if_sf.c:998 — cur_tx = &sc->sf_ldata->sf_tx_dlist[cur_cmp->sf_index >> 7]; sf_index is u_int32_t sf_index:15 (if_sfreg.h:899-904), i.e. 0..32767; >> 7 yields 0..255; sf_tx_dlist has SF_TX_DLIST_CNT = 128 entries (if_sfreg.h:781). The value is DMA-written by the NIC (completion queue).
• if_sf.c:1008-1013 — the OOB-read cur_tx->sf_mbuf is passed to m_freem(), then NULL-written; sc->sf_tx_cnt-- per iteration can underflow to negative.

What was proven on the guest

1. Static proof: gcc -Werror=array-bounds rejects the harness build with the literal driver expressions: "array subscript 255 is above array bounds of 'struct sf_tx_bufdesc_type0[128]'" (build.log). The driver compiles only because its index is a runtime DMA value.
2. Runtime OOB read+write+underflow (kern.sfrh.run=1, run.log): sf_index=0x7ff8 -> idx 255 -> OOB READ at +16256 past the ring (inside the sf_rx_clist region): reads planted 0xdeadc0de0000; OOB NULL WRITE at the same offset; sf_tx_cnt 0 -> -1.
3. Wild-free primitive (kern.sfrh.run=2, panic.txt): REAL m_freem(0xdeadc0de0000) -> "Fatal trap 9: general protection fault", "Stopped at m_free+0x10: movswq 0x20(%rdi),%rax" — the kernel dereferenced the OOB-read value exactly as if_sf.c:1010 would.

Impact

Memory-corruption / arbitrary-free primitive gated on NIC-supplied completion data (compromised or faulty AIC-6915, or a PCIe/DMA fault): OOB pointer free (wild m_freem), NULL-poisoning of RX ring memory, and TX accounting underflow that later defeats the ring-full check (if_sf.c:1274). On hardware this is a kernel memory-corruption bug; realistic ceiling is host crash to heap corruption depending on adjacent allocations.

Why not uid=0: the trigger requires the sf(4) NIC itself (or its DMA) to emit the malicious descriptor; no such hardware exists on the audit guest, so the escalation chain could not be attempted beyond the demonstrated primitive.

Fix

Bounds-check the derived index before use and resync (fix.diff).

Fix validation

fix_status=not_testable: the fix lives in sf_txeof(), which only executes on AIC-6915 hardware the guest does not have; the harness replicates the driver code in its own module and therefore cannot observe a sys/ source change.

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.