linux.git/drivers/net/wireless/ath, branch master

wifi: ath5k: do not access array OOB

2026-05-04T14:15:20+00:00

Vincent reports:
> The ath5k driver seems to do an array-index-out-of-bounds access as
> shown by the UBSAN kernel message:
> UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20
> index 4 is out of range for type 'ieee80211_tx_rate [4]'
> ...
> Call Trace:
>  
>  dump_stack_lvl+0x5d/0x80
>  ubsan_epilogue+0x5/0x2b
>  __ubsan_handle_out_of_bounds.cold+0x46/0x4b
>  ath5k_tasklet_tx+0x4e0/0x560 [ath5k]
>  tasklet_action_common+0xb5/0x1c0

It is real. 'ts->ts_final_idx' can be 3 on 5212, so:
   info->status.rates[ts->ts_final_idx + 1].idx = -1;
with the array defined as:
   struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES];
while the size is:
   #define IEEE80211_TX_MAX_RATES  4
is indeed bogus.

Set this 'idx = -1' sentinel only if the array index is less than the
array size. As mac80211 will not look at rates beyond the size
(IEEE80211_TX_MAX_RATES).

Note: The effect of the OOB write is negligible. It just overwrites the
next member of info->status, i.e. ack_signal.

Signed-off-by: Jiri Slaby (SUSE) 
Reported-by: Vincent Danjean 
Link: https://lore.kernel.org/all/aQYUkIaT87ccDCin@eldamar.lan
Closes: https://bugs.debian.org/1119093
Fixes: 6d7b97b23e11 ("ath5k: fix tx status reporting issues")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251209100459.2253198-1-jirislaby@kernel.org
Signed-off-by: Jeff Johnson

wifi: ath12k: fix peer_id usage in normal RX path

2026-05-04T14:15:20+00:00

ath12k_dp_rx_deliver_msdu() currently uses hal_rx_desc_data::peer_id
parsed from mpdu_start descriptor to do peer lookup. However In an A-MSDU
aggregation scenario, hardware only populates mpdu_start descriptor for
the first sub-msdu, but not the following ones. In that case peer_id could
be invalid, leading to peer lookup failure:

ath12k_wifi7_pci 0000:06:00.0: rx skb 00000000c391c041 len 1532 peer (null) 0 ucast sn 0 eht320 rate_idx 12 vht_nss 2 freq 6105 band 3 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0

As a result pubsta is NULL and parts of ieee80211_rx_status structure are
left uninitialized, which may cause unexpected behavior.

Fix it by switching the normal RX path to use ath12k_skb_rxcb::peer_id
which is parsed from REO ring's rx_mpdu_desc and is always valid.

hal_rx_desc_data::peer_id is still used in
ath12k_wifi7_dp_rx_frag_h_mpdu(), which is safe since A-MSDU
aggregation does not occur for fragmented frames. Similarly,
ath12k_skb_rxcb::peer_id may be overwritten by hal_rx_desc_data::peer_id
in ath12k_wifi7_dp_rx_h_mpdu(), which only handles non-aggregated
multicast/broadcast traffic.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

Fixes: 11157e0910fd ("wifi: ath12k: Use ath12k_dp_peer in per packet Tx & Rx paths")
Signed-off-by: Baochen Qiang 
Reviewed-by: Rameshkumar Sundaram 
Link: https://patch.msgid.link/20260427-ath12k-fix-peer-id-source-v1-1-b5f701fb8e88@oss.qualcomm.com
Signed-off-by: Jeff Johnson

wifi: ath12k: initialize RSSI dBm conversion event state

2026-05-04T14:15:20+00:00

Currently, the RSSI dBm conversion event handler leaves struct
ath12k_wmi_rssi_dbm_conv_info_arg uninitialized on the stack before
calling the TLV parser. If one of the optional sub-TLVs is absent, the
corresponding *_present flag retains stack garbage and later gets read
in ath12k_wmi_update_rssi_offsets(). With UBSAN enabled this triggers an
invalid-load report for _Bool:

