DF-3576 — Divide-by-zero kernel panic in iwn_set_timing() via beacon with bintval=0

What this is

Evidence pack for a remote-triggerable kernel division-by-zero (panic) in sys/dev/netif/iwn/if_iwn.c:5596-5597 (iwn_set_timing()).

Root cause (source trace, all lines verified in this tree)

attacker AP beacons with bintval = 0 (one 16-bit field in an 802.11 beacon)
  -> sys/netproto/802_11/wlan/ieee80211_input.c:545   scan->bintval = le16toh(...)
  -> ieee80211_input.c:700-707    marks IEEE80211_BPARSE_BINTVAL_INVALID
     ...but the STA scan-table consumer NEVER checks that status bit:
  -> sys/netproto/802_11/wlan/ieee80211_scan_sta.c:314  ise->se_intval = sp->bintval;
  -> sys/netproto/802_11/wlan/ieee80211_node.c:818      ni->ni_intval = se->se_intval;   (ieee80211_sta_join)
  -> station completes association (evil-twin AP answers auth/assoc)
  -> iwn_newstate RUN -> iwn_run (if_iwn.c:7237) -> iwn_set_timing (if_iwn.c:5583)
  -> if_iwn.c:5596   val = (uint64_t)ni->ni_intval * IEEE80211_DUR_TU;   == 0
  -> if_iwn.c:5597   mod = le64toh(cmd.tstamp) % val;                    % 0
  -> integer divide error (#DE) in kernel mode -> kernel panic

What this pack proves (and what it cannot)

The QEMU audit guest is virtio-only: it has if_iwn.ko and the driver registered (kldstat -v shows pci/iwn) but no Intel WiFi device, so the in-kernel path cannot be executed end-to-end. Therefore:

1. iwn_timing_div0.c executes the exact arithmetic of iwn_set_timing() (copied verbatim from if_iwn.c:5590-5598) with ni_intval = 0 — the value that a bintval=0 beacon produces through the net80211 chain above. Result: SIGFPE (exit 136), 4/4 runs; the control value (ni_intval = 100) survives. A compile-time-folded division cannot fault, so this is a genuine hardware div/idiv fault — in the kernel it is a fatal #DE.
2. The reachability chain (beacon -> scan cache -> node -> iwn_run) is proven by the source citations above; every hop was read in this tree.

Build / run (on the DragonFly guest)

cc -O2 -Wall -o iwn_timing_div0 iwn_timing_div0.c
./iwn_timing_div0        # expect: control OK, then "Floating point exception", exit 136

Expected output

See run.log — control prints survived, malicious call prints ni_intval=0 -> val=0 ; taking modulo and the process dies with SIGFPE (exit=136). Stress reruns in run.2.log.

Fix

Guard the divisor (mirrors what the driver already does elsewhere, e.g. iwn4965_get_temperature() guards r1 == r3): see fix.diff.

DF-3576 — VERDICT

Status: inconclusive (runtime), source-certain (analysis). Impact: kernel panic (#DE). Reproduced: the fault primitive, yes; the kernel path, not on this guest.

What was verified and how

1. Source-level certainty. Every hop of the chain was read and cited: - sys/dev/netif/iwn/if_iwn.c:5596-5597 — val = (uint64_t)ni->ni_intval * IEEE80211_DUR_TU; followed by mod = le64toh(cmd.tstamp) % val; with no zero check. - iwn_set_timing() is reached from iwn_run() (if_iwn.c:7237) on the IEEE80211_S_RUN transition (association complete). - ni->ni_intval is populated from the scan cache: sys/netproto/802_11/wlan/ieee80211_scan_sta.c:314 (ise->se_intval = sp->bintval;) — the only validation of bintval, IEEE80211_BPARSE_BINTVAL_INVALID (ieee80211_input.c:700-707), is set by the parser but never tested by this consumer (the only status-bit consumers in the tree are ieee80211_hostap.c:1707 and the OFFCHAN branches). ieee80211_sta_join() then copies it unfiltered into the node (sys/netproto/802_11/wlan/ieee80211_node.c:818). - Note ieee80211_init_neighbor() (node.c:1525) copies sp->bintval unvalidated too — same latent issue for other drivers/modes.
2. Runtime primitive. iwn_timing_div0.c runs the verbatim arithmetic with ni_intval == 0 on the audit guest (DragonFly 6.5-DEVELOPMENT, X86_64_GENERIC, gcc 8.3): - control (ni_intval=100): survives, prints a sane binitval. - malicious (ni_intval=0): SIGFPE, exit 136 — deterministic across 4 runs (run.log, run.2.log). Since constant-folded divisions do not fault, this is a real hardware divide fault; in kernel context the same instruction raises #DE and panics the system.

Why not "reproduced"

The guest has no iwn hardware (pciconf -l shows no Intel WiFi device; virtio-only), so the driver's RX/association path cannot be driven end-to-end. The honest classification is: primitive proven at runtime, full chain proven by source trace, end-to-end kernel panic not demonstrated on this guest.

Exploit chain (attack)

1. Attacker runs an evil-twin AP (or injects beacons with a spoofed BSSID of a network the victim auto-joins) whose beacons/probe responses carry bintval = 0.
2. Victim scans: scan cache entry gets se_intval = 0 (validation bit ignored).
3. Victim associates: ieee80211_sta_join → ni->ni_intval = 0.
4. iwn_newstate(RUN) → iwn_run → iwn_set_timing → % 0 → kernel panic.

No memory disclosure, no code execution: impact ceiling is a reliable remote panic/DoS of any iwn-equipped DragonFly station that joins the attacker's AP.

Fix

fix.diff — reject (or clamp) a zero beacon interval in iwn_set_timing before the division. The complementary net80211 hardening (reject IEEE80211_BPARSE_BINTVAL_INVALID entries in sta_add_scan) would protect every driver, not just iwn.

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.