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

[Jeff Johnson]

On 7/31/2026 10:51 AM, Kamil Bienkiewicz wrote:
> 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.

I've cc'd the dev team to have a look at this issue.

There are quite a few error path patches in the pipeline, both internally from
Qualcomm and in public from the community, so if this hasn't already been
addressed, hopefully the dev team can do so. especially since the full
IPQ5332+QCN* support is under internal review.

/jeff