<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/wireless, branch v6.6.142</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.142</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.142'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-01T15:43:14+00:00</updated>
<entry>
<title>wifi: ath11k: fix peer resolution on rx path when peer_id=0</title>
<updated>2026-06-01T15:43:14+00:00</updated>
<author>
<name>Matthew Leach</name>
<email>matthew.leach@collabora.com</email>
</author>
<published>2026-04-24T09:50:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=69a0885079c97b4e961d04392aa331b9b44655a6'/>
<id>urn:sha1:69a0885079c97b4e961d04392aa331b9b44655a6</id>
<content type='text'>
[ Upstream commit 2a2451a34afdf563b3102d36a4b6cf335cf813e2 ]

It has been observed that on certain chipsets a peer can be assigned
peer_id=0. For reception of non-aggregated MPDUs this is fine as
ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer
based upon the source MAC address. On an aggregated link, the mpdu_start
header is only populated by hardware on the first sub-MSDU. This causes
the peer resolution to be skipped for the subsequent MSDUs and the
encryption type of these frames to be set to an incorrect value,
resulting in these MSDUs being dropped by ieee80211.

ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0
ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1

Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and
ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID
of 0 to be resolved.

Tested-on: QCA2066 hw2.1 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.9

Fixes: 2167fa606c0f ("ath11k: Add support for RX decapsulation offload")
Reviewed-by: Baochen Qiang &lt;baochen.qiang@oss.qualcomm.com&gt;
Signed-off-by: Matthew Leach &lt;matthew.leach@collabora.com&gt;
Reviewed-by: P Praneesh &lt;praneesh.p@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260424-ath11k-null-peerid-workaround-v4-1-252b224d3cf6@collabora.com
Signed-off-by: Jeff Johnson &lt;jeff.johnson@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: ath11k: fix error path leak in ath11k_tm_cmd_wmi_ftm()</title>
<updated>2026-06-01T15:43:12+00:00</updated>
<author>
<name>Nicolas Escande</name>
<email>nico.escande@gmail.com</email>
</author>
<published>2026-05-06T13:42:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a5db6a7c062f99f5ddf21a47c3650da05068fee4'/>
<id>urn:sha1:a5db6a7c062f99f5ddf21a47c3650da05068fee4</id>
<content type='text'>
[ Upstream commit 7320d6eb861e9913193a7801834c661381756a79 ]

This is similar to what was fixed by previous patches. We have a call
to ath11k_wmi_cmd_send() which does check the return value, but forgot
to free the related skb on error.

Fixes: b43310e44edc ("wifi: ath11k: factory test mode support")
Signed-off-by: Nicolas Escande &lt;nico.escande@gmail.com&gt;
Reviewed-by: Baochen Qiang &lt;baochen.qiang@oss.qualcomm.com&gt;
Reviewed-by: Rameshkumar Sundaram &lt;rameshkumar.sundaram@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260506134240.2284016-4-nico.escande@gmail.com
Signed-off-by: Jeff Johnson &lt;jeff.johnson@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: ath11k: fix error path leaks in some WMI WOW calls</title>
<updated>2026-06-01T15:43:12+00:00</updated>
<author>
<name>Nicolas Escande</name>
<email>nico.escande@gmail.com</email>
</author>
<published>2026-05-06T13:42:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3d675896ea03aca631852a2a7e91e6cb8f664967'/>
<id>urn:sha1:3d675896ea03aca631852a2a7e91e6cb8f664967</id>
<content type='text'>
[ Upstream commit 55dda532bbc261aef495e403c8900c5e2ab5fa34 ]

Fix two instances where we used to directly return the result of
ath11k_wmi_cmd_send(...). Because we did not check the return value, we
also did not free the skb in the error path.

Fixes: 79802b13a492 ("ath11k: implement WoW enable and wakeup commands")
Signed-off-by: Nicolas Escande &lt;nico.escande@gmail.com&gt;
Reviewed-by: Baochen Qiang &lt;baochen.qiang@oss.qualcomm.com&gt;
Reviewed-by: Rameshkumar Sundaram &lt;rameshkumar.sundaram@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260506134240.2284016-2-nico.escande@gmail.com
Signed-off-by: Jeff Johnson &lt;jeff.johnson@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: ath11k: clear shared SRNG pointer state on restart</title>
<updated>2026-06-01T15:43:07+00:00</updated>
<author>
<name>Kyle Farnung</name>
<email>kfarnung@gmail.com</email>
</author>
<published>2026-05-14T04:52:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f50c3ff97c83468a101d665ba168bd4b72657610'/>
<id>urn:sha1:f50c3ff97c83468a101d665ba168bd4b72657610</id>
<content type='text'>
commit f51e4b3b5574ad8cb5b16b11f8a1452147ece87a upstream.