UBSAN: invalid-load in drivers/net/wireless/ath/ath12k/wmi.c:9682:15
load of value 9 is not a valid value for type '_Bool'
Call Trace:
 ath12k_wmi_rssi_dbm_conversion_params_info_event.cold+0x72/0x85 [ath12k]
 ath12k_wmi_op_rx+0x1871/0x2ab0 [ath12k]
 ath12k_htc_rx_completion_handler+0x44b/0x810 [ath12k]
 ath12k_ce_recv_process_cb+0x554/0x9f0 [ath12k]
 ath12k_ce_per_engine_service+0xbe/0xf0 [ath12k]
 ath12k_pci_ce_workqueue+0x69/0x120 [ath12k]

Initialize the parsed event state to zero before passing it to the TLV
parser so missing sub-TLVs correctly leave the presence flags false.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

Fixes: 0314ee81a91d ("wifi: ath12k: handle WMI event for real noise floor calculation")
Signed-off-by: Rameshkumar Sundaram 
Reviewed-by: Baochen Qiang 
Link: https://patch.msgid.link/20260427103011.2983269-1-rameshkumar.sundaram@oss.qualcomm.com
Signed-off-by: Jeff Johnson

wifi: ath12k: fix leak in some ath12k_wmi_xxx() functions

2026-05-04T14:15:19+00:00

Some wmi functions were using plain 'return ath12k_wmi_cmd_send(...)'
without explicitly handling the error code. This leads to leaking the skb
in case of error.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1

Fixes: 66a9448b1b89 ("wifi: ath12k: implement hardware data filter")
Fixes: 593174170919 ("wifi: ath12k: implement WoW enable and wakeup commands")
Fixes: 4a3c212eee0e ("wifi: ath12k: add basic WoW functionalities")
Fixes: 16f474d6d49d ("wifi: ath12k: add WoW net-detect functionality")
Fixes: 1666108c74c4 ("wifi: ath12k: support ARP and NS offload")
Fixes: aab4ae566fa1 ("wifi: ath12k: support GTK rekey offload")
Fixes: 7af01e569529 ("wifi: ath12k: handle keepalive during WoWLAN suspend and resume")
Signed-off-by: Nicolas Escande 
Reviewed-by: Baochen Qiang 
Reviewed-by: Vasanthakumar Thiagarajan 
Link: https://patch.msgid.link/20260422163258.3013872-1-nico.escande@gmail.com
Signed-off-by: Jeff Johnson

wifi: ath12k: use lockdep_assert_in_rcu_read_lock() for RCU assertions

2026-04-23T17:57:50+00:00

Two functions in ath12k assert that the caller holds an RCU read lock:
ath12k_mac_get_arvif() and ath12k_p2p_noa_update_vdev_iter(). Both use:

    WARN_ON(!rcu_read_lock_any_held());

On kernels using preemptible RCU (CONFIG_PREEMPT=y or CONFIG_PREEMPT_RT=y)
without CONFIG_DEBUG_LOCK_ALLOC, this produces a false positive splat
whenever these functions are invoked from paths that do hold the RCU
read lock (e.g. firmware stats processing or mac80211 interface
iteration).

Root cause:

  - Without CONFIG_DEBUG_LOCK_ALLOC, rcu_read_lock_any_held() is a
    static inline that returns !preemptible() as a proxy for "in an
    RCU read section".

  - With preemptible RCU, rcu_read_lock() does not disable preemption.
    A task can therefore be preemptible while legitimately holding an
    RCU read lock, making the proxy unreliable.

  - Callers such as ath12k_wmi_tlv_rssi_chain_parse() (via guard(rcu)())
    and ieee80211_iterate_active_interfaces_atomic() do hold the RCU
    read lock, so these warnings are incorrect.

Typical splat seen on a WCN7850 station with periodic fw stats
processing:

  WARNING: drivers/net/wireless/ath/ath12k/mac.c:791 at
    ath12k_mac_get_arvif+0x9e/0xd0 [ath12k]
  Tainted: G W O 6.19.13-rt #1 PREEMPT_RT
  Call Trace:
   ath12k_wmi_tlv_rssi_chain_parse+0x69/0x170 [ath12k]
   ath12k_wmi_tlv_iter+0x7f/0x120 [ath12k]
   ath12k_wmi_tlv_fw_stats_parse+0x342/0x6b0 [ath12k]
   ath12k_wmi_op_rx+0xe9e/0x3150 [ath12k]
   ath12k_htc_rx_completion_handler+0x3df/0x5b0 [ath12k]
   ath12k_ce_per_engine_service+0x325/0x3e0 [ath12k]
   ath12k_pci_ce_workqueue+0x20/0x40 [ath12k]

