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

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

[Kamil Bienkiewicz]

Hi,

A scan request that arrives while the device is recovering from a firmware
crash oopses the kernel in ath12k_mac_op_hw_scan(). Because the oops reboots
the AP and the same firmware crash tends to recur on the next boot, this
presents as a boot loop rather than a one-off crash.

Hardware:  GL.iNet GL-BE9300 (Flint 3) - IPQ5332 (ath12k_wifi7 AHB, 2.4 GHz)
           + QCN9274 (ath12k_wifi7_pci, 5/6 GHz)
Kernel:    6.18.39, OpenWrt build, ath12k as out-of-tree module (Tainted: O)
Firmware:  fw_version 0x160484db, build 2025-12-09 20:09
Trigger:   hostapd's 20/40 MHz coexistence scan (HT_SCAN) on 2.4 GHz

Sequence, single boot, kernel timestamps:

  [39.670790] qcom-wcss-secure-pil d100000.remoteproc: fatal error without message
  [39.670790] remoteproc remoteproc0: crash detected in q6wcss: type fatal error
  [39.684304] remoteproc remoteproc0: recovering q6wcss
  [55.548545] ath12k_wifi7_pci 0001:01:00.0: firmware crashed: MHI_CB_EE_RDDM
  [56.476959] ath12k_wifi7_pci 0001:01:00.0: Uploading coredump
  [57.777482] Unable to handle kernel access to user memory outside uaccess
              routines at virtual address 0000000000001508
  [57.836328] [0000000000001508] pgd=0000000000000000, p4d=0000000000000000,
              pud=0000000000000000
  [57.842705] Internal error: Oops: 0000000096000005 [#1]  SMP
  [57.889448] CPU: 3 UID: 101 PID: 3410 Comm: hostapd Tainted: G O 6.18.39 #0
  [57.929380] pc : ath12k_mac_op_hw_scan+0x2a0/0x714 [ath12k]
  [57.936322] lr : ath12k_mac_op_hw_scan+0x260/0x714 [ath12k]

  Call trace:
    ath12k_mac_op_hw_scan+0x2a0/0x714 [ath12k] (P)
    ieee80211_can_leave_ch+0x500/0x7a8 [mac80211]
    ieee80211_request_scan+0x10/0x20 [mac80211]
    ieee80211_scan+0x74/0x80 [mac80211]
    cfg80211_scan+0x178/0x1dc [cfg80211]
    nl80211_trigger_scan+0x4ec/0x754 [cfg80211]
    genl_family_rcv_msg_doit+0xcc/0x140
    genl_rcv_msg+0x1b8/0x250
    netlink_rcv_skb+0x60/0x130
    genl_rcv+0x38/0x50
    netlink_unicast+0x210/0x308
    netlink_sendmsg+0x178/0x380
    ____sys_sendmsg+0x1e8/0x250
    ___sys_sendmsg+0x80/0xc8
    __sys_sendmsg+0x60/0xc4
    __arm64_sys_sendmsg+0x24/0x34
    invoke_syscall.constprop.0+0x4c/0xc0
    do_el0_svc+0x40/0xc0
    el0_svc+0x24/0xd0
    el0t_64_sync_handler+0xa0/0xf0
    el0t_64_sync+0x180/0x184
  Code: 93407e78 f9435c15 b40000f5 f9400ab9 (f94a8720)

The faulting address 0x1508 is a small structure offset from a NULL base,
not a wild pointer, so this looks like a member being read off a pointer
that is NULL while the device is in recovery.

Why hostapd keeps asking:

Both radios go down first - the AHB q6wcss takes a fatal error, then the
PCIe QCN9274 enters MHI RDDM. hostapd is meanwhile bringing up a 40 MHz BSS
on 2.4 GHz, which requires the 20/40 MHz coexistence scan, and its scan
requests are rejected while the hardware is busy:

  hostapd: phy0.0-ap0: interface state COUNTRY_UPDATE->HT_SCAN
  hostapd: Failed to request a scan of neighboring BSSes ret=-16
           (Resource busy) - try to scan again

hostapd retries, so the driver is asked to scan repeatedly for as long as
recovery lasts, and one of those requests hits the window where the oops
occurs. This is why it reproduces most reliably on the first boot after a
flash, when all three radios initialise simultaneously.

Workaround that avoids the trigger entirely (does not fix the driver):
configure 2.4 GHz for 20 MHz, or set noscan=1 in hostapd, so no coexistence
scan is ever requested. Both stop the crash here.

Suggested direction: ath12k_mac_op_hw_scan() should fail the scan with
-EBUSY (or -ENETDOWN) while the device is in recovery / not fully
reinitialised, rather than proceeding to dereference. mac80211 and hostapd
both handle a rejected scan gracefully - hostapd already retries on -EBUSY.

I have the full pstore dumps (dmesg-ramoops with the complete log from boot
to oops, plus the previous boot's console) and can provide them, test
patches on this hardware, or run with extra instrumentation. The board has
no usable serial console, so the trace above was recovered via ramoops.

Thanks,
Kamil Bienkiewicz

Re: [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 2:41 AM, Kamil Bienkiewicz wrote:
> Hi,
> 
> A scan request that arrives while the device is recovering from a firmware
> crash oopses the kernel in ath12k_mac_op_hw_scan(). Because the oops reboots
> the AP and the same firmware crash tends to recur on the next boot, this
> presents as a boot loop rather than a one-off crash.
> 
> Hardware:  GL.iNet GL-BE9300 (Flint 3) - IPQ5332 (ath12k_wifi7 AHB, 2.4 GHz)
>            + QCN9274 (ath12k_wifi7_pci, 5/6 GHz)
> Kernel:    6.18.39, OpenWrt build, ath12k as out-of-tree module (Tainted: O)

Unless you reproduce this with the upstream kernel you should be reporting
this to the OpenWrt team, not here.

If you reproduce with the upstream kernel, see:
https://wireless.docs.kernel.org/en/latest/en/users/drivers/ath12k/bugreport.html

/jeff

Re: [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:
> 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

Re: [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

Re: [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