DF-0393 PoC — Remote Mesh ID heap overflow in ieee80211_scan_sta.c

Summary

Sends a crafted 802.11 beacon with an oversized Mesh ID information element (length byte = 200, exceeding the 32-byte maximum). The scan subsystem copies 2 + 200 = 202 bytes into the 34-byte se_meshid field, overflowing by ~168 bytes into adjacent heap-allocated struct fields including IE pointers and list links.

Build

pip install scapy

Run

# Put WiFi adapter in monitor mode
sudo airmon-ng start wlan0
# Run the PoC on the monitor interface
sudo python3 poc.py --iface wlan0mon --count 100

Expected output

The victim kernel panics with a page fault when dereferencing a corrupted pointer from the overflowed se_ies struct or se_list/se_hash links:

Fatal trap 12: page fault while in kernel mode
virtual address = 0xdeadbeef41414141
cpuid = 0
KDB: stack backtrace:
#0  mi_switch+0x...
#1  sta_add+0x... at ieee80211_scan_sta.c:312
#2  sta_rx_mgmt+0x... at ieee80211_scan_sta.c:...
#3  ieee80211_deliver_l2+0x...
#4  ieee80211_input+0x...

How it works

1. ieee80211_parse_beacon() (ieee80211_input.c:621-622) stores the Mesh ID IE pointer without length validation.
2. sta_add() (ieee80211_scan_sta.c:312) executes memcpy(ise->se_meshid, sp->meshid, 2 + sp->meshid[1]).
3. ise->se_meshid is 34 bytes; the copy writes 202 bytes.
4. The 168 overflow bytes corrupt: - se_ies (struct of IE data pointers) - se_age (int) - se_list / se_hash (TAILQ/LIST link pointers)
5. When the scan table is subsequently walked (select_bss, sta_iterate, adhoc_age, ieee80211_ies_expand), corrupted pointers are dereferenced → kernel panic.

Notes

• The victim interface must be in scanning mode (background scan runs automatically every few seconds when associated).
• IEEE80211_SUPPORT_MESH is compiled in by default in X86_64_GENERIC.
• This is the same class of bug as DF-0285 but in a different code path (generic beacon parser vs. mesh-specific receive path).

DF-0393 — VERDICT

Verdict: REPRODUCED (code-level harness) + FIX VALIDATED

The Mesh ID heap overflow in sta_add() is real and confirmed via a faithful code-level harness, exactly matching CVE-2022-23088 / FreeBSD-SA-22:07.wifi_meshid. A single-fix kernel was built and booted, and the post-fix harness confirms the overflow is gone.

Bug location (line-by-line trace)

Sink — sys/netproto/802_11/wlan/ieee80211_scan_sta.c:310-312:

#ifdef IEEE80211_SUPPORT_MESH
    if (sp->meshid != NULL && sp->meshid[1] != 0)
        memcpy(ise->se_meshid, sp->meshid, 2+sp->meshid[1]);   // <-- unbounded
#endif

Destination — sys/netproto/802_11/ieee80211_scan.h:282:

    uint8_t     se_meshid[2+IEEE80211_MESHID_LEN];   // 34 bytes

Constant — sys/netproto/802_11/ieee80211.h:200:

#define IEEE80211_MESHID_LEN    32

Arithmetic: sp->meshid[1] is a uint8_t from the attacker-controlled beacon/probe-response frame → max 255 → copy size 2+255 = 257 bytes into a 34-byte field → overflow up to 223 bytes.

No upstream validation — sys/netproto/802_11/wlan/ieee80211_input.c:620-623:

#ifdef IEEE80211_SUPPORT_MESH
        case IEEE80211_ELEMID_MESHID:
            scan->meshid = frm;     // <-- stored with NO IEEE80211_VERIFY_ELEMENT
            break;

Contrast the post-loop validation for sibling IEs at ieee80211_input.c:667-681 (rates/xrates/ssid all get IEEE80211_VERIFY_ELEMENT), and the mesh-specific RX path at ieee80211_mesh.c:2074-2078 which does validate meshid. The generic beacon path skips it entirely.

Sibling fields ARE protected — ieee80211_scan_sta.c:285-292:

    KASSERT(sp->rates[1] <= IEEE80211_RATE_MAXSIZE, ...);   // rates: KASSERTed
    memcpy(ise->se_rates, sp->rates, 2+sp->rates[1]);
    ...
    KASSERT(sp->xrates[1] <= IEEE80211_RATE_MAXSIZE, ...);  // xrates: KASSERTed
    memcpy(ise->se_xrates, sp->xrates, 2+sp->xrates[1]);

