DF-5032 — AR5212 RF gain readback reads 2 words past the 3-word RF bank 7 (2413/2316/2317/5413/2425/2417 radios)

What

ar5212InvalidGainReadback() (ar5212_rfgain.c:123-154) takes the non-5112/5111 branch for the newer AR5212-family radios and extracts the 6-bit gain step from RF bank 7:

gStep = ar5212GetRfField(ar5212GetRfBank(ah, 7), 6, 37, 0);   /* :140 */

ar5212GetRfField() (ar5212_rfgain.c:92-120) walks the bank as bytes: firstBit=37, numBits=6 → rfBuf[4] then rfBuf[5] (see the walk in oob_demo.c, output in oob_demo.log).

But for these radios, bank 7 has only 3 rows in the shared ini tables (sys/dev/netif/ath/ath_hal/ar5212/ar5212.ini):

Reachability gate: the probe state is only armed on 5 GHz channels (or 5112+OFDM) — ar5212PerCalibrationN(), ar5212_reset.c:1085-1094 → ar5212RequestRfgain(); the driver polls ath_hal_getrfgain() each calibration tick (if_ath.c:5401) → ar5212GetRfgain() → ar5212InvalidGainReadback().

Consequently:

• ar5413 (a/b/g, 5 GHz-capable, common card silicon): the OOB read is live on every long calibration cycle on a 5 GHz channel. The 8 bytes past Bank7Data[3] land inside vpdTable_L in the same ath_hal_malloc()'d RF private struct (ar5413.c:35-57,777) — undefined behavior / array OOB in C, but stays inside the allocation.
• ar2425/ar2417: Bank7Data is the final member of ar2425State (ar2425.c:36-45), so the same two reads would be a heap OOB read of 8 bytes past the allocation — but these radios are 2.4 GHz-only, the channel gate (ar5212_reset.c:1090) never arms the probe on them, so the path is dormant unless a 5 GHz channel is ever configured on such a part (e.g. by future band-capability changes).
• ar2413/2316/2317: same struct shape as 5413 (vpd tables follow) and same 2.4 GHz-only gating.

Impact: gStep is garbage derived from adjacent fields → L2/L3/L4, gv->loTrig/hiTrig (ar5212_rfgain.c:143-149) are wrong → the gain-ladder adjust decisions (ar5212AdjustGain) misfire → RF gain calibration misbehaves (link-quality degradation; worst case the radio walks the gain ladder to a rail). The value never leaves the HAL; no disclosure or corruption is reachable from it. Severity: Low (hardware-triggered, no attacker control, functional impact).

Files

• oob_demo.c — replicates ar5212GetRfField's index walk (ar5212_rfgain.c:102-117) for all four call sites in the file and prints the touched word indices against the real N(ar5212Bank7_*) row counts.
• oob_demo.log — its output on the audit guest (exit 1: 5 radios OOB).
• env.txt — guest uname / cc.
• verdict.json / manifest.json.

Build / run (any UNIX with a C compiler; ran on the DragonFly guest)

cc -O2 -o oob_demo oob_demo.c && ./oob_demo

Expected

InvalidGainReadback/else GetRfField(bank7, 6, 37, 0)
  words touched: [4] [5]  (max index 5)
...
ar5413  (else path)   N(ar5212Bank7_5413)    =  3 rows -> index 5 *** OUT OF BOUNDS (reads 2 words past) ***

Kernel-level verification (panic/corruption) is intentionally skipped: Low severity, no memory-safety consequence beyond the intra-struct read on the reachable path, and no AR5412/5413 hardware exists on the audit guest.

Fix

Extend the bank-7 shadow arrays for the affected radios (or clamp the read): simplest correct fix is to make ar5212InvalidGainReadback() use a bank-7 field layout matching each radio family; minimal hardening is to size Bank7Data[] to 6 words minimum in the 2413/2316/2317/5413/2425/2417 RF private structs so the byte-walk stays inside the array. See verdict.json: recommended_fix.

DF-5032 VERDICT — AR5212 rfgain readback OOB read past 3-word bank 7

Status: untested (kernel impact), defect certain (static proof + arithmetic demo run on the guest).

Reproduced or not, and why

• The bounds defect is proven statically and by the index-walk demo (oob_demo.log, run on the DragonFly guest): ar5212GetRfField(bank7, 6, 37, 0) — ar5212_rfgain.c:140 — touches rfBuf[4] and rfBuf[5], while every non-5112/5111 RF backend's bank 7 shadow array has only 3 words (ar5212.ini:1870/1878/1886/2158/2166).
• The kernel path was not executed: the audit guest has no Atheros hardware (and no 5 GHz-capable 5413 card can exist in it), so ar5212GetRfgain() cannot run. Per the audit contract, PoC/Phase-V work is skipped for Low-severity, hardware-only findings.

Reachability (path:line)

ar5212PerCalibrationN (ar5212_reset.c:1085-1094) arms the probe on 5 GHz channels → ar5212RequestRfgain (ar5212_rfgain.c:160-172) → driver polls ath_hal_getrfgain (if_ath.c:5401) → ar5212GetRfgain (ar5212_rfgain.c:279-333) → ar5212InvalidGainReadback:140 → OOB read. Radio gates:

• ar5413: 5 GHz-capable → live path on every calibration cycle; the read lands in vpdTable_L inside the same allocation (ar5413.c:35-57; priv from ath_hal_malloc, ar5413.c:777) → C-level array OOB, no heap violation.
• ar2425/ar2417: Bank7Data is the last member (ar2425.c:36-45) → would be an 8-byte heap OOB read — but 2.4 GHz-only radios never pass the 5 GHz gate (ar5212_reset.c:1090-1091). Dormant.
• ar2413/2316/2317: vpd tables follow Bank7Data (ar2413.c:35-57); 2.4 GHz only → dormant, and intra-struct anyway.

Impact ceiling

gStep (garbage) → wrong loTrig/hiTrig (ar5212_rfgain.c:147-149) → misfiring gain-ladder adjustments (ar5212AdjustGain, :187-237) → RF performance degradation / potential link loss. The read value is never exported (no info leak) and never used as an index/pointer (no corruption). Low severity, CWE-125.

Fix sketch

Keep the byte-walk inside the shadow arrays: bump the affected RF structs' Bank7Data[] to ≥6 words (harmless extra 12 bytes per radio priv), or gate ar5212InvalidGainReadback's gStep extraction to radios whose bank-7 layout actually places bits 33-43 there (5111 only, 8 rows) and treat the newer radios as "never adjust" (gStep == 0x3f semantics already encode that).

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.

(No fix.diff for this item: documented recommendation only - see Fix above.)