<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/net/wireless, branch v7.1-rc7</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>wifi: iwlwifi: pcie: simplify the resume flow if fast resume is not used</title>
<updated>2026-05-31T14:07:11+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2026-05-31T10:30:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=093305d801fae6ff9b8bb531fd78b579794c4f80'/>
<id>093305d801fae6ff9b8bb531fd78b579794c4f80</id>
<content type='text'>
In most distributions, NetworkManager shuts the device down before
entering system suspend, so fast suspend is typically not used.

On older devices, resume currently tries to grab NIC access to infer
whether the device was powered off while suspended. That probe is only
meaningful for the fast-suspend path where the device is expected to
remain alive.

Unfortunately, for unclear reasons, grabbing NIC access was harmful as
reported in the bugzilla ticket below.

Workaround this issue by simply not grabbing NIC access if fast suspend
is not used.

Cc: stable@vger.kernel.org
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221501
Assisted-by: GitHub Copilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Link: https://patch.msgid.link/20260531133005.e2ed9e0cd44f.If283625983a843933e0c01561a421daff184e9e9@changeid
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In most distributions, NetworkManager shuts the device down before
entering system suspend, so fast suspend is typically not used.

On older devices, resume currently tries to grab NIC access to infer
whether the device was powered off while suspended. That probe is only
meaningful for the fast-suspend path where the device is expected to
remain alive.

Unfortunately, for unclear reasons, grabbing NIC access was harmful as
reported in the bugzilla ticket below.

Workaround this issue by simply not grabbing NIC access if fast suspend
is not used.

Cc: stable@vger.kernel.org
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221501
Assisted-by: GitHub Copilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Link: https://patch.msgid.link/20260531133005.e2ed9e0cd44f.If283625983a843933e0c01561a421daff184e9e9@changeid
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: iwlwifi: mvm: avoid oversized UATS command copy</title>
<updated>2026-05-30T20:54:42+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2026-05-29T05:57:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e0c121d545134af886b28c4c26d91abf5dd39c17'/>
<id>e0c121d545134af886b28c4c26d91abf5dd39c17</id>
<content type='text'>
MCC_ALLOWED_AP_TYPE_CMD exceeds the fixed copied host-command buffer
and triggers warnings in the gen2 enqueue path when command
0xc05 is sent.

Use IWL_HCMD_DFL_NOCOPY as it was done before the offending commit.

Fixes: 078df640ef05 ("wifi: iwlwifi: mld: add support for iwl_mcc_allowed_ap_type_cmd v2")
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20260529085453.9af349ab459b.I348df3980764c15efce0099a35fe8a88fb2a6ee2@changeid
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
MCC_ALLOWED_AP_TYPE_CMD exceeds the fixed copied host-command buffer
and triggers warnings in the gen2 enqueue path when command
0xc05 is sent.

Use IWL_HCMD_DFL_NOCOPY as it was done before the offending commit.

Fixes: 078df640ef05 ("wifi: iwlwifi: mld: add support for iwl_mcc_allowed_ap_type_cmd v2")
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20260529085453.9af349ab459b.I348df3980764c15efce0099a35fe8a88fb2a6ee2@changeid
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: iwlwifi: mld: send tx power constraints before link activation</title>
<updated>2026-05-30T20:54:42+00:00</updated>
<author>
<name>Pagadala Yesu Anjaneyulu</name>
<email>pagadala.yesu.anjaneyulu@intel.com</email>
</author>
<published>2026-05-29T05:57:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9bf1b409afc7c4a1f0340f3975846c4f3278643a'/>
<id>9bf1b409afc7c4a1f0340f3975846c4f3278643a</id>
<content type='text'>
TX power constraints must be sent to the firmware before link
activation. If not, the firmware will use default power values.

Fix this by moving the iwl_mld_send_ap_tx_power_constraint_cmd()
call from iwl_mld_start_ap_ibss() to iwl_mld_assign_vif_chanctx(),
before iwl_mld_activate_link() for AP interfaces. Also update
the guard in the function to allow it to run before link activation
for AP interfaces.

Signed-off-by: Pagadala Yesu Anjaneyulu &lt;pagadala.yesu.anjaneyulu@intel.com&gt;

Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20260529085453.06c94b01efd2.Id43bdfe5eb030061c23348779687ba71b5f58182@changeid
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
TX power constraints must be sent to the firmware before link
activation. If not, the firmware will use default power values.

