DF-0351 — HWMP uint32 metric-accumulation overflow (route poisoning)

Severity: High · Class: integer-overflow → protocol/logic (route poisoning / hijacking) File: sys/netproto/802_11/wlan/ieee80211_hwmp.c Sites: :1089 (PREQ recv), :1325 (PREQ fwd), :1453 (PREP recv), :1557 (PREP fwd), :1972 (RANN recv) — all plain uint32_t add, no saturation.

Bug

HWMP (IEEE 802.11s Hybrid Wireless Mesh Protocol) accumulates the airtime path metric by adding each hop's link metric onto the value carried in the frame:

/* ieee80211_hwmp.c:1089 */
metric = preq->preq_metric + ms->ms_pmetric->mpm_metric(ni);

preq->preq_metric is a uint32_t populated verbatim from the on-air frame at ieee80211_hwmp.c:458:

preq->preq_metric = le32dec(iefrm_t); iefrm_t += 4;   /* no range check */

The addition is plain uint32_t with no saturation, so an attacker transmitting a crafted PREQ with preq_metric near UINT32_MAX makes the sum wrap modulo 2³² to a small value. That wrapped tiny metric then beats every honest path metric in the route-accept comparison (:1090-1102) and is stored into the route table (:1095), installing the attacker as the nexthop for the originator → route poisoning / hijacking / MITM / blackhole / partition.

The same unsaturated add is used in five places (PREQ/PREP/RANN receive and PREQ/PREP forward), so the wrap is reachable on every HWMP message type and also propagates: a forwarder does ppreq.preq_metric += link (:1325) and re-broadcasts the wrapped value, poisoning every downstream mesh node.

The 802.11s spec mandates a monotonically-increasing, non-wrapping metric accumulation; the code has no saturation.

Why this is not a memory-corruption primitive

The overflow stores a valid uint32_t into a uint32_t field (rt_metric). There is no heap/stack write of attacker bytes, no UAF, no type confusion. The damage is routing state: the mesh node routes traffic for the spoofed originator through the attacker. Impact ceiling = route poisoning / hijacking in an 802.11s mesh (requires WiFi HW + mesh-mode VAP). No uid=0 chain applies; the exploit chain field is none.

Reproduction on this guest

The audit guest has no WiFi hardware and no mesh-mode VAP, so the live in-kernel HWMP receive path cannot be driven end-to-end here (the action-frame handler hwmp_recv_action_meshpath is only invoked from the net80211 RX path for an association in IEEE80211_M_MBSS). Per the finding's own note ("No WiFi HW → harness"), this pack ships a userspace harness that replicates the exact arithmetic and route-accept logic of the cited lines, proving the overflow is real and attacker-controlled, and proving the saturating-add fix closes it. This is the same harness-validated pattern used for HW/remote-only findings across the audit.

Build & run (on the guest, as maxx)

./build.sh   # cc -O2 -Wall -o hwmp_metric_overflow hwmp_metric_overflow.c
./run.sh     # ./hwmp_metric_overflow

Expected output (decisive lines)

[fresh-seq  ] preq_metric=0xffffffff link=50000  => accumulated=49999       (0x0000c34f)  *** ROUTE POISONED ***
[equal-seq  ] preq_metric=0xffffffff link=50000  => accumulated=49999       (0x0000c34f)  *** ROUTE POISONED ***
hop1: 0xFFFFFFFE + 50000 = 49998 (0x0000c34e)  <-- WRAPS    (PREQ forward accumulation)
-- FIXED kernel --
[equal-seq  ] preq_metric=0xffffffff link=50000  => accumulated=4294967295  (0xffffffff)  rejected (legit route preserved)

Fix

fix.diff introduces a static __inline saturating-add helper (hwmp_metric_add) right after the HWMP_SEQ_* macros and replaces all five plain-add sites with calls to it. The sum clamps at UINT32_MAX, so the wrapped tiny value never appears and the legitimate route is always preserved.

Fix validation (Phase 8): the harness's "FIXED" path mirrors the helper byte-for-byte; additionally, fix.diff is applied to the in-guest source, a single-fix X86_64_GENERIC kernel is built and booted, and the harness is re-run to confirm the kernel compiles/links/runs with the fix in place. See VERDICT.md and fix_build.log / fix_run.log.

DF-0351 — Verdict

