DF-3966 — rt2661_rx_intr trusts the device-fed 12-bit frame length against a 2 KB cluster: up to 2047-byte OOB read into ieee80211_input

File: sys/dev/netif/ral/rt2661.c (pass 2; no known findings on this file; rt2860 sibling knowns DF-3748..3753 do not cover rxeof length trust)

What

rt2661.c:1101–1102 sets m->m_pkthdr.len = m->m_len = (flags>>16)&0xfff straight from the DMA'd RX descriptor — up to 4095 — while the mbuf is a 2048-byte cluster (m_getcl at 1055; MCLBYTES=2048, sys/sys/param.h:497). There is no clamp. The over-long mbuf is passed to ieee80211_input (1132–1138), so up to 2047 bytes beyond the cluster are parsed as frame content and can be delivered to the stack/userland (monitor-mode capture, UDP payload) — a device-gated kernel heap info leak; malformed OOB header fields can equally panic the parsers.

Build / Run (hardware recipe)

Requires a Ralink RT2561/RT2661 NIC (guest has none — env.txt; if_ral.ko ships in /boot/kernel). See trigger.c steps: monitor mode + one crafted descriptor (flags[27:16] > 2048) + tcpdump capture.

Expected

Captured frames contain bytes from beyond the mbuf cluster (kernel heap), or a parser panic on garbage OOB bytes.

DF-3966 verdict — source-certain OOB read, hardware-gated

Reproduced?

No: the audit guest has no Ralink device (pciconf: no vendor 0x1814; env.txt). if_ral.ko is present in /boot/kernel (1.59 MB) and one kldload away on any host with the NIC.

Why the bug is real

• rt2661.c:1017-1021: desc = &sc->rxq.desc[sc->rxq.cur]; flags read from the DMA'd descriptor (device-written).
• rt2661.c:1101-1102: m->m_pkthdr.len = m->m_len = (le32toh(desc->flags) >> 16) & 0xfff — the ONLY bound is the 12-bit field mask (4095).
• rt2661.c:1055/706: the RX mbufs are m_getcl(...) clusters — MCLBYTES = 1<<11 = 2048 (sys/sys/param.h:494-497, x86_64).
• rt2661.c:1129-1138: mtod(m, ...) + ieee80211_input(ni, m, ...) / ieee80211_input_all — net80211 walks the frame using m_len: everything in (2048, 4095] is read past the cluster.
• No intermediate clamp exists anywhere on the path (checked: rt2661_rx_intr is the only consumer of the descriptor length).

Threat model / severity

Device-fed: requires malicious/compromised NIC firmware or a DMA platform attack (same class as DF-3748..3753 for the rt2860 sibling — those covered AID truncation, wcid UAF, TXWI pool, wcid byte, retrycnt, rate lookups; none of them is this rxeof length trust). A merely buggy NIC that sets the 12-bit length above 2048 also triggers it. Medium: kernel heap disclosure up to 2047 B/frame, repeatable per descriptor.

Fix

fix.diff clamps the finalized length to MCLBYTES before ieee80211_input.

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.