DF-4734 — ar5210ResetTxQueue dereferences ah_curchan without the NULL guard both siblings carry

File: sys/dev/netif/ath/ath_hal/ar5210/ar5210_xmit.c:157,180 Severity: Low (latent NULL-deref panic; in-tree call order protects) — certain on the divergence.

Root cause

ar5210ResetTxQueue takes the current channel

157:    const struct ieee80211_channel *chan = AH_PRIVATE(ah)->ah_curchan;

and, for every DATA queue, dereferences it unconditionally:

180:    if (IEEE80211_IS_CHAN_TURBO(chan)) {

IEEE80211_IS_CHAN_TURBO(_c) is ((_c)->ic_flags & IEEE80211_CHAN_TURBO) != 0 (sys/netproto/802_11/_ieee80211.h:268) — a plain deref. ah_curchan is AH_NULL from attach until the first ar5210Reset runs.

Both sibling HALs guard exactly this and annotate why:

• ar5211_xmit.c (ar5211ResetTxQueue): /* NB: chan can be NULL during attach */ followed by if (chan && IEEE80211_IS_CHAN_B(chan)) — chan used nowhere else.
• ar5212_xmit.c (ar5212ResetTxQueue): identical guard, identical comment.

The 5210 HAL missed the guard, and unlike its siblings it uses chan for the whole IFS programming branch (turbo vs normal), so the deref executes on every DATA resetTxQueue call with a NULL channel.

Reachability (why latent)

In-tree order: ath_attach runs ath_hal_reset (sets ah_curchan) before ath_txq_setup calls ath_hal_resettxqueue (if_ath.c:4125-4130), and the only other caller (ath_txq_update) runs after channel changes. So no in-tree path reaches the deref with chan == AH_NULL; a driver variant (or future caller) that sets up/resets a DATA queue before the first channel reset takes a NULL-deref kernel panic. Same "latent, caller-order-protected" class as the DF-4519/4712/4733 family.

Reproduce

Hardware-gated (no Atheros NIC on the guest). Source-confirmed divergence plus fix build-validation:

scp fix.diff guest:/tmp/df4734.diff
vm.sh run_root 'cd /usr/src && patch -p1 < /tmp/df4734.diff && make nativekernel KERNCONF=X86_64_GENERIC'
# expected: BUILD_RC=0, ar5210_xmit.c compiled -Werror (build.log)

Fix

fix.diff: if (chan != AH_NULL && IEEE80211_IS_CHAN_TURBO(chan)) with the siblings' comment — NULL channel takes the normal-mode defaults, matching ar5211/ar5212 semantics (they fall back to INIT_CWMIN when chan is NULL).

VERDICT — DF-4734

Finding

ar5210ResetTxQueue caches AH_PRIVATE(ah)->ah_curchan (ar5210_xmit.c:157) and dereferences it unconditionally in IEEE80211_IS_CHAN_TURBO(chan) (line 180) for every DATA-queue reset. IEEE80211_IS_CHAN_TURBO is a raw (_c)->ic_flags deref (sys/netproto/802_11/_ieee80211.h:268). ah_curchan is NULL from attach until the first ar5210Reset. Both sibling HALs carry an explicit guard with the comment "NB: chan can be NULL during attach" and use chan nowhere unguarded:

• ar5211_xmit.c ar5211ResetTxQueue: if (chan && IEEE80211_IS_CHAN_B(chan))
• ar5212_xmit.c ar5212ResetTxQueue: if (chan && IEEE80211_IS_CHAN_B(chan))

(verified by extracting both functions — chan appears only inside the guard). The 5210 HAL missed it, and its usage is broader (the whole turbo/normal IFS programming branch), so a DATA resetTxQueue before the first channel reset is a NULL-deref kernel panic.

Reachability (latent)

In-tree call order protects: ath_attach performs ath_hal_reset (which sets ah_curchan) before ath_txq_setup → ath_hal_resettxqueue (if_ath.c:4125-4130); the other caller (ath_txq_update) runs on channel changes. No in-tree path reaches the deref with NULL. Same caller-order-protected latent class as DF-4519/4712/4733. Hardware-gated on the guest (no Atheros NIC, verified).

Verification

• Runtime: not possible on the guest (no ar5210 hardware; the HAL is inert).
• Fix build-validated: fix.diff (chan != AH_NULL && + sibling comment) applied to guest /usr/src; single make nativekernel KERNCONF=X86_64_GENERIC build together with DF-4733/DF-4735: BUILD_RC=0, -Werror, ar5210_xmit.c compiled (build.log).

Bottom line

Certain, precisely-scoped cross-version divergence (both siblings guard + annotate; 5210 forgot). Low severity latent NULL-deref panic; one-line fix mirroring siblings, build-validated.

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.