DF-3327 — Remote kernel panic in hwmp_send_action: PREP sent along a never-validated (zero) nexthop

File: sys/netproto/802_11/wlan/ieee80211_hwmp.c Severity: High (unauthenticated adjacent-network DoS, default-config mesh vap) Verdict: REPRODUCED — panic: null node on the stock INVARIANTS kernel; fix validated.

What

A single broadcast-target HWMP PREQ action frame makes hwmp_recv_preq() emit a proactive PREP addressed to the nexthop of an originator route that exists but was never marked VALID. Such a route is M_ZERO-allocated (ieee80211_mesh.c:203-215), so its nexthop is 00:00:00:00:00:00. hwmp_send_action() resolves that address with ieee80211_mesh_find_txnode(), which returns NULL for an unrouted address (ieee80211_mesh.c:1028-1037), then hits KASSERT(ni != NULL, ("null node")) (ieee80211_hwmp.c:636) — panic on INVARIANTS kernels; on production kernels the next line (ic = ni->ni_ic, ieee80211_hwmp.c:637) is a NULL deref → fatal page fault. Same sink is reachable from PREP propagation (ieee80211_hwmp.c:1558) and the intermediate PREP reply (ieee80211_hwmp.c:1303).

Why the route stays INVALID: for a fresh originator route hr_seq == 0; a PREQ with origseq == 0 and metric not better than 0 satisfies neither update branch (ieee80211_hwmp.c:1090-1102) nor the discard branch (:1103-1106), so processing falls through with the route INVALID, yet the proactive branch (:1216-1255) still sends a PREP to rtorig->rt_nexthop == 00:00:00:00:00:00.

Reproduce

Requires the repo-root working dir and the QEMU guest (see dfbsd-qemu/).

sh findings/poc/DF-3327/build.sh     # compile extended fwm.ko in guest
sh findings/poc/DF-3327/run.sh       # boot mesh vap, peer, fire step 30

Expected (stock kernel): serial console shows

fwm: inject HWMP PREQ origseq=0 targ=bc TO (proactive PREP to zero nexthop)
panic: null node
hwmp_send_action() at hwmp_send_action+0x4ee
hwmp_recv_action_meshpath() at ...
Debugger("panic")

and the guest wedges in ddb (reset afterwards: dfbsd-qemu/vm.sh reset with-src).

Fix validation

fix.diff adds a NULL check in hwmp_send_action() (drop + ENOENT). Applied in-guest, make -j6 nativekernel KERNCONF=X86_64_GENERIC + make installkernel, reboot into kernel #1, same PoC (twice): no panic, guest stays up, PREQ still fully processed (forwarded broadcast PREQ visible in kern.fwm_txlog). See fix_run.log, fix_build.log.

Harness

fwm.c extends the DF-3286/3287 shared software-radio KLD. New step 30 builds the 65-byte action frame:

802.11 hdr | cat=13 (MESH) code=1 (HWMP) | PREQ IE (130) len=37:
flags=0 hop=0 ttl=32 id=0x41414141 orig=02:00:00:00:e0:01 (fresh)
origseq=0 lifetime=5000 metric=0 tcount=1
target: flags=0x01 (TO) addr=ff:ff:ff:ff:ff:ff seq=0

Peer establishment (step 4: beacon + OPEN + CONFIRM) is required because ieee80211_recv_action() gates CAT_MESH frames on an ESTABLISHED link (ieee80211_action.c:243-256); peering is auto-granted on default-config mesh vaps (ieee80211_mesh.c:683 — MESHFLAGS_AP|MESHFLAGS_FWD).

DF-3327 VERDICT — REPRODUCED (remote kernel panic, single HWMP PREQ action frame)

Runs

Why it reproduces (path:line)

1. ieee80211_action.c:243-256 — CAT_MESH action frames dispatch once the attacker link is ESTABLISHED (auto-peered via the fwm dance; no user auth on default open mesh).
2. ieee80211_hwmp.c:417-474 — the PREQ IE (len=37, tcount=1) parses cleanly; verify_mesh_preq_len passes (:328).
3. ieee80211_hwmp.c:1055-1079 — rt_add(orig 02:00:00:00:e0:01) → M_ZERO route (ieee80211_mesh.c:203-215): INVALID, nexthop 0, metric 0, hr_seq 0.
4. ieee80211_hwmp.c:1089-1102 — origseq=0 is neither GT the stored 0 nor (equal-seq ∧) better-metric ⇒ no update, route stays INVALID. :1103-1106 — neither discard clause fires (no target route, originator route not VALID) ⇒ processing continues.
5. :1216-1242 — target is broadcast + TO bit ⇒ proactive branch; (rt_flags & VALID) == 0 ⇒ "reply with PREP" ⇒ :1254 hwmp_send_prep(vap, rtorig->rt_nexthop /* 00:00:00:00:00:00 */, &prep).
6. ieee80211_hwmp.c:627 — ieee80211_mesh_find_txnode(vap, 00:…:00) → no route for the zero MAC ⇒ NULL (ieee80211_mesh.c:1030-1033).
7. ieee80211_hwmp.c:636 — KASSERT(ni != NULL, ("null node")) ⇒ panic (stock INVARIANTS kernel). On production kernels :637 ic = ni->ni_ic is a NULL-page deref ⇒ fatal fault either way.

Same sink, two more remote routes: PREP propagation (ieee80211_hwmp.c:1521-1558, rtorig exists-but-invalid) and the intermediate PREP reply (:1271-1303).

Impact

Remote (adjacent, unauthenticated after auto-peering) kernel panic of any default-config mesh node, one frame per panic, repeatable at will. Not a memory-corruption primitive (NULL deref), so DoS is the ceiling.

Fix validation

fix.diff (NULL check + drop + ENOENT in hwmp_send_action) — applied in guest /usr/src, make -j6 nativekernel KERNCONF=X86_64_GENERIC (0 errors), make installkernel, reboot, same PoC twice: panic gone, guest healthy, PREQ still forwarded (behavior preserved). Baseline vs patched transcript in run.log / fix_run.log.

Notes

• The panic occurred inside the sysctl kern.fwm_step=30 write (synchronous RX injection), matching the ieee80211_input_mimo frames in the backtrace.
• Guest reset to clean with-src snapshot after both runs.

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.