Fix this by moving the iwl_mld_send_ap_tx_power_constraint_cmd()
call from iwl_mld_start_ap_ibss() to iwl_mld_assign_vif_chanctx(),
before iwl_mld_activate_link() for AP interfaces. Also update
the guard in the function to allow it to run before link activation
for AP interfaces.

Signed-off-by: Pagadala Yesu Anjaneyulu &lt;pagadala.yesu.anjaneyulu@intel.com&gt;

Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20260529085453.06c94b01efd2.Id43bdfe5eb030061c23348779687ba71b5f58182@changeid
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: iwlwifi: mvm: don't support the reset handshake for old firmwares</title>
<updated>2026-05-30T20:54:42+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2026-05-29T05:57:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0eaa1f245ac03ed0c6394159360532726f666811'/>
<id>0eaa1f245ac03ed0c6394159360532726f666811</id>
<content type='text'>
-77.ucode doesn't contain the fixes for this flow it seems.
Don't use the firmware reset handshake even if the firmware claims
support for it.

Fixes: 906d4eb84408 ("iwlwifi: support firmware reset handshake")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220600
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Reviewed-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20260529085453.9307b81d9b02.I21bba9e649f4cd0e35d3ea6cd97a03258be5832f@changeid
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
-77.ucode doesn't contain the fixes for this flow it seems.
Don't use the firmware reset handshake even if the firmware claims
support for it.

Fixes: 906d4eb84408 ("iwlwifi: support firmware reset handshake")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220600
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Reviewed-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20260529085453.9307b81d9b02.I21bba9e649f4cd0e35d3ea6cd97a03258be5832f@changeid
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'ath-current-20260519' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath</title>
<updated>2026-05-20T09:27:00+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2026-05-20T09:26:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8499d0949d6a624b830d66d480f98badbf24dc26'/>
<id>8499d0949d6a624b830d66d480f98badbf24dc26</id>
<content type='text'>
Jeff Johnson says:
==================
ath.git update for v7.1-rc5

ath10k:
- avoid sending any commands to firmware when it is wedged

ath11k:
- fix WMI buffer leaks on error conditions
- fix UAF in RX MSDU coalesce path
- allow peer ID 0 on RX path (legal for mobile devices)
- reinitialize shared SRNG pointers on restart

ath12k:
- fix 20 MHz-only parsing of EHT-MCS map
==================

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Jeff Johnson says:
==================
ath.git update for v7.1-rc5

ath10k:
- avoid sending any commands to firmware when it is wedged

ath11k:
- fix WMI buffer leaks on error conditions
- fix UAF in RX MSDU coalesce path
- allow peer ID 0 on RX path (legal for mobile devices)
- reinitialize shared SRNG pointers on restart

ath12k:
- fix 20 MHz-only parsing of EHT-MCS map
==================

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'iwlwifi-fixes-2026-05-16' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next</title>
<updated>2026-05-20T09:25:55+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2026-05-20T09:25:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2248db6dc60108963b77c33e8b3d5cf19b0ed2e5'/>
<id>2248db6dc60108963b77c33e8b3d5cf19b0ed2e5</id>
<content type='text'>
Miri Korenblit says:
====================
wifi: iwlwifi: fixes - 2026-05-16

Contains:
wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is disabled
wifi: iwlwifi: mld: stop TX during firmware restart
wifi: iwlwifi: mld: don't WARN on WoWLAN suspend w/o BSS vif
wifi: iwlwifi: mvm: fix driver-set TX rates on old devices
wifi: iwlwifi: mld: disconnect only after 6 beacons without Rx
wifi: iwlwifi: mld: don't dereference a pointer before NULL checking it
wifi: iwlwifi: use correct function to read STEP_URM register
====================

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Miri Korenblit says:
====================
wifi: iwlwifi: fixes - 2026-05-16

Contains:
wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is disabled
wifi: iwlwifi: mld: stop TX during firmware restart
wifi: iwlwifi: mld: don't WARN on WoWLAN suspend w/o BSS vif
wifi: iwlwifi: mvm: fix driver-set TX rates on old devices
wifi: iwlwifi: mld: disconnect only after 6 beacons without Rx
wifi: iwlwifi: mld: don't dereference a pointer before NULL checking it
wifi: iwlwifi: use correct function to read STEP_URM register
====================

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: wilc1000: fix dma_buffer leak on bus acquire failure</title>
<updated>2026-05-20T09:19:55+00:00</updated>
<author>
<name>Shitalkumar Gandhi</name>
<email>shital.gandhi45@gmail.com</email>
</author>
<published>2026-05-11T04:27:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=dd7b6a8671939708cc4b7a46786d8c11297e8f69'/>
<id>dd7b6a8671939708cc4b7a46786d8c11297e8f69</id>
<content type='text'>
wilc_wlan_firmware_download() allocates dma_buffer with kmalloc() at
the top of the function and uses a 'fail:' label to free it via
kfree(dma_buffer) on error.

