# DF-0713 — cac_timeout NULL-deref

## Summary

`ieee80211_dfs.c:154` assigns `dfs->newchan` (which may be NULL, from
`ieee80211_dfs_pickchannel` returning NULL when all channels are
radar-marked) to `vap->iv_des_chan` without converting NULL to the
`IEEE80211_CHAN_ANYC` (0xffff) sentinel. Downstream hostap/adhoc/mesh/
scan_sta/regdomain code guards with `iv_des_chan != IEEE80211_CHAN_ANYC`
(not `!= NULL`), so NULL passes the guard and `IEEE80211_IS_CHAN_RADAR(NULL)`
dereferences `NULL->ic_state` (offset 0x0A) → kernel panic.

## Build

```
./build.sh    # no compilation (shell-only PoC)
```

## Run

```
./run.sh      # copies trigger.sh to guest, runs as maxx
```

## Expected (on a system WITH DFS-capable wireless hardware)

Kernel panic — NULL pointer dereference in `IEEE80211_IS_CHAN_RADAR` /
`iv_des_chan->ic_freq` during the SCAN state transition after `cac_timeout`
sets `iv_des_chan = NULL`.

## Expected (on this guest — no wireless hardware)

The trigger script reports "cannot trigger on this guest (no wireless
hardware)" because no wlan vap can be created without a parent radio
device. The bug is confirmed real by source-level trace (see VERDICT.md).

## Preconditions

- A DFS-capable 802.11 wireless NIC (e.g. Atheros ath(4) in 5GHz DFS channels)
- A hostap/adhoc/mesh vap created on a DFS channel with CAC in progress
- Radar detected on the bss channel while CAC is pending
- All alternative channels also radar-marked (so `pickchannel` returns NULL)
- The `net.wlan.N.radar` sysctl (root-writable) can simulate the radar event

## Fix

See `fix.diff` — convert NULL to `IEEE80211_CHAN_ANYC` at the assignment site.