DF-0285 — PoC evidence pack

Finding: ieee80211_parse_meshid heap OOB write via unchecked MESHID IE length. File: sys/netproto/802_11/wlan/ieee80211_mesh.c:3456-3461 Class: CWE-787 heap overflow (802.11s mesh receive path). Severity: High (remote, wifi-adjacency; function-pointer-control surface).

TL;DR verdict

INCONCLUSIVE — real bug, code-level-confirmed; NOT runtime-triggerable on this guest (no wifi hardware). The vulnerable function is statically linked into the live kernel and IEEE80211_SUPPORT_MESH is enabled in the GENERIC config, but ifconfig -l shows only vtnet0 lo0 and there is no virtual/software frame-injection path into ieee80211_parse_beacon. See VERDICT.md for the full trace and the precise function-pointer correction.

What this pack proves

1. The overflow is real — memcpy(ni->ni_meshid, ie+2, ie[1]) at ieee80211_mesh.c:3460 with ie[1] attacker-controlled and unchecked, into a fixed 32-byte array. (Source trace in VERDICT.md.)
2. The overflow reaches the ni_mltimer.toc pointer (and a second one, ni_mlhtimer.toc) — proven by offsetof() arithmetic in layout_proof (numeric, ABI-checked, deterministic). ni_mltimer.toc is clobbered for any ie[1] >= 48; worst case ie[1]=255 gives a 223-byte OOB write.
3. The function-pointer claim is corrected: struct callout does not hold a function pointer directly; it holds toc, a pointer to a separately allocated struct _callout that holds the function pointers. So the primitive is a controlled-pointer-deref / type confusion (forge toc → forged _callout.qfunc), not a direct function-pointer field overwrite. Real RCE surface, but the finding's one-line wording is slightly imprecise.
4. The vulnerable code ships in the production kernel (nm on /boot/kernel/kernel shows ieee80211_parse_meshid live); it is merely unreachable without a wifi driver+radio.

Build

./build.sh

Builds two pure-userspace programs (layout_proof, frame_craft) with the guest's base cc. No kernel contact.

Run

./run.sh

Runs the three-part code-level proof: 1. layout_proof — overflow-reach table. 2. frame_craft — builds the attacker beacon pcap (df0285_beacon.pcap). 3. live-kernel symbol + config + ifconfig check.

Expected output

• layout_proof prints the ABI sanity checks (all OK), the field-offset table, and the reach matrix showing ni_mltimer.toc clobbered for ie[1]>=48 and both callout pointers for ie[1]>=80.
• frame_craft writes a 341-byte pcap whose MESHID IE is 72 ff 44 46 32 38 35 41 41 … (id=0x72, len=0xFF, "DF285", 'A'*250).
• the symbol check prints T ieee80211_parse_meshid, T ieee80211_mesh_init_neighbor, t mesh_peer_timeout_cb, and ifconfig -l ⇒ vtnet0 lo0.

Because there is no wifi HW, no kernel panic or memory corruption is observable at runtime on this guest. That is the expected, honest result for a wifi-receive-path bug; the source/layout proof is the deliverable.

To actually fire it (requires real wifi HW — NOT in this audit)

On a host with a monitor+inject-capable 802.11 radio (e.g. ath9k) and a DragonFly vap created in MBSS mesh mode:

# victim: create a mesh vap on a real radio
ifconfig wlan0 create wlandev ath0 wlanmode mesh
ifconfig wlan0 meshid mymesh up

# attacker: replay the crafted beacon at the victim
tcpreplay -i wlan0mon df0285_beacon.pcap    # Linux inject adapter
# or feed df0285_beacon.pcap to the injecting driver directly

On receipt, ieee80211_parse_beacon stores the IE (ieee80211_input.c:622), ieee80211_mesh_init_neighbor (ieee80211_mesh.c:3471) calls ieee80211_parse_meshid, and the 223-byte OOB write corrupts ni_mltimer.toc et al.