LMAC rings reuse the shared rdp/wrp pointer buffers without going
through the normal SRNG hw-init path that zeros non-LMAC ring
pointers. After restart, ath11k_hal_srng_clear() can therefore hand
stale hp/tp state from the previous firmware instance back to the new
one.

Clear the shared pointer buffers while keeping the allocations in
place so restart still avoids reallocating SRNG DMA memory, but starts
with fresh ring-pointer state.

Fixes: 32be3ca4cf78b ("wifi: ath11k: HAL SRNG: don't deinitialize and re-initialize again")
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/all/CAOPSVF04q6uvVdq8GTRLHBrVMdpt9=o9wVcFMc6f-yhmSBcZqQ@mail.gmail.com/
Signed-off-by: Kyle Farnung &lt;kfarnung@gmail.com&gt;
Reviewed-by: Rameshkumar Sundaram &lt;rameshkumar.sundaram@oss.qualcomm.com&gt;
Reviewed-by: Baochen Qiang &lt;baochen.qiang@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260513-kfarnung-ath11k-srng-clear-pointer-state-v1-1-bc700dd8b333@gmail.com
Signed-off-by: Jeff Johnson &lt;jeff.johnson@oss.qualcomm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcmfmac: Fix error pointer dereference</title>
<updated>2026-05-23T11:03:07+00:00</updated>
<author>
<name>Ethan Tidmore</name>
<email>ethantidmore06@gmail.com</email>
</author>
<published>2026-02-17T02:30:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d3f280be48f1c672cb10e8026c236d0cca60048a'/>
<id>urn:sha1:d3f280be48f1c672cb10e8026c236d0cca60048a</id>
<content type='text'>
[ Upstream commit dd8592fc6007a451c3e4b9025de365e39de8178a ]

The function brcmf_chip_add_core() can return an error pointer and is
not checked. Add checks for error pointer.

Detected by Smatch:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1010 brcmf_chip_recognition() error:
'core' dereferencing possible ERR_PTR()

drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1013 brcmf_chip_recognition() error:
'core' dereferencing possible ERR_PTR()

drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1016 brcmf_chip_recognition() error:
'core' dereferencing possible ERR_PTR()

drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1019 brcmf_chip_recognition() error:
'core' dereferencing possible ERR_PTR()

drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1022 brcmf_chip_recognition() error:
'core' dereferencing possible ERR_PTR()

Fixes: cb7cf7be9eba7 ("brcmfmac: make chip related functions host interface independent")
Signed-off-by: Ethan Tidmore &lt;ethantidmore06@gmail.com&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Link: https://patch.msgid.link/20260217023043.73631-1-ethantidmore06@gmail.com
[add missing wifi: prefix]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: rtw89: phy: fix uninitialized variable access in rtw89_phy_cfo_set_crystal_cap()</title>
<updated>2026-05-23T11:03:07+00:00</updated>
<author>
<name>Alexey Velichayshiy</name>
<email>a.velichayshiy@ispras.ru</email>
</author>
<published>2026-03-23T14:05:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ea04b9881534958687ccabba5f239577abac1277'/>
<id>urn:sha1:ea04b9881534958687ccabba5f239577abac1277</id>
<content type='text'>
[ Upstream commit 047cddf88c611e616d49a00311d4722e46286234 ]

In the rtw89_phy_cfo_set_crystal_cap() function, for chips other than
RTL8852A/RTL8851B, the values read by rtw89_mac_read_xtal_si() are
stored into the local variables sc_xi_val and sc_xo_val. If either
read fails, these variables remain uninitialized, they are later
used to update cfo-&gt;crystal_cap and in debug print statements. This
can lead to undefined behavior.

Fix the issue by initializing sc_xi_val and sc_xo_val to zero,
like is implemented in vendor driver.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: 8379fa611536 ("rtw89: 8852c: add write/read crystal function in CFO tracking")
Signed-off-by: Alexey Velichayshiy &lt;a.velichayshiy@ispras.ru&gt;
Acked-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Signed-off-by: Ping-Ke Shih &lt;pkshih@realtek.com&gt;
Link: https://patch.msgid.link/20260323140613.1615574-1-a.velichayshiy@ispras.ru
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: mt76: mt7915: fix use-after-free bugs in mt7915_mac_dump_work()</title>
<updated>2026-05-23T11:03:07+00:00</updated>
<author>
<name>Duoming Zhou</name>
<email>duoming@zju.edu.cn</email>
</author>
<published>2026-01-30T14:57:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6d5202409467d621b6d1dfd7fc7dadb997fe66d2'/>
<id>urn:sha1:6d5202409467d621b6d1dfd7fc7dadb997fe66d2</id>
<content type='text'>
[ Upstream commit 1146d0946b5358fad24812bd39d68f31cd40cc34 ]