All later error paths correctly use 'goto fail' to route through this
cleanup. However, the early failure path after the first acquire_bus()
call uses a bare 'return ret;', which leaks dma_buffer whenever the bus
acquire fails.

Replace the early return with goto fail so the existing cleanup path
runs.

Found via a custom Coccinelle semantic patch hunting for kmalloc'd
locals leaked on early-return error paths in driver firmware-download
code.

Fixes: 1241c5650ff7 ("wifi: wilc1000: Fill in missing error handling")
Signed-off-by: Shitalkumar Gandhi &lt;shitalkumar.gandhi@cambiumnetworks.com&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://patch.msgid.link/20260511042732.998311-1-shitalkumar.gandhi@cambiumnetworks.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
wilc_wlan_firmware_download() allocates dma_buffer with kmalloc() at
the top of the function and uses a 'fail:' label to free it via
kfree(dma_buffer) on error.

All later error paths correctly use 'goto fail' to route through this
cleanup. However, the early failure path after the first acquire_bus()
call uses a bare 'return ret;', which leaks dma_buffer whenever the bus
acquire fails.

Replace the early return with goto fail so the existing cleanup path
runs.

Found via a custom Coccinelle semantic patch hunting for kmalloc'd
locals leaked on early-return error paths in driver firmware-download
code.

Fixes: 1241c5650ff7 ("wifi: wilc1000: Fill in missing error handling")
Signed-off-by: Shitalkumar Gandhi &lt;shitalkumar.gandhi@cambiumnetworks.com&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://patch.msgid.link/20260511042732.998311-1-shitalkumar.gandhi@cambiumnetworks.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: ath12k: fix EHT TX MCS limitation due to wrong 20 MHz-only parsing</title>
<updated>2026-05-18T13:47:03+00:00</updated>
<author>
<name>Baochen Qiang</name>
<email>baochen.qiang@oss.qualcomm.com</email>
</author>
<published>2026-05-14T03:32:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=60fb2cf51e77bb1c0261160b4be44209d68956b1'/>
<id>60fb2cf51e77bb1c0261160b4be44209d68956b1</id>
<content type='text'>
When connecting to an AP configured for EHT 20 MHz with a full EHT
MCS/NSS map (supporting MCS 0-13)

Supported EHT-MCS and NSS Set
    EHT-MCS Map (BW &lt;= 80MHz): 0x444444
        .... .... .... .... .... 0100 = Rx Max Nss That Supports EHT-MCS 0-9: 4
        .... .... .... .... 0100 .... = Tx Max Nss That Supports EHT-MCS 0-9: 4
        .... .... .... 0100 .... .... = Rx Max Nss That Supports EHT-MCS 10-11: 4
        .... .... 0100 .... .... .... = Tx Max Nss That Supports EHT-MCS 10-11: 4
        .... 0100 .... .... .... .... = Rx Max Nss That Supports EHT-MCS 12-13: 4
        0100 .... .... .... .... .... = Tx Max Nss That Supports EHT-MCS 12-13: 4

TX throughput is observed to be significantly lower than expected.
Investigation shows that TX rates are limited to EHT MCS 11, even though
the AP advertises support for EHT MCS 12/13.

The root cause is an incorrect parsing of the Supported EHT-MCS and NSS
Set element in ath12k_peer_assoc_h_eht().

IEEE Std 802.11be-2024 Figure 9-1074as describes the format for 20
MHz-Only Non-AP STAs.

IEEE Std 802.11be-2024 Figure 9-1074at describes the format for all
other AP and non-AP STAs.

Currently the first format is parsed when the peer advertises no wider
HE channel width support, without considering whether it is an AP or a
non-AP STA. This is incorrect: the peer AP's capabilities must be parsed
using Figure 9-1074at even when it operates on 20 MHz only. Parsing it
as Figure 9-1074as causes rx_tx_mcs13_max_nss to be interpreted as zero,
which is then passed to firmware, leading firmware to assume the peer
does not support MCS 13 and to limit TX rates at MCS 11.

Fix this by parsing the Figure 9-1074as format only when the peer is a
20 MHz-Only non-AP STA, i.e. when the local interface operates as AP or
mesh point.

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

