# VERDICT — DF-3595

**Status: inconclusive at runtime (no bwn hardware on the audit guest); defect source-certain.**
**Impact: kernel NULL-deref panic (local DoS) via error-path lifetime bug.**

## Root cause (path:line)

Two failure paths clear `sc->sc_curmac` to NULL without clearing
`BWN_FLAG_RUNNING` or otherwise quiescing the softc:

1. `bwn_switch_band()` — on `bwn_core_init(up_dev)` failure:
   `fail: sc->sc_curmac = NULL; return (err);`
   (`sys/dev/netif/bwn/bwn/if_bwn.c:4763-4765`).
2. `bwn_hwreset()` — on `bwn_core_init(mac)` failure:
   `sc->sc_curmac = NULL;` (`if_bwn.c:5363-5366`).

In both cases the interface was previously up (`bwn_init()` set
`BWN_FLAG_RUNNING` at `:2032`; callers of `bwn_set_channel` ignore the
band-switch error — `:1906-1908` only jumps to the radiotap tail — and
`bwn_restart` schedules hwreset from interrupt context at `:5064`).

Every subsequent state-changing entry point that trusts `sc_curmac` then
dereferences NULL:

* `bwn_stop()`: `struct bwn_mac *mac = sc->sc_curmac;` (`:2042`) …
  `if (mac->mac_status >= BWN_MAC_STATUS_INITED)` (`:2048`) — NULL deref.
  Reached from `bwn_parent()` (`:910`), `bwn_suspend()` (`:7374`), and
  `bwn_detach()` (`:791-794` — note `bwn_detach` also fetches `mac` at `:783`
  and calls `bwn_dma_free(mac)` at `:795` unconditionally for attached
  devices).
* Contrast: `bwn_start()` *does* check (`mac == NULL ||` at `:949`), and
  `bwn_update_promisc`/`bwn_wme_update` re-fetch with NULL guards
  (`:1827-1828`, `:1850-1851`) — the author knew `sc_curmac` can be NULL and
  guarded the TX/promisc paths but not stop/detach/suspend.

Reachability of the failure itself: `bwn_core_init` fails whenever firmware
re-load fails (`bwn_fw_fillinfo → bwn_fw_get → firmware_get` ENOENT,
`if_bwn.c:2298`), PMU/powerup issues, or PHY re-init errors — a realistic
field state on systems whose firmware files disappear after first load, or on
a malicious card that fails the second init deliberately. The error paths at
`:4764`/`:5365` then arm the panic for the *next* ifconfig down/detach.

## Why runtime reproduction was not possible

Same as DF-3593/3594: no Broadcom card on the guest (`run.log`). The
attach→init→band-switch-fail→stop sequence cannot be entered.

## Fix

Treat curmac==NULL as already-down in `bwn_stop()` (and guard `bwn_detach`'s
`bwn_dma_free`), or clear `BWN_FLAG_RUNNING` when nulled — see `fix.diff`.

## Artifacts

* `probe.sh`, `run.log` — guest probe (driver residency + hardware absence)
* `fix.diff` — proposed patch vs read-only `sys/` tree (never applied)

## 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.