Replace WARN_ON(!rcu_read_lock_any_held()) with
lockdep_assert_in_rcu_read_lock(), which is gated on CONFIG_PROVE_RCU
and therefore compiles out entirely when PROVE_RCU is disabled.
PROVE_RCU kernels continue to get the full lockdep-based check, and
the new helper precisely checks for rcu_read_lock() rather than any
RCU variant, which better matches the callers' expectations.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

Fixes: 3dd2c68f206e ("wifi: ath12k: prepare vif data structure for MLO handling")
Suggested-by: Baochen Qiang 
Suggested-by: Sebastian Andrzej Siewior 
Reviewed-by: Baochen Qiang 
Reviewed-by: Rameshkumar Sundaram 
Signed-off-by: Yu-Hsiang Tseng 
Reviewed-by: Sebastian Andrzej Siewior 
Link: https://patch.msgid.link/20260422180814.1938317-1-asas1asas200@gmail.com
Signed-off-by: Jeff Johnson

wifi: ath10k: snoc: select POWER_SEQUENCING

2026-04-23T17:57:50+00:00

The commit afcf3ec615c9 ("wifi: ath10k: snoc: support powering on the
device via pwrseq") made ath10k SNOC driver use devm_pwrseq_get().
Select the corresponding Kconfig symbol to make sure that API call is
always available and doesn't return an error per se.

Fixes: afcf3ec615c9 ("wifi: ath10k: snoc: support powering on the device via pwrseq")
Reported-by: Luca Weiss 
Closes: https://lore.kernel.org/r/DHUHU7UIT487.139L3KIVRVREU@fairphone.com
Signed-off-by: Dmitry Baryshkov 
Reviewed-by: Rameshkumar Sundaram 
Link: https://patch.msgid.link/20260418-ath10k-snoc-pwrseq-v1-1-832594ba3294@oss.qualcomm.com
Signed-off-by: Jeff Johnson

wifi: ath12k: fix OF node refcount imbalance in WSI graph traversal

2026-04-23T17:57:49+00:00

ath12k_core_get_wsi_info() traverses the WSI (Wired Serial Interface)
device graph starting from dev->of_node. The current code uses
dev->of_node directly as the local traversal pointer and calls
of_node_put() on error.

Since the driver does not own a reference to dev->of_node, dropping it
during traversal results in the following OF refcount underflow:

OF: ERROR: of_node_release() detected bad of_node_put() on /soc@0/wifi@c000000
CPU: 1 UID: 0 PID: 210 Comm: insmod Not tainted 6.19.0-rc4-next-20260109-00023-g797dd36dc178 #26 PREEMPT
Hardware name: Qualcomm Technologies, Inc. IPQ5332 MI01.2 (DT)
Call trace:
 show_stack+0x18/0x24 (C)
 dump_stack_lvl+0x60/0x80
 dump_stack+0x18/0x24
 of_node_release+0x164/0x1a0
 kobject_put+0xb4/0x278
 of_node_put+0x18/0x28
 ath12k_core_init+0x29c/0x5d4 [ath12k]
 ath12k_ahb_probe+0x950/0xc14 [ath12k]
 platform_probe+0x5c/0xa4
 really_probe+0xc0/0x3ec
 __driver_probe_device+0x80/0x170
 driver_probe_device+0x3c/0x120
 __driver_attach+0xc4/0x218
OF: ERROR: next of_node_put() on this node will result in a kobject warning 'refcount_t: underflow; use-after-free.'

Fix this by explicitly acquiring a reference to the starting node
using of_node_get() and attaching automatic cleanup via
__free(device_node).

Each discovered WSI node is stored in ag->wsi_node[] with its own
of_node_get() reference. These references are later released in
ath12k_core_free_wsi_info() during driver teardown.

Also remove unnecessary memset() of wsi_node array since cleanup now
explicitly sets pointers to NULL.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1

Fixes: 908c10c860e0 ("wifi: ath12k: parse multiple device information from Device Tree")
Signed-off-by: Aaradhana Sahu 
Reviewed-by: Rameshkumar Sundaram 
Reviewed-by: Baochen Qiang 
Link: https://patch.msgid.link/20260410071300.2323603-1-aaradhana.sahu@oss.qualcomm.com
Signed-off-by: Jeff Johnson

wifi: ath12k: prepare REO update element only for primary link

2026-04-23T17:57:49+00:00

Commit [1] introduces dp->reo_cmd_update_rx_queue_list for the purpose
of tracking all pending REO queue flush commands. The helper
ath12k_dp_prepare_reo_update_elem() allocates an element and populates
it with REO queue information, then add it to the list. The element would
be helpful during clean up stage to finally unmap/free the corresponding
REO queue buffer.

In MLO scenarios with more than one links, for non dp_primary_link_only
chips like WCN7850, that helper is called for each link peer. This
results in multiple elements added to the list but all of them pointing
to the same REO queue buffer. Consequently the same buffer gets
unmap/freed multiple times:

BUG kmalloc-2k (Tainted: G    B   W  O       ): Object already free
-----------------------------------------------------------------------------
Allocated in ath12k_wifi7_dp_rx_assign_reoq+0xce/0x280 [ath12k_wifi7] age=7436 cpu=10 pid=16130
 __kmalloc_noprof
 ath12k_wifi7_dp_rx_assign_reoq
 ath12k_dp_rx_peer_tid_setup
 ath12k_dp_peer_setup
 ath12k_mac_station_add
 ath12k_mac_op_sta_state
 [...]
Freed in ath12k_dp_rx_tid_cleanup.part.0+0x25/0x40 [ath12k] age=1 cpu=27 pid=16137
 kfree
 ath12k_dp_rx_tid_cleanup.part.0
 ath12k_dp_rx_reo_cmd_list_cleanup
 ath12k_dp_cmn_device_deinit
 ath12k_core_stop
 ath12k_core_hw_group_cleanup
 ath12k_pci_remove

Fix this by allowing list addition for primary link only. Note
dp_primary_link_only chips like QCN9274 are not affected by this change,
because that's what they were doing in the first place.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

Fixes: 3bf2e57e7d6c ("wifi: ath12k: Add Retry Mechanism for REO RX Queue Update Failures") # [1]
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221011
Signed-off-by: Baochen Qiang 
Reviewed-by: Vasanthakumar Thiagarajan 
Link: https://patch.msgid.link/20260210-ath12k-rxtid-double-free-v1-1-8b523fb2886d@oss.qualcomm.com
Signed-off-by: Jeff Johnson

wifi: ath10k: Add device-tree quirk to skip host cap QMI requests

2026-04-08T17:13:09+00:00

Some firmware versions do not support the host capability QMI request.
Since this request occurs before firmware-N.bin and board-M.bin are
loaded, the quirk cannot be expressed in the firmware itself.

The root cause is unclear, but there appears to be a generation of
firmware that lacks host capability support.

Without this quirk, ath10k_qmi_host_cap_send_sync() returns
QMI_ERR_MALFORMED_MSG_V01 before loading the firmware. This error is not
fatal - Wi-Fi services still come up successfully if the request is simply
skipped.

Add a device-tree quirk to skip the host capability QMI request on devices
whose firmware does not support it.

For example, firmware build
"QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1"
on Xiaomi Poco F1 phone requires this quirk.

Suggested-by: Bjorn Andersson 
Signed-off-by: Amit Pundir 
Tested-by: Paul Sajna 
Reviewed-by: Baochen Qiang 
Reviewed-by: Vasanthakumar Thiagarajan 
Acked-by: Dmitry Baryshkov 
Signed-off-by: David Heidelberg 
Link: https://patch.msgid.link/20260407-skip-host-cam-qmi-req-v5-2-dfa8a05c6538@ixit.cz
Signed-off-by: Jeff Johnson

wifi: ath12k: Use michael_mic() from cfg80211

2026-04-08T06:55:15+00:00

Just use the michael_mic() function from cfg80211 instead of a local
implementation of it using the crypto_shash API.

Note: when the kernel is booted with fips=1,
crypto_alloc_shash("michael_mic", 0, 0) always returned
ERR_PTR(-ENOENT), because Michael MIC is not a "FIPS allowed" algorithm.
For now, just preserve that behavior exactly, to ensure that TKIP is not
allowed to be used in FIPS mode.  This logic actually seems to disable
the entire driver in FIPS mode and not just TKIP, but that was the
existing behavior.  Supporting this driver in FIPS mode, if anyone
actually needs it there, should be a separate commit.

Signed-off-by: Eric Biggers 
Link: https://patch.msgid.link/20260408030651.80336-5-ebiggers@kernel.org
Signed-off-by: Johannes Berg