Fixes: 6c95151e2e77 ("wifi: ath12k: Add EHT MCS/NSS rates to Peer Assoc")
Signed-off-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/20260514-ath12k-fix-20mhz-only-mcs-map-v1-1-a38d4a9b21a2@oss.qualcomm.com
Signed-off-by: Jeff Johnson &lt;jeff.johnson@oss.qualcomm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When connecting to an AP configured for EHT 20 MHz with a full EHT
MCS/NSS map (supporting MCS 0-13)

Supported EHT-MCS and NSS Set
    EHT-MCS Map (BW &lt;= 80MHz): 0x444444
        .... .... .... .... .... 0100 = Rx Max Nss That Supports EHT-MCS 0-9: 4
        .... .... .... .... 0100 .... = Tx Max Nss That Supports EHT-MCS 0-9: 4
        .... .... .... 0100 .... .... = Rx Max Nss That Supports EHT-MCS 10-11: 4
        .... .... 0100 .... .... .... = Tx Max Nss That Supports EHT-MCS 10-11: 4
        .... 0100 .... .... .... .... = Rx Max Nss That Supports EHT-MCS 12-13: 4
        0100 .... .... .... .... .... = Tx Max Nss That Supports EHT-MCS 12-13: 4

TX throughput is observed to be significantly lower than expected.
Investigation shows that TX rates are limited to EHT MCS 11, even though
the AP advertises support for EHT MCS 12/13.

The root cause is an incorrect parsing of the Supported EHT-MCS and NSS
Set element in ath12k_peer_assoc_h_eht().

IEEE Std 802.11be-2024 Figure 9-1074as describes the format for 20
MHz-Only Non-AP STAs.

IEEE Std 802.11be-2024 Figure 9-1074at describes the format for all
other AP and non-AP STAs.

Currently the first format is parsed when the peer advertises no wider
HE channel width support, without considering whether it is an AP or a
non-AP STA. This is incorrect: the peer AP's capabilities must be parsed
using Figure 9-1074at even when it operates on 20 MHz only. Parsing it
as Figure 9-1074as causes rx_tx_mcs13_max_nss to be interpreted as zero,
which is then passed to firmware, leading firmware to assume the peer
does not support MCS 13 and to limit TX rates at MCS 11.

Fix this by parsing the Figure 9-1074as format only when the peer is a
20 MHz-Only non-AP STA, i.e. when the local interface operates as AP or
mesh point.

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

Fixes: 6c95151e2e77 ("wifi: ath12k: Add EHT MCS/NSS rates to Peer Assoc")
Signed-off-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/20260514-ath12k-fix-20mhz-only-mcs-map-v1-1-a38d4a9b21a2@oss.qualcomm.com
Signed-off-by: Jeff Johnson &lt;jeff.johnson@oss.qualcomm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: ath11k: clear shared SRNG pointer state on restart</title>
<updated>2026-05-18T13:47:03+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.tavy.me/linux.git/commit/?id=f51e4b3b5574ad8cb5b16b11f8a1452147ece87a'/>
<id>f51e4b3b5574ad8cb5b16b11f8a1452147ece87a</id>
<content type='text'>
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;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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;
</pre>
</div>
</content>
</entry>
<entry>
<title>wifi: ath11k: fix use after free in ath11k_dp_rx_msdu_coalesce()</title>
<updated>2026-05-18T13:47:02+00:00</updated>
<author>
<name>Willmar Knikker</name>
<email>willmar@met-dubbel-l.nl</email>
</author>
<published>2026-05-05T17:17:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=72b8654e3b83548f64524add2e9145e9b6c8a852'/>
<id>72b8654e3b83548f64524add2e9145e9b6c8a852</id>
<content type='text'>
In ath11k_dp_rx_msdu_coalesce() the loop uses -&gt;is_continuation after
the dev_kfree_skb_any(). This can cause a use after free kfence.

Use flag for caching is_continuation for use after the
dev_kfree_skb_any().

Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Willmar Knikker &lt;willmar@met-dubbel-l.nl&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/20260505171709.547274-1-willmar@met-dubbel-l.nl
Signed-off-by: Jeff Johnson &lt;jeff.johnson@oss.qualcomm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In ath11k_dp_rx_msdu_coalesce() the loop uses -&gt;is_continuation after
the dev_kfree_skb_any(). This can cause a use after free kfence.

Use flag for caching is_continuation for use after the
dev_kfree_skb_any().

Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Willmar Knikker &lt;willmar@met-dubbel-l.nl&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/20260505171709.547274-1-willmar@met-dubbel-l.nl
Signed-off-by: Jeff Johnson &lt;jeff.johnson@oss.qualcomm.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