REPRODUCED (source-confirmed + harness-demonstrated; live in-kernel path needs WiFi HW, which the audit guest lacks — validated via the harness-arith equivalence pattern, per the finding's own "No WiFi HW → harness" directive).

Mechanism (every hop cited path:line)

1. Attacker-controlled input. hwmp_recv_action_meshpath() parses each HWMP PREQ IE from the on-air frame and reads the metric field verbatim with no range/sanity check: - sys/netproto/802_11/wlan/ieee80211_hwmp.c:458 → preq->preq_metric = le32dec(iefrm_t); - PREP and RANN metrics are parsed analogously (same le32dec pattern). An attacker transmitting a crafted PREQ sets preq_metric to any uint32_t, including values near UINT32_MAX.

2. Unsaturated accumulation. The receive path adds the per-hop link metric onto the frame value in plain uint32_t (wraps modulo 2³²): - :1089 (PREQ recv) metric = preq->preq_metric + ms->ms_pmetric->mpm_metric(ni); - :1325 (PREQ fwd) ppreq.preq_metric += ms->ms_pmetric->mpm_metric(ni); - :1453 (PREP recv) metric = prep->prep_metric + ms->ms_pmetric->mpm_metric(ni); - :1557 (PREP fwd) pprep.prep_metric += ms->ms_pmetric->mpm_metric(ni); - :1972 (RANN recv) metric = rann->rann_metric + ms->ms_pmetric->mpm_metric(ni); All operands and the LHS are uint32_t (ieee80211_mesh.h:225 rann_metric, :250 preq_metric, :276 prep_metric, :429 rt_metric, :487 mpm_metric return type).

3. Fresh-seq bypass + poisoned store. With a fresh originator sequence number the first clause of :1090-1092 is true and the route is updated unconditionally; even on the equal-seq path the wrapped (tiny) metric beats the stored honest metric (metric < rtorig->rt_metric). The wrapped value is stored and the attacker becomes the nexthop: - :1093 hrorig->hr_seq = preq->preq_origseq; - :1094 IEEE80211_ADDR_COPY(rtorig->rt_nexthop, wh->i_addr2); ← attacker - :1095 rtorig->rt_metric = metric; ← poisoned wrapped value - :1102 rtorig->rt_flags = IEEE80211_MESHRT_FLAGS_VALID;

4. Propagation. The forward paths (:1325, :1557) re-broadcast the wrapped metric, so every downstream mesh node that forwards or receives the frame is also poisoned — a mesh-wide hijack primitive.

The 802.11s HWMP spec mandates a monotonically-increasing, non-wrapping metric accumulation; the code has no saturation, so the wrap is real.

Harness proof (hwmp_metric_overflow.c)

The harness replicates the exact arithmetic + route-accept logic of :1089-1102 and the forward accumulation of :1325. Decisive output (guest maxx, gcc 8.3):

[fresh-seq] preq_metric=0xffffffff link=50000 => accumulated=49999 (0x0000c34f) *** ROUTE POISONED ***
[equal-seq] preq_metric=0xffffffff link=50000 => accumulated=49999 (0x0000c34f) *** ROUTE POISONED ***
hop1: 0xFFFFFFFE + 50000 = 49998 (0x0000c34e)  <-- WRAPS  (PREQ forward accumulation, :1325)
-- FIXED kernel (saturating add) --
[equal-seq] preq_metric=0xffffffff link=50000 => accumulated=4294967295 (0xffffffff) rejected (legit route preserved)

0xFFFFFFFF + 50000 wraps to 49999; the route is poisoned and the attacker's nexthop installed. Under the saturating-add fix the sum clamps to UINT32_MAX, the comparison UINT32_MAX < 5000000 is false, and the legitimate route is preserved. RUN_EXIT=0, deterministic across runs.

Why no escalation chain

The primitive is not memory corruption: a valid uint32_t is written to a uint32_t routing field. There is no heap/stack write, UAF, double-free, or type confusion — no uid=0 chain exists. The impact ceiling is mesh routing integrity/availability (route poisoning / hijacking). exploit_chain = none.

PoC changes vs. seeded scaffolding

The seeded findings/poc/DF-0351/ folder was empty; this run authored the full evidence pack: hwmp_metric_overflow.c (harness), build.sh, run.sh, README.md, VERDICT.md, manifest.json, fix.diff, and all logs.

Fix (fix.diff)

Adds a static __inline saturating-add helper hwmp_metric_add() (clamp at UINT32_MAX, uint64_t intermediate) right after the HWMP_SEQ_* macros (:134) and replaces all five plain-add sites (:1089, :1325, :1453, :1557, :1972) with calls to it. The fix is broader than the finding's three cited lines — the finding missed the two forward-accumulation sites (:1325, :1557), which are equally reachable and equally critical (they propagate the wrap mesh-wide). One logical change, minimal, HWMP-spec-aligned.

git apply --check -p1 fix.diff ⇒ APPLIES_CLEAN.

Fix validation (Phase 8)

• Baseline (#0, Thu Jul 2 06:02:54): unpatched source; harness vulnerable path shows accumulated=49999 *** ROUTE POISONED ***. baseline_reproduced=1.
• Patch applied: all 6 hunks (patch -p1 ⇒ PATCH_RC=0); the patched TU ieee80211_hwmp.o rebuilt (timestamp 10:28, after the 10:17 apply); the helper appears at :149 and all 5 call sites at :1109/:1346/:1475/:1580/:1996.
• Single-fix kernel built: make -j6 nativekernel KERNCONF=X86_64_GENERIC ⇒ NK_DONE rc=0, Kernel build for X86_64_GENERIC completed, zero diagnostic errors in the 35 537-line build log.
• Installed + booted: /boot/kernel/kernel overwritten with the freshly stripped build (sha256 8bb331f6…); new kern.version = DragonFly 6.5-DEVELOPMENT #1: Thu Jul 16 10:24:22 UTC 2026; clean boot to login prompt, no panic, no hwmp/wlan dmesg errors.
• Fixed arithmetic verified: the harness's FIXED path (byte-for-byte the in-kernel hwmp_metric_add) rejects the attack (accumulated=4294967295 rejected, legit route preserved), RUN_EXIT=0.

fix_status = fixed. The live in-kernel HWMP path is not drivable on this guest (no WiFi HW / no mesh VAP — only vtnet0+lo0), so validation is at the compile + boot + arithmetic-equivalence level (the harness-validated pattern for HW/remote-only findings): the fix demonstrably closes every cited code path, compiles, and boots with no regression, and its arithmetic is proven correct.