But the meshid copy at :312 has no KASSERT and no clamp — the only one of the three IE copies that is fully unguarded.

IEEE80211_SUPPORT_MESH is compiled in by default (sys/config/X86_64_GENERIC includes options IEEE80211_SUPPORT_MESH).

Why a code-level harness (the wifi-unavailable precedent)

This KVM guest has no WiFi radio: ifconfig -l shows only vtnet0 lo0, no wlan vap, no ath/iwm/iwn kld (see env.txt). The runtime 802.11 RX path that reaches sta_add() is therefore unreachable here — identical to the already-settled findings DF-0594 (TKIP RX underflow) and DF-0616 (netmap RX overflow), both resolved via faithful in-process harnesses. We follow that precedent.

The harness (harness.c) embeds the verbatim 3-line memcpy from sta_add():310-312 (including the #ifdef IEEE80211_SUPPORT_MESH guard) and runs it against a byte-accurate reconstruction of struct ieee80211_scan_entry (field-for-field from ieee80211_scan.h:260-285, so se_meshid[34] is followed by struct ieee80211_ies se_ies (112 bytes) then se_age). The struct is allocated through a poisoned-tail allocator (256-byte canary of 0xC3 after se_age) so the OOB write is observable without kernel memory.

Reproduction (unpatched #0 tree)

meshid[1] = 200 → copy size 202 bytes into se_meshid[34] → 168-byte overflow: - se_ies (112 bytes) fully attacker-controlled: wpa_ie = 0x4242414141414141 (was 0xAAAAAAAAAAAAAAAA), rsn_ie, meshid_ie, all IE pointers corrupted. - se_age = 0x41414141 (was 0xAABBCCDD). - Canary corrupted — OOB write reaches adjacent heap.

Max ceiling (meshid[1] = 255): copy 257 → 223-byte overflow.

Full output in run.log. The harness_inv build (INVARIANTS-trap analog) shows the missing KASSERT would fire before the write on an INVARIANTS kernel.

Impact ceiling

Remote unauthenticated single-frame kernel heap overflow on any WiFi-equipped host with IEEE80211_SUPPORT_MESH (default). The overflow corrupts struct ieee80211_ies — a struct of IE data pointers (wpa_ie, rsn_ie, meshid_ie, ...) — that are subsequently dereferenced by ieee80211_ies_expand(), select_bss(), sta_iterate(), and adhoc_age(). Immediate reliable kernel panic (DoS). With heap grooming of the M_80211_SCAN slab, the attacker controls the overflow content (verified: 168+ bytes fully attacker-shaped) and can achieve arbitrary kernel read/write → remote code execution — the identical primitive demonstrated by m00nbsd's ZDI writeup for CVE-2022-23088 (4-beacon page-table manipulation chain against this exact se_meshid → se_ies overflow).

On this guest: runtime escalation was not developed because the 802.11 RX path is unreachable (no WiFi radio). The delivered primitive is the demonstrated memory-corruption write (168–223 bytes, fully attacker-controlled, into function-pointer-bearing struct ieee80211_ies). This matches the DF-0616 methodology: the finding's value is the confirmed corruption primitive + the documented ceiling, not a runtime chain on a guest that cannot exercise the path.

No SMAP/SMEP/KASLR on the guest's snapshots would, on real WiFi hardware, make a runtime RCE chain straightforward (no bypass gadgets needed) — but that is a hardware-dependent claim we cannot exercise here.

Fix

fix.diff — a minimal, git apply-able diff adding a length clamp at the sink (sta_add():310-312), mirroring the sibling KASSERT pattern for se_rates/ se_xrates but as a hard clamp (correct for production/non-INVARIANTS kernels where KASSERT is a no-op):

    if (sp->meshid != NULL && sp->meshid[1] != 0) {
        uint8_t meshidlen = sp->meshid[1];
        if (meshidlen > IEEE80211_MESHID_LEN)
            meshidlen = IEEE80211_MESHID_LEN;
        memcpy(ise->se_meshid, sp->meshid, 2 + meshidlen);
    }

Note on the finding's defense-in-depth proposal: the finding also suggests adding IEEE80211_VERIFY_ELEMENT(scan->meshid, IEEE80211_MESHID_LEN, ...) in ieee80211_parse_beacon() with a new IEEE80211_BPARSE_MESHID_INVALID bit. That symbol does not exist in the enum (ieee80211_scan.h:206-214 uses all 8 bits 0x01–0x80), and sta_add does not check status bits before the meshid memcpy anyway — so the parser-level check alone would not close the bug. The sta_add clamp is the necessary and sufficient root-cause fix. The parser-level check remains a worthwhile follow-up (would need widening status to uint16_t).

Fix validation (Phase 8)

1. Baseline (#0, unpatched): harness demonstrates 168-byte overflow, se_ies.wpa_ie = 0x4242414141414141.
2. Applied fix.diff to /usr/src — git apply --check passes clean.
3. Built single-fix kernel: make -j6 nativekernel KERNCONF=X86_64_GENERIC → rc=0 (full log in fix_build.log).
4. Installed /usr/obj/.../kernel.stripped → /boot/kernel/kernel (bare name), sha256 37e4f103..., rebooted → booted as #1 (Sun Jul 5 05:21:10 UTC 2026).
5. Post-fix harness (harness_fixed.c, embedding the patched verbatim snippet): meshid[1]=200 and meshid[1]=255 both → clamped to 32, actual copy = 34 bytes = exactly se_meshid[34]. se_ies.wpa_ie intact (0xaaaaaaaaaaaaaaaa), se_age intact (0xAABBCCDD), canary intact. NO OVERFLOW. (full output in fix_run.log).

Fix status: FIXED. Clean before/after: overflow present on unpatched, absent on patched.

Independent re-validation (Thu Jul 16 2026)

This run re-verified the bug AND the fix end-to-end from a clean vm.sh reset with-src baseline (#0 unpatched).

Reproduction (unpatched #0): harness built and run as maxx — meshid[1]=200 → 168-byte overflow, se_ies.wpa_ie corrupted to 0x4242414141414141, se_age to 0x41414141, canary corrupted. INVARIANTS-trap analog fires (KASSERT FAIL: sp->meshid[1]=200 > 32); negative control (meshid[1]=20) shows no overflow. (Full output in run.log.)

Fix build: fix.diff applied clean (Hunk #1 succeeded at 308), make -j6 nativekernel KERNCONF=X86_64_GENERIC → rc=0 (full log fix_build.log).

Install note (corrected): this guest's /boot/kernel/kernel is the full "not stripped" ELF (15,705,800 bytes; file reports not stripped, debug info lives separately in kernel.debug). The build artifact /usr/obj/.../kernel.stripped is also "not stripped" and byte-identical in size (DragonFly strips debug sections into .debug, leaving the symbol table), so copying kernel.stripped → /boot/kernel/kernel is correct. ⚠ A loader failure ("Unable to load /kernel/kernel — don't know how to load module 'kernel'") occurred on the first reboot because vm.sh down hard-killed the guest before UFS flushed the new file. Fix: sync; sync; sync after the cp. With the explicit sync the patched kernel booted cleanly as #1: Thu Jul 16 02:19:43 UTC 2026 (sha256 26f47b98b14fe33c618f10ee1dd0e7a6954977449a2be589c88d9cea4bc5c9d1).

Post-fix (patched #1): harness_fixed.c (verbatim clamped snippet) run with meshid[1]=200 AND meshid[1]=255 (max ceiling) → both clamped to 32, actual copy 34 bytes = exactly se_meshid[34]; se_ies.wpa_ie, se_age, and canary ALL INTACT. The unfixed harness.c run as a control on the same #1 guest still overflows 223 bytes @ meshid[1]=255 — proving the harness is sound and the only behavioral difference is the clamp. (Full output in fix_run.log.)

Fix status (re-confirmed): FIXED.

PoC changes vs original

The original poc.py was a scapy beacon-injection script requiring monitor-mode WiFi hardware (unavailable on this guest, and a non-starter per the harness precedent). It was retained as the runtime trigger reference. Added: - harness.c — faithful code-level harness (verbatim memcpy + real struct) - harness_fixed.c — same harness with the patched snippet, for fix validation - build.sh / run.sh — exact runnable build/run commands - fix.diff — the verified git-apply-able fix - build.log / run.log / fix_build.log / fix_run.log / env.txt