DF-0981 — PoC evidence pack

Finding: Heap buffer overflow in run_bulk_rx_callback() aggregated-frame path — m_getcl cluster (MCLBYTES == 2048) too small for the device-controlled per-frame dmalen (can reach ~4079 bytes when the bulk RX URB is RUN_MAX_RXSZ == 4096).

File: sys/bus/u4b/wlan/if_run.c (the finding's "File" field is correct; the task prompt's sys/dev/netif/run/ is a stale path — those are empty subdirectories).

Reachability on this guest

This is a USB WiFi driver bug in run(4) (Ralink RT2770/RT2870/RT3070/ RT3370/...). The vulnerable callback run_bulk_rx_callback() is only entered when:

1. A run(4) USB adapter is present and attached, AND
2. A bulk RX USB transfer (URB) completes with a frame.

The audit guest — DragonFly 6.5-DEVELOPMENT #0 in KVM — has no USB controller exposed to the guest and no run(4) device:

• usbconfig list ⇒ No device match or lack of permissions.
• kldstat | grep run ⇒ empty (module is not loaded; nothing to bind)
• ifconfig -a ⇒ only vtnet0 (virtio) and lo0

Therefore the live trigger is unreachable on this guest — this is a valid hard blocker for a live kernel exploit. No uid=0 chain can be developed here because the corrupting write never executes without the hardware.

Per the run instructions, a deterministic code-level harness that replicates the exact run_bulk_rx_callback aggregation / m_copydata / dmalen logic is the acceptable proof. run_aggr_oob.c is that harness.

How to reproduce

./build.sh      # cc -O2 -Wall -o run_aggr_oob run_aggr_oob.c
./run.sh        # prints BEFORE (OOB confirmed) and AFTER (fixed, no OOB)

What the harness does

It re-implements, verbatim from the kernel:

• the per-frame DMA-length extraction dmalen = le32toh(*mtod(m,uint32_t*)) & 0xffff (if_run.c:2989),
• the dmalen & 3 / (dmalen+8) > xferlen checks (if_run.c:2991-3001),
• the aggregated-frame branch decision (xferlen -= dmalen+8) <= 8 (if_run.c:3003),
• the vulnerable allocation m0 = m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR) whose cluster is MCLBYTES == 2048 (if_run.c:3013),
• the blind m_copydata(m, 4, dmalen + sizeof(struct rt2870_rxd), mtod(m0,*)) with NO destination-bound check (if_run.c:3023-3024 + uipc_mbuf.c:1671-1696).

For a crafted URB of RUN_MAX_RXSZ (4096) bytes with dmalen = 3000 (a legal multiple of 4, satisfying (dmalen+8) <= xferlen, and leaving xferlen - (dmalen+8) = 1088 > 8 to force the aggregated branch), the BEFORE path writes 3004 bytes into a 2048-byte cluster ⇒ 956-byte heap OOB write.

The harness then runs the SAME input through the FIXED logic (m_getjcl(MJUMPAGESIZE) + a dmalen + sizeof(rt2870_rxd) > MCLBYTES reject) and shows neither overflows nor even reaches the copy.

Fix

fix.diff (git-apply-able) makes two changes to sys/bus/u4b/wlan/if_run.c:

1. Allocation fix (root cause): change m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR) → m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUMPAGESIZE) at the aggregated branch, so the destination cluster is at least as large as the source URB (MJUMPAGESIZE == 4096 == RUN_MAX_RXSZ), matching how sc->rx_m is already allocated at if_run.c:2933.
2. Defense-in-depth bound: reject any frame whose dmalen + sizeof(struct rt2870_rxd) > MCLBYTES before the copy, so even a future change to RUN_MAX_RXSZ / cluster sizing cannot re-introduce the mismatch. This is the belt; #1 is the suspenders.

Validation on this guest

Because run is a loadable module (not compiled into X86_64_GENERIC) and there is no hardware to load it, the fix is validated by:

1. Module compiles cleanly with -Werror: both baseline (vulnerable) and patched if_run.ko build with cc ... -Werror and rc=0. See build.log (baseline) and fix_build.log (patched).
2. Harness before/after: the vulnerable code path overflows (956 B); the patched logic does not. See run.log and fix_run.log.

A full nativekernel rebuild would NOT recompile if_run.c (it is a module, not in GENERIC), so it adds no signal beyond the module build.

Files