When the mt7915 pci chip is detaching, the mt7915_crash_data is
released in mt7915_coredump_unregister(). However, the work item
dump_work may still be running or pending, leading to UAF bugs
when the already freed crash_data is dereferenced again in
mt7915_mac_dump_work().

The race condition can occur as follows:

CPU 0 (removal path)               | CPU 1 (workqueue)
mt7915_pci_remove()                | mt7915_sys_recovery_set()
 mt7915_unregister_device()        |  mt7915_reset()
  mt7915_coredump_unregister()     |   queue_work()
   vfree(dev-&gt;coredump.crash_data) | mt7915_mac_dump_work()
                                   |  crash_data-&gt; // UAF

Fix this by ensuring dump_work is properly canceled before
the crash_data is deallocated. Add cancel_work_sync() in
mt7915_unregister_device() to synchronize with any pending
or executing dump work.

Fixes: 4dbcb9125cc3 ("wifi: mt76: mt7915: enable coredump support")
Signed-off-by: Duoming Zhou &lt;duoming@zju.edu.cn&gt;
Link: https://patch.msgid.link/20260130145759.84272-1-duoming@zju.edu.cn
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: mt76: mt7996: fix struct mt7996_mcu_uni_event</title>
<updated>2026-05-23T11:03:07+00:00</updated>
<author>
<name>StanleyYP Wang</name>
<email>StanleyYP.Wang@mediatek.com</email>
</author>
<published>2026-02-03T15:55:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=66f2a0becd35a2deac46af79933ef87288c905c6'/>
<id>urn:sha1:66f2a0becd35a2deac46af79933ef87288c905c6</id>
<content type='text'>
[ Upstream commit efbd5bf395f4e6b45a87f3835d4c2e28170c77c5 ]

The cid field is defined as a two-byte value in the firmware.

Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
Signed-off-by: StanleyYP Wang &lt;StanleyYP.Wang@mediatek.com&gt;
Signed-off-by: Shayne Chen &lt;shayne.chen@mediatek.com&gt;
Link: https://patch.msgid.link/20260203155532.1098290-2-shayne.chen@mediatek.com
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: mt76: mt7996: fix FCS error flag check in RX descriptor</title>
<updated>2026-05-23T11:03:06+00:00</updated>
<author>
<name>Alok Tiwari</name>
<email>alok.a.tiwari@oracle.com</email>
</author>
<published>2025-10-13T09:08:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=63fe66f10283745c9b78fbadb4de407ed2ad04a2'/>
<id>urn:sha1:63fe66f10283745c9b78fbadb4de407ed2ad04a2</id>
<content type='text'>
[ Upstream commit d8db56142e531f060c938fa0b5175ed6c8cabb11 ]

The mt7996 driver currently checks the MT_RXD3_NORMAL_FCS_ERR bit in
rxd1 whereas other Connac3-based drivers(mt7925) correctly check this
bit in rxd3.

Since the MT_RXD3_NORMAL_FCS_ERR bit is defined in the fourth RX
descriptor word (rxd3), update mt7996 to use the proper descriptor
field. This change aligns mt7996 with mt7925 and the rest of the
Connac3 family.

Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
Signed-off-by: Alok Tiwari &lt;alok.a.tiwari@oracle.com&gt;
Reviewed-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.com&gt;
Link: https://patch.msgid.link/20251013090826.753992-1-alok.a.tiwari@oracle.com
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: mt76: mt7915: fix use_cts_prot support</title>
<updated>2026-05-23T11:03:06+00:00</updated>
<author>
<name>Ryder Lee</name>
<email>ryder.lee@mediatek.com</email>
</author>
<published>2026-01-21T17:41:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4dd75a78cdfbdcc97d59bab3a4170f9cc76507d4'/>
<id>urn:sha1:4dd75a78cdfbdcc97d59bab3a4170f9cc76507d4</id>
<content type='text'>
[ Upstream commit 8b2c26562b95c6397e132d21f2bd3d73aaee0c0a ]

With this fix, when driver needs to adjust its behavior for compatibility,
especially concerning older 11g/n devices, by enabling or disabling CTS
protection frames, often for hidden SSIDs or to manage legacy clients.

Fixes: 150b91419d3d ("wifi: mt76: mt7915: enable use_cts_prot support")
Signed-off-by: Ryder Lee &lt;ryder.lee@mediatek.com&gt;
Link: https://patch.msgid.link/eb8db4d0bf1c89b7486e89facb788ae3e510dd8b.1768879119.git.ryder.lee@mediatek.com
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