Files

DF-0285 — ieee80211_parse_meshid heap OOB write (802.11s MESHID IE)

Verdict

INCONCLUSIVE (real bug, code-level-confirmed; NOT runtime-triggerable on this audit guest).

The claimed heap overflow is real and exactly as described at the source level, but the audit guest is a KVM VM with no wifi hardware, so the receive path that feeds it (ieee80211_parse_beacon → ieee80211_mesh_init_neighbor → ieee80211_parse_meshid) cannot be driven at runtime here. This is the expected outcome for a wifi-receive-path bug; we provide a rigorous code-level proof instead, plus the exact attacker payload that would fire it on real radio HW.

The vulnerable code is statically linked into the live kernel (nm /boot/kernel/kernel shows T ieee80211_parse_meshid @ 0xffffffff8077aa50, mesh_peer_timeout_cb @ 0xffffffff80775560), and IEEE80211_SUPPORT_MESH is enabled in the audited X86_64_GENERIC config — so the bug ships in the production kernel image; it is merely unreachable without a wifi driver+radio.

The bug — trigger → primitive → effect (every hop cited)

Trigger. A mesh peer (or an attacker within wifi range of an MBSS vap) transmits a beacon/probe-response whose MESHID Information Element has a length byte ie[1] greater than IEEE80211_MESHID_LEN (32). The 802.11 IE parser ieee80211_input.c:620-623 stores the raw, unchecked IE pointer:

#ifdef IEEE80211_SUPPORT_MESH
case IEEE80211_ELEMID_MESHID:
    scan->meshid = frm;     /* frm[0]=id, frm[1]=len(!!), frm[2..]=data */
    break;

Contrast line 602 (case IEEE80211_ELEMID_ERP), which does validate if (frm[1] != 1) — proving the kernel's own pattern is to bounds-check IE lengths; the MESHID case simply omits it. The pointer then flows through ieee80211_mesh_init_neighbor (ieee80211_mesh.c:3467-3472) into the sink:

Sink. sys/netproto/802_11/wlan/ieee80211_mesh.c:3456-3461

void
ieee80211_parse_meshid(struct ieee80211_node *ni, const uint8_t *ie)
{
    ni->ni_meshidlen = ie[1];
    memcpy(ni->ni_meshid, ie + 2, ie[1]);   /* ie[1] UNCHECKED, up to 255 */
}

ni->ni_meshid is a fixed 32-byte array (ieee80211_node.h:200, uint8_t ni_meshid[IEEE80211_MESHID_LEN], IEEE80211_MESHID_LEN == 32 per ieee80211.h:200). ie[1] is an attacker-controlled uint8_t in [0..255]. For any ie[1] > 32, memcpy writes ie[1]-32 bytes past the end of the array — a classic heap OOB write of up to 223 bytes.

A second call site (ieee80211_node.c:843-844, ieee80211_parse_meshid(ni, ni->ni_ies.meshid_ie)) feeds the same sink from cached node IEs; the IE pointer there is likewise stored without clamping (ieee80211_node.c:1017, ies->meshid_ie = ie).

What gets overwritten (the layout proof — layout_proof.c)

struct ieee80211_node's "11s state" block (ieee80211_node.h:199-208) is laid out (offsets relative to ni_meshid[0], verified by offsetof() in layout_proof):

Reach table from layout_proof:

CONFIRM or REFUTE the "function-pointer overwrite" claim

PARTIALLY CONFIRMED — with a precise correction to the finding's wording.

The finding says ni_mltimer is "a callout containing a function pointer." That is imprecise. On DragonFly, struct callout (sys/sys/callout.h:77-82) does not itself contain a function pointer:

struct callout {
    struct _callout *toc;   /* opaque internal pointer   <-- FIRST FIELD */
    struct lock     *lk;
    uint32_t         flags;
    uint32_t         unused01;
};

