DF-2358 — Heap buffer overflow in USB RX frame aggregation (sys/bus/u4b/wlan/if_run.c)

Verdict: NOT REPRODUCED (HW-gated); REAL BUG IN SOURCE (defense-in-depth fix warranted)

Hardware gate (why the PoC cannot run on this guest)

run is the Ralink RT2700U/RT2800U/RT3000U/RT3900E 802.11abgn USB wifi driver. It attaches only when a matching Ralink USB wifi dongle is plugged in. The audit QEMU/KVM guest has no USB device and no wifi interface:

$ usbconfig list               # No device match or lack of permissions.
$ ifconfig -l                  # vtnet0 lo0   (no wlan/run)
$ pciconf -l | grep -iE "ralink|148f|1435|0789"   # (no Ralink USB wifi chip)
$ kldstat                      # kernel + ehci.ko + xhci.ko only

The RX aggregation path run_bulk_rx_callback runs only when the run driver has attached to a Ralink USB wifi device and is receiving batched frames. With no such device the path never executes; the unprivileged maxx user cannot plug a USB dongle into the QEMU guest, and there is no adjacent rogue-AP threat (no radio).

Source trace — the bug is REAL (sys/bus/u4b/wlan/if_run.c)

run_bulk_rx_callback (if_run.c:2897-...) splits an aggregated USB bulk transfer into individual 802.11 frames. Bounds (if_runvar.h:26-27):

#define RUN_MAX_RXSZ  MIN(4096, MJUMPAGESIZE)   /* 4096 */

The source buffer sc->rx_m is correctly allocated with m_getcl/m_getjcl (MJUMPAGESIZE = 4096), so the source of the copy is in bounds. The problem is the destination:

m->m_pkthdr.len = m->m_len = xferlen;                       /* if_run.c:2985 */
for(;;) {
    dmalen = le32toh(*mtod(m, uint32_t *)) & 0xffff;        /* device-controlled 16-bit */
    if ((dmalen >= (uint32_t)-8) || (dmalen == 0) || ((dmalen & 3) != 0)) break;
    if ((dmalen + 8) > (uint32_t)xferlen) break;            /* if_run.c:2996: bound by xferlen, not dest */
    if ((xferlen -= dmalen + 8) <= 8) { ... run_rx_frame(sc, m, dmalen); break; }  /* final frame uses 4096-byte src buf */
    /* aggregated (non-final) frames: copy into a NEW m_getcl cluster */
    m0 = m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR);              /* if_run.c:3013: cluster = MCLBYTES = 2048 */
    ...
    m_copydata(m, 4, dmalen + sizeof(struct rt2870_rxd),    /* if_run.c:3023 */
               mtod(m0, void *));                           /* writes dmalen+rxd_size into 2048-byte cluster */

dmalen is bounded only by xferlen (≤ RUN_MAX_RXSZ = 4096), so for a non-final aggregated frame dmalen + sizeof(struct rt2870_rxd) can reach ~4080 bytes — but m0 is a m_getcl cluster of only MCLBYTES = 2048 bytes. m_copydata does not bounds-check the destination (the KASSERT at kern/uipc_mbuf.c:1671 validates only the source), so the copy overflows the 2048-byte cluster by up to ~2032 bytes into adjacent slab memory.

Two attack vectors: (1) wireless adjacent-network rogue AP bursts large data frames the firmware aggregates; (2) a malicious USB device impersonating Ralink sends a crafted bulk IN. Impact: kernel heap corruption → arbitrary kernel code execution or panic.

Exploit chain status

Not pursuable — primitive (heap overflow of destination cluster) requires a Ralink USB wifi dongle or adjacent radio (absent) — valid Phase-6 hard blocker: dead path at runtime on this guest. On hardware this is a write-capable heap overflow.

PoC changes

None. No Ralink USB wifi dongle on guest; verified by source trace only.

Recommended fix

Use a destination mbuf large enough for dmalen + sizeof(rt2870_rxd) (e.g. m_getjcl(MJUMPAGESIZE)) or bound dmalen against MCLBYTES - sizeof(rt2870_rxd). See fix.diff (matches finding proposal: allocate the destination with a cluster that can hold the maximum possible copy).