• run_aggr_oob.c — the harness (faithful reimplementation).
• build.sh / run.sh — exact repro commands.
• build.log — baseline (unpatched) if_run.ko module build.
• run.log — harness run (BEFORE OOB / AFTER OK).
• fix_build.log — patched if_run.ko module build (-Werror, rc=0).
• fix_run.log — harness AFTER-section (fixed, no overflow).
• fix.diff — git-apply-able fix (2 hunks).
• env.txt — guest environment (uname, cc, kldstat, usbconfig).
• VERDICT.md — full narrative + line-by-line trace.
• manifest.json — artifact catalog.

DF-0981 — VERDICT

Verdict

REPRODUCED (code-level harness) — heap OOB write confirmed; live trigger UNREACHABLE on this guest (no run(4) USB hardware). Bug is REAL and the fix is VALIDATED (module compiles under -Werror; harness before/after shows the overflow is eliminated).

The bug (line-by-line trace)

In sys/bus/u4b/wlan/if_run.c, run_bulk_rx_callback() reassembles device-aggregated 802.11 frames out of a bulk RX URB. The per-frame DMA length dmalen is device-controlled:

/* if_run.c:2989 */
dmalen = le32toh(*mtod(m, uint32_t *)) & 0xffff;

The only bounds placed on dmalen are (if_run.c:2991-3001):

if ((dmalen >= (uint32_t)-8) || (dmalen == 0) || ((dmalen & 3) != 0)) { break; }
if ((dmalen + 8) > (uint32_t)xferlen) { break; }

i.e. dmalen may be as large as xferlen - 8, and xferlen itself may be up to RUN_MAX_RXSZ:

/* if_runvar.h:26-27 */
#define RUN_MAX_RXSZ  MIN(4096, MJUMPAGESIZE)   /* == 4096 */

The URB buffer (sc->rx_m) is correctly allocated as a 4096-byte jumbo cluster (if_run.c:2933, m_getjcl(..., MJUMPAGESIZE)), so the SOURCE side is fine. But when the callback detects aggregation ((xferlen -= dmalen + 8) > 8, if_run.c:3003), it copies each per-frame slice into a newly allocated 2048-byte cluster:

/* if_run.c:3013 (VULNERABLE) */
m0 = m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR);          /* MCLBYTES == 2048 */
...
/* if_run.c:3023-3024 (THE OOB WRITE) */
m_copydata(m, 4 /* skip 32-bit DMA-len header */,
    dmalen + sizeof(struct rt2870_rxd), mtod(m0, void *));

m_copydata() (sys/kern/uipc_mbuf.c:1671-1696) is a blind bcopy() of len bytes into the supplied destination with no destination-bound check — it trusts the caller to size the buffer. With dmalen up to ~4079 and sizeof(struct rt2870_rxd) == 4 (if_runreg.h:834, a single uint32_t __packed), the copy writes up to ~4083 bytes into a 2048-byte cluster, overflowing the kernel heap by up to ~2035 bytes. The overflow content is fully attacker-controlled (it is the USB URB payload).

run_rx_frame() then sets m->m_pkthdr.len = m->m_len = len from the device rxwi->len (if_run.c:2845), and net80211 reads attacker-controlled bytes from beyond the 2048-byte cluster into upper-layer protocol parsing.

Why it's a heap overflow

• Destination: m_getcl() ⇒ MCLBYTES == 2048 (sys/sys/param.h:497).
• Copy length: dmalen + 4, bounded only by xferlen - 8 + 4 ≤ 4092.
• Overflow: min(4092, dmalen+4) - 2048 ≥ 0 for any dmalen ≥ 2044 that is a multiple of 4 and leaves xferlen - dmalen - 8 > 8 (i.e. dmalen ≤ 4079).

So for every dmalen ∈ {2044, 2048, …, 4076} (multiples of 4), the copy overflows. The finding's dmalen = 3000 example overflows by 956 bytes (3004 − 2048), exactly reproduced by the harness.

Reachability / threat model

• Primary (the realistic one): a malicious USB peripheral enumerating as a run_devs[] VID/PID (e.g. USB_VP(0x148f, 0x2770)). DragonFlyBSD plug-and-plays run(4) with no user interaction and no privilege, so hot-plugging the crafted device triggers this on any USB-capable host.
• Secondary (wireless): a hostile AP / RF injector delivering a large HT A-MSDU whose per-frame DMA length exceeds ~2044 bytes; the RT2860/RT2870 MAC accepts MPDUs up to MAX_LEN_CFG = 0x2fff = 12287 (if_run.c:6027) and the firmware faithfully passes a large dmalen to the host.

Reproduction on this guest

The live path is NOT reachable on this guest — there is no USB controller exposed to the KVM guest and no run(4) device:

$ usbconfig list
No device match or lack of permissions.
$ kldstat | grep run
(empty — module not loaded)
$ ifconfig -a
vtnet0: ... (virtio)
lo0: ...

