# DF-0352 — RANN frame overwrites shared global ieee80211_hwmp_rannint (no lock)

## Verdict
**LATENT — code-level defect confirmed, NOT reachable on this guest.**

The bug is real by source inspection. The audit guest has no WiFi
hardware and no `wlan`/mesh module loaded, so the receive path that
writes the shared global (`hwmp_recv_rann`) is dead code at runtime
here. An unprivileged local user cannot create a WiFi vap, inject a
frame, or load a WiFi driver module — all are root-only operations on
this guest. This is the **"genuinely not reachable on this kernel"**
category with a real latent bug.

## Bug mechanism (source trace)
File: `sys/netproto/802_11/wlan/ieee80211_hwmp.c`.

- Line 183: `static int ieee80211_hwmp_rannint = -1;` — file-scope
  global shared across **all vaps** in the system.
- Lines 184–186: exposed as a writable sysctl
  (`net.wlan_hwmp.rannint`), with no internal locking.
- Line 220: initialized to `msecs_to_ticks(1*1000)` at module load.
- Line 841: `callout_reset(&hs->hs_roottimer, ieee80211_hwmp_rannint, ...)`
  — drives the periodic root-announcement callout period for **every**
  RANN-rooted vap, using the shared global.
- Line 914: same global is read when *sending* a RANN
  (`rann.rann_interval = ieee80211_hwmp_rannint`).
- **Line 1971 (the bug):** inside `hwmp_recv_rann`, on receiving ANY
  RANN frame from the wire:
  ```c
  ieee80211_hwmp_rannint = rann->rann_interval; /* XXX: mtx lock? */
  ```
  The on-the-wire `rann_interval` field (attacker-controlled) is
  written directly into the shared global with **no lock** (the
  `XXX: mtx lock?` comment admits the omission).

## Effects if reachable (realistic threat model)
On a host with a WiFi NIC in mesh mode + HWMP root mode:
- A remote on-link attacker sends a forged RANN with `rann_interval=0`
  (or 1 tick). The victim's RANN callout is reset to that interval,
  producing a tight-loop callout firing every tick — CPU saturation
  on the callout's CPU.
- Concurrent sysctl reads / vap switches race the unlocked write —
  torn reads, possibly bogus callout_reset args.
- The attacker controls `rann_interval` (16-bit), but the effect is
  bounded to "drive callout at attacker-chosen rate"; no direct
  memory corruption in this specific write.

So the realistic impact ceiling is **remote DoS via CPU saturation +
lockless-write race**. No memory-corruption primitive.

## Why not testable on this guest
```
$ ssh dfbsd-maxx 'ifconfig -l'
vtnet0 lo0
$ ssh dfbsd 'kldstat | grep mesh'   # (empty)
$ ssh dfbsd 'pciconf -l | grep -i wireless'   # (empty)
```
No WiFi hardware is presented to the guest. `wlan.ko` exists on disk
but is not loaded (and `kldload` is root-only, hence cannot be part
of an unprivileged chain). A vap cannot be created without a WiFi
driver instance, which itself requires real WiFi hardware or a
software-defined radio — neither available here.

The bug requires: WiFi NIC driver attached + vap in HWMP/RANN root
mode + receiving a forged RANN. None of these can be set up by an
unprivileged user, and none are present by default on the audit
guest.

## Recommended fix
Take `hs->hs_lock` (or the mesh state lock) around the write at
line 1971, AND validate `rann->rann_interval` against a sane
minimum (e.g. reject 0 / very-small values to prevent the
callout-tightening DoS). See `fix.diff`.

## Files in this folder
- `fix.diff`     — adds a lock around the write + a sanity lower-bound
- `VERDICT.md`   — this file
- `manifest.json`
- `env.txt`      — guest environment confirming no WiFi HW