[BUG] ath12k: NULL deref in ath12k_mac_op_hw_scan() when a scan is requested during firmware recovery (IPQ5332 + QCN9274)

[Kamil Bienkiewicz]

On 7/31/2026, Jeff Johnson wrote:
> I've cc'd the dev team to have a look at this issue.

Thank you, much appreciated.

For those just added, a short self-contained summary so you don't have to
read back through the thread.

Platform
  GL.iNet GL-BE9300: IPQ5332 (ath12k AHB, 2.4 GHz) + 2x QCN9274 (PCIe,
  5/6 GHz). OpenWrt "qualcommbe" target, kernel 6.18.39, backports 7.2-rc4.

Failure
  The firmware crashes before QMI is ready. ath12k_core_reset() then
  returns early because ATH12K_FLAG_QMI_FW_READY_COMPLETE is unset (core.c,
  "ignore reset dev flags"), so recovery is skipped by design and the device
  is left half-initialised. An nl80211 scan arriving in that window
  dereferences a pointer that is not valid yet, in
  ath12k_mac_op_hw_scan(). Faulting address is 0x1508 — a small structure
  offset from NULL. The faulting task is hostapd.

Why it reproduces rather than being a one-in-a-thousand race
  hostapd runs the 20/40 MHz coexistence scan when bringing up a 40 MHz BSS
  on 2.4 GHz, and it retries that scan on -EBUSY. So for the entire duration
  of the un-recovered window the driver is asked to scan, over and over.
  Any firmware crash during early boot therefore lands on this reliably.

Provenance of the crashing code
  ath12k_mac_op_hw_scan() in the tree we build is byte-identical to
  drivers/net/wireless/ath/ath12k/mac.c in mainline master — I diffed the
  whole function. None of our out-of-tree ath12k patches touch the scan
  path, and the early-return in ath12k_core_reset() is upstream code as
  well. Our tree only adds a clearer warning and a coredump call there.

Suggested shape of a fix (not a patch, just the contract question)
  If ath12k may legitimately be scanned while a reset has been skipped,
  then ath12k_mac_op_hw_scan() returning -EBUSY or -ENETDOWN rather than
  dereferencing looks correct independent of platform. Both mac80211 and
  hostapd handle a refused scan cleanly — hostapd already retries on -EBUSY
  today.

Workaround we run meanwhile, in case it helps narrow it
  Forcing HT20/EHT20 on the 2.4 GHz radio avoids the coexistence scan
  entirely and the crash stops occurring. That is consistent with the scan
  being the trigger rather than a contributing coincidence.

I have the board on the bench, full pstore/ramoops dumps (complete kernel
log from boot through to the oops), and a reliable trigger. I am happy to
test any patch or debug diff on this hardware with a quick turnaround —
including the error-path work already in the pipeline, if it is expected to
cover this. If it does, I am glad to confirm that rather than have anyone
spend time on a fresh fix.

Thanks,
Kamil