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

[Kamil Bienkiewicz <perceivalpercy@gmail.com>]

On 7/31/2026, Jeff Johnson wrote:
> Unless you reproduce this with the upstream kernel you should be reporting
> this to the OpenWrt team, not here.

Understood, and I realise the taint makes this hard to act on. Two things
that may change the calculus, and then I will happily take it elsewhere.

First, the reproduction you are asking for is not available to me: this
board is IPQ5332 with the wifi7 AHB path, and that platform has no mainline
support at all — there is no upstream kernel that boots it. So "reproduce on
upstream" is not a bar I can clear on this hardware, rather than one I have
not bothered with.

Second, and more usefully: the code that crashes carries no local changes.

  - ath12k_mac_op_hw_scan() in the backports tree we build is byte-identical
    to drivers/net/wireless/ath/ath12k/mac.c in mainline master. I diffed the
    whole function; there is no delta.
  - None of the out-of-tree ath12k patches in our build touch the scan path.
  - The condition that leaves the device un-recovered is also upstream code.
    ath12k_core_reset() returns early when ATH12K_FLAG_QMI_FW_READY_COMPLETE
    is unset (core.c, "ignore reset dev flags"), so a firmware crash during
    early boot skips recovery entirely. Our tree only adds a clearer warning
    and a coredump call at that point; the control flow is yours.

That is the whole failure: firmware dies before QMI ready, recovery is
skipped by design, the device stays half-initialised, and an nl80211 scan
arriving in that window dereferences a pointer that is not valid yet.
Faulting address 0x1508 is a small structure offset from NULL, and the
faulting task is hostapd — it is running the 20/40 MHz coexistence scan for
a 40 MHz BSS on 2.4 GHz, and hostapd retries that on -EBUSY, so the driver
gets asked repeatedly for the whole recovery window.

I am not asking you to take a fix on this evidence. But if the intended
contract is that ath12k may be scanned while a reset has been skipped, then
ath12k_mac_op_hw_scan() failing the scan (-EBUSY or -ENETDOWN) rather than
dereferencing looks like the correct behaviour regardless of platform, and
both mac80211 and hostapd handle a refused scan cleanly — hostapd already
retries on -EBUSY today.

If you would still prefer this against OpenWrt, say so and I will file it
there. I have full pstore dumps (dmesg-ramoops with the complete log from
boot to oops) and a deterministic trigger, and I am happy to test any patch
on this hardware.

Thanks,
Kamil