[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