This is a valid hard blocker for a live uid=0 chain: the corrupting m_copydata write never executes without the hardware, so no escalation is possible to demonstrate on this guest. The realistic escalation surface is a USB-equipped DragonFlyBSD host with a run(4) adapter present (default config on such hardware). On that host, with no SMAP/SMEP/KASLR, a 2 KB attacker-controlled heap overflow from an unprivileged physical-access vector ("plug in a USB stick") is a credible LPE.

Per the run instructions, the proof is a deterministic code-level harness replicating the exact logic. run_aggr_oob.c does this; it shows:

[BEFORE] m_getcl() (cluster=2048), no extra bound:
  *** HEAP OOB WRITE CONFIRMED: 956 bytes past the 2048-byte cluster ***
  -> matches if_run.c:3023-3024 m_copydata() overflow

Exploit chain

Not pursuable on this guest: valid hard blocker — no run(4) device, so the write primitive never fires in-kernel here. Characterized at the code level:

• Class: kernel heap buffer overflow (CWE-122).
• Write size: up to ~2035 bytes, fully attacker-content-controlled (USB URB payload).
• Destination slab: an mbuf cluster from m_getcl() — the mbufcluster objcache; the overflow lands on whatever allocator-adjacent kernel object follows the cluster (other mbufs/clusters, malloc'd objects).
• Conversion on a USB-equipped host (NOT demonstrable here): classic heap-grooming — fill the mbuf-cluster slab, punch a hole, trigger the overflow to corrupt an adjacent victim object (e.g. another struct mbuf's m_next/m_data, or a neighboring kmalloc object holding a function pointer / ucred *), then drive the victim through normal network/proc syscalls. No SMAP/SMEP/KASLR on this guest family means a hijacked kernel function pointer can jump straight to userspace shellcode that calls commit_creds(prepare_kernel_cred(NULL)). The blocker is purely that the trigger hardware is absent, not that the primitive is benign.

PoC changes

The PoC directory was empty on arrival (no README, no source, no fix.diff). I authored the full evidence pack from scratch:

• run_aggr_oob.c — the harness (faithful reimplementation of the run_bulk_rx_callback aggregation loop + m_copydata blind-copy semantics, with guard-padded destination buffers so the OOB is directly observable).
• build.sh, run.sh — exact repro commands.
• fix.diff — the verified fix (2 hunks).
• VERDICT.md, README.md, manifest.json, full logs.

The fix

fix.diff (git-apply-able, applies cleanly with git apply -p1 and patch -p1) makes two changes to sys/bus/u4b/wlan/if_run.c:

1. Allocation fix (root cause): m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR) → m_getjcl(M_NOWAIT, MT_DATA, M_PKTHDR, MJUMPAGESIZE) at the aggregated branch, so the destination cluster is at least RUN_MAX_RXSZ (4096) bytes — matching how sc->rx_m is already allocated at if_run.c:2933.
2. Defense-in-depth bound: reject dmalen + sizeof(struct rt2870_rxd) > MCLBYTES before the copy, so even a future change to RUN_MAX_RXSZ cannot re-introduce the mismatch.

This supersedes the finding markdown's proposal: the markdown proposed only change #1 (m_getjcl(MJUMPAGESIZE)). I add #2 (explicit bound) as defense-in-depth and also note the markdown's optional secondary hardening (tighten the len > dmalen check in run_rx_frame) is left for separate treatment.

Fix validation

Because run is a loadable module (not in X86_64_GENERIC) and the guest has no hardware, validation is module compile + harness before/after (per the run instructions):

• Baseline (unpatched) module builds: if_run.ko compiles with cc ... -Werror and rc=0. (build.log)
• Patched module builds: if_run.ko compiles identically with -Werror and rc=0 (76392 bytes). (fix_build.log)
• Harness before/after: the vulnerable path overflows by 956 bytes; the patched logic (both the m_getjcl reallocation AND the explicit bound) eliminates the overflow. (run.log, fix_run.log)

A full nativekernel rebuild would NOT recompile if_run.c (module-only), so it adds no signal beyond the module build and was not performed.

Impact

• On a USB-equipped DragonFlyBSD host with run(4): kernel heap OOB write of up to ~2035 attacker-controlled bytes from an unprivileged physical-access vector (malicious USB peripheral) or a hostile wireless peer. Credible LPE / kernel RCE; reliable kernel panic (DoS) at minimum. Severity High is correct (CVSS AV:A/physical-proximity or AV:P/USB, but the finding's AV:A/AC:L wireless framing is also valid).
• On this audit guest: unreachable (no hardware) — DoS/corruption impact cannot be triggered; documented as a real-but-hardware-gated bug.