DF-4872 — ar9287Attach: 2GHz-only Kiwi-2 caps never enforced — GMODE divergence re-adds 11A/11NA modes and 5GHz edges survive; enables 5GHz channel selection on 2GHz-only silicon (upstream enabler of the DF-4793 NULL-pier panic)

What was verified (static, line-by-line; no AR9287 silicon on the audit guest)

The full chain from EEPROM opflag to 5GHz channel admission, every hop cited:

1. The AR9287 EEPROM layer explicitly denies A-mode. sys/dev/netif/ath/ath_hal/ah_eeprom_9287.c:73-74 c case AR_EEP_AMODE: return HAL_EIO; /* no 5GHz for Kiwi */ The AR9287 EEPROM image itself carries only 2GHz calibration data: ah_eeprom_9287.h:135-153 — calFreqPier2G[AR9287_NUM_2G_CAL_PIERS], calPierData2G[AR9287_MAX_CHAINS][AR9287_NUM_2G_CAL_PIERS], and a single modalHeader ("only 2.4ghz here; so only one modal header entry", ah_eeprom_9287.c:187). There is no 5GHz pier/target data anywhere.

2. The generic caps builder re-adds 11A anyway via the GMODE divergence. ar9287Attach → ar9287FillCapabilityInfo (sys/dev/netif/ath/ath_hal/ar9002/ar9287_attach.c:321-324, 428-469) calls ar5416FillCapabilityInfo(ah) at line 433 and inherits: - ar5416_attach.c:904-915: when AR_EEP_GMODE is set (every functional 11g card: v9287EepromGet returns OK when opCapFlags & AR5416_OPFLAGS_11G, ah_eeprom_9287.c:75-79; identical polarity in ah_eeprom_v14.c:110-115 and ah_eeprom_v4k.c:83-90), lines 910-914 unconditionally OR HAL_MODE_11A | HAL_MODE_11NA_HT20 | HAL_MODE_11NA_HT40PLUS | HAL_MODE_11NA_HT40MINUS into halWirelessModes — even though the AMODE branch was denied. - ar5416_attach.c:920-921: halLow5GhzChan = 4915; halHigh5GhzChan = 6100; set unconditionally.

3. ar9287FillCapabilityInfo never clamps. Its override block (ar9287_attach.c:435-466) sets ~20 fields (GPIO count, WoW, RIFS, STBC, SGI20, ...) but never touches halWirelessModes, halLow5GhzChan, or halHigh5GhzChan. Unlike the ar9285 twin (DF-4799), nf_5g is populated here (ar9287_attach.c:353-355), so the residual defect for the AR9287 is exactly the caps/edges divergence.

4. halWirelessModes is the channel-admission gate. if_ath.c:6073-6084 ath_getradiocaps() → ath_hal_getchannels(..., HAL_MODE_ALL, ...). In getchannels() (sys/dev/netif/ath/ath_hal/ah_regdomain.c:398-416): c modesAvail = ath_hal_getWirelessModes(ah); /* == halWirelessModes */ ... if ((cm->mode & modeSelect) == 0) continue; /* HAL_MODE_ALL passes */ if ((cm->mode & modesAvail) == 0) continue; /* <-- the only HW gate */ With the divergent 11A/11NA bits set, every 5GHz cmode passes; the 5GHz channel bitmap then comes from the EEPROM regdomain (ah_currentRD = regDmn[0], ar9287_attach.c:334-335, unvalidated u16). ar5212GetChannelEdges (ar5212_attach.c:646-655) hardcodes 4915/6100 for any 5GHZ-flagged mode, so 5GHz bands are admitted.

5. Downstream consequence (already filed at the crash site as DF-4793). Selecting one of those 5GHz channels reaches ar9287SetPowerCalTable (ar9002/ar9287_reset.c): the 9287 EEPROM accessors return a NULL pier list for non-2GHz channels, and the unguarded per-chain walk NULL-derefs pList[0] in ath_ee_getLowerUpperIndex → kernel panic. Even without the panic, the radio is programmed from 2GHz-only calibration data (regulatory misoperation), mirroring DF-4799's impact analysis for the AR9285.

Why no runtime PoC (untested, per family precedent DF-4793/DF-4799/DF-4548)

The trigger requires an AR9287 ("Kite-2") PCIe NIC whose EEPROM carries an 11G opflag (normal) plus a regdomain with 5GHz entries. The single-tenant QEMU/KVM audit guest has no Atheros NIC (no PCIe device assignment), so neither the panic nor the mis-tune can be exercised there. Verification is the static chain above; every hop was opened and read, no hop is assumed.

Threat model

Untrusted-EEPROM (same model as DF-4548/DF-4793/DF-4799): a card with a reprogrammed/corrupt EEPROM (physical access, resold hardware, or a malicious "compat" card). No EEPROM validation happens between the raw image and regDmn[0]/opCapFlags beyond the checksum, which the attacker recomputes. Note the GMODE hop needs nothing unusual at all — every stock 11g AR9287 satisfies it; only the regdomain content decides whether 5GHz channels appear.

Fix

Mask the A-family modes and invalidate the 5GHz edges in ar9287FillCapabilityInfo right after the inherit (see fix.diff). The cleaner companion fix is in ar5416_attach.c:904-915 — the GMODE block should not OR 11A/11NA bits; every 5416-family chip that supports 11A already gets those bits from the AMODE branch — but the per-chip clamp is the minimal, targeted change (matches the fix proposed for DF-4799).

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.