The actual function pointers (rfunc/qfunc) live in struct _callout (callout.h:54-75), which is a separately allocated object that toc points at. Therefore the overflow does not directly overwrite a function pointer field; it overwrites the toc pointer inside ni_mltimer (and a second one inside ni_mlhtimer).

This is nonetheless a serious primitive — arguably more powerful than a direct function-pointer overwrite, because it is a controlled pointer dereference / type confusion:

• ni_mltimer is armed with a real callback: callout_reset(&ni->ni_mltimer, ni->ni_mltval, mesh_peer_timeout_cb, ni) (ieee80211_mesh.c:3055,3069), and drained on peer-down/cleanup (ieee80211_mesh.c:640,3449). When the callout subsystem fires, it dereferences cc->toc and invokes toc->qfunc(toc->qarg).
• If the attacker controls toc (which the overflow gives them, at ie[1]>=48), they can redirect it at a forged struct _callout placed in attacker-influenced kernel memory (e.g. via a separate heap spray, or at a chosen existing address). The forged _callout.qfunc then becomes an arbitrary kernel function call with a controlled argument → kernel PC control → RCE / local privilege escalation on a host that also has a wifi adapter in MBSS mode.

So: the function-pointer-control RCE severity is justified, but the mechanism is "corrupt the toc pointer → indirect call through a forged _callout", not "a function pointer field is directly overwritten". The finding's headline mechanism is right; its one-sentence structural description is slightly off.

Exploitability ceiling on this primitive (honest): full RCE/LPE requires the attacker to (a) reach the receive path (wifi adjacency to a mesh vap), (b) win any race between the overflow and the callout firing, and (c) place a forged _callout at a predictable/writable kernel address (defended by KASLR + heap randomization + SMAP/SMEP). We did not develop the chain to uid0 here because there is no runtime path on this guest to even trigger the overflow — that is explicitly out of scope for a wifi-receive-path bug on a headless KVM guest. The realistic impact is remote code execution against any DragonFly host operating a wifi interface in MBSS mesh mode, severity High (matches the finding). The content of the overflow is fully attacker-controlled (the IE body), and up to 223 bytes of it land in struct fields — a clean, deterministic heap write primitive, not a probabilistic one.

Reachability on THIS audit guest

PoC artifacts in this folder

• layout_proof.c / layout_proof — userspace offsetof() proof of the overflow reach; prints the field table + reach matrix above. This is the decisive numeric evidence.
• frame_craft.c / frame_craft — deterministic builder for the exact attacker payload: a valid 802.11 beacon (DLT_IEEE802_11 pcap) whose MESHID IE has id=0x72, len=0xFF and a 253-byte marker body. Writes df0285_beacon.pcap. On a host with a wifi radio in monitor+inject mode, tcpreplay-ing this pcap at a DragonFly MBSS vap fires the overflow. Not delivered on this guest (no radio).
• df0285_beacon.pcap — the generated payload (341 bytes).
• build.sh / run.sh — exact build/run (both pure-userspace, no kernel contact).
• build.log / run.log — full untrimmed outputs.
• env.txt — guest uname, cc, kldstat, live kernel symbols, ifconfig.
• fix.diff — standalone git apply-able clamp fix (validated: git apply --check ⇒ RC 0).

Recommended fix

Clamp ie[1] to IEEE80211_MESHID_LEN in ieee80211_parse_meshid before the memcpy, and store the clamped length. One-line logical change; full diff in fix.diff. No prior finding-proposal diff existed (this finding had no markdown writeup), so this is the authoritative fix.

Related secondary bug (not the primary claim, flagged for completeness)

ieee80211_scan_sta.c:312:

memcpy(ise->se_meshid, sp->meshid, 2+sp->meshid[1]);

where se_meshid is uint8_t[2+IEEE80211_MESHID_LEN] = 34 bytes (ieee80211_scan.h:282), but 2+sp->meshid[1] can be up to 257. Same beacon overflows the scan-cache entry too. Worth a separate finding / same-fix sweep.