* [PATCH net-next v2 1/3] net: prestera: ignore duplicate RIF destruction events
From: Yuyang Huang @ 2026-07-11 0:54 UTC (permalink / raw)
To: Yuyang Huang
Cc: David S. Miller, Andrew Lunn, David Ahern, Elad Nachman,
Eric Dumazet, Ido Schimmel, Jakub Kicinski, Johannes Berg,
Paolo Abeni, Simon Horman, linux-kernel, linux-wireless, netdev,
Kuniyuki Iwashima
In-Reply-To: <20260711005405.2861680-1-yuyanghuang@google.com>
During address teardown, the inetaddr notifier may be called multiple
times for the same interface. Ignore NETDEV_DOWN events if the RIF has
already been destroyed, rather than returning -EEXIST, which aborts the
notifier chain.
Cc: Ido Schimmel <idosch@nvidia.com>
Cc: Kuniyuki Iwashima <kuniyu@google.com>
Signed-off-by: Yuyang Huang <yuyanghuang@google.com>
---
drivers/net/ethernet/marvell/prestera/prestera_router.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/prestera/prestera_router.c b/drivers/net/ethernet/marvell/prestera/prestera_router.c
index b036b173a308..0c4f462baa6e 100644
--- a/drivers/net/ethernet/marvell/prestera/prestera_router.c
+++ b/drivers/net/ethernet/marvell/prestera/prestera_router.c
@@ -1302,10 +1302,8 @@ static int __prestera_inetaddr_port_event(struct net_device *port_dev,
dev_hold(port_dev);
break;
case NETDEV_DOWN:
- if (!re) {
- NL_SET_ERR_MSG_MOD(extack, "Can't find RIF");
- return -EEXIST;
- }
+ if (!re)
+ return 0;
prestera_rif_entry_destroy(port->sw, re);
dev_put(port_dev);
break;
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply related
* [PATCH net-next v2 0/3] align IPv4 teardown with IPv6 and fix driver regressions
From: Yuyang Huang @ 2026-07-11 0:54 UTC (permalink / raw)
To: Yuyang Huang
Cc: David S. Miller, Andrew Lunn, David Ahern, Elad Nachman,
Eric Dumazet, Ido Schimmel, Jakub Kicinski, Johannes Berg,
Paolo Abeni, Simon Horman, linux-kernel, linux-wireless, netdev
This series aligns the IPv4 address teardown sequence with IPv6 by clearing
dev->ip_ptr early in inetdev_destroy() before freeing the multicast list and
individual IP addresses. This prevents RCU readers from accessing a partially
destroyed in_device structure.
However, clearing dev->ip_ptr early causes __in_dev_get_rtnl() to return NULL
during the notifier loop in inetdev_destroy(). This causes regressions in
some drivers (prestera and mac80211) that use this lookup helper in their
inetaddr notifier callbacks.
To prevent regressions and maintain bisectability, this series first fixes the
affected drivers (Patch 1 and 2) before applying the core IPv4 change (Patch 3).
An audit was performed on all other registered inetaddr and inet6addr notifier
listeners, and no other drivers were found to be affected.
Change in v2:
- Split the original single patch into a 3-patch series.
- Patch 1: Teach prestera to ignore duplicate RIF destruction events when the
RIF is already gone, rather than returning -EEXIST and aborting the chain.
- Patch 2: Fix mac80211 to use the valid ifa->ifa_dev from the event argument
instead of looking it up via the netdevice.
- Patch 3: The original change to clear dev->ip_ptr early.
Yuyang Huang (3):
net: prestera: ignore duplicate RIF destruction events
wifi: mac80211: use ifa_dev from event argument
net: ipv4: clear dev->ip_ptr before destroying inetdev
drivers/net/ethernet/marvell/prestera/prestera_router.c | 6 ++----
net/ipv4/devinet.c | 4 ++--
net/mac80211/main.c | 4 +---
3 files changed, 5 insertions(+), 9 deletions(-)
--
2.55.0.795.g602f6c329a-goog
^ permalink raw reply
* Re: [PATCH v3 6/8] wifi: ath12k: Use pci_{enable/disable}_link_state() APIs to enable/disable ASPM states
From: Bjorn Helgaas @ 2026-07-10 20:25 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Nirmal Patel, Jonathan Derrick, Jeff Johnson,
linux-pci, linux-kernel, linux-arm-msm, linux-wireless, ath12k,
ath11k, ath10k, Krishna Chaitanya Chundru, Qiang Yu,
Ilpo Järvinen, Manivannan Sadhasivam
In-Reply-To: <20260708-pci-aspm-fix-v3-6-6bd72451746e@kernel.org>
On Wed, Jul 08, 2026 at 04:30:20PM +0200, Manivannan Sadhasivam wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> It is not recommended to enable/disable the ASPM states on the back of the
> PCI core directly using the LNKCTL register. It will break the PCI core's
> knowledge about the device ASPM states. So use the APIs exposed by the PCI
> core to enable/disable ASPM states.
>
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
>
> Reported-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/Kconfig | 2 +-
> drivers/net/wireless/ath/ath12k/pci.c | 19 +++----------------
> drivers/net/wireless/ath/ath12k/pci.h | 4 +++-
> 3 files changed, 7 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/Kconfig b/drivers/net/wireless/ath/ath12k/Kconfig
> index 4a2b240f967a..7852ede3eaea 100644
> --- a/drivers/net/wireless/ath/ath12k/Kconfig
> +++ b/drivers/net/wireless/ath/ath12k/Kconfig
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: BSD-3-Clause-Clear
> config ATH12K
> tristate "Qualcomm Wi-Fi 7 support (ath12k)"
> - depends on MAC80211 && HAS_DMA && PCI
> + depends on MAC80211 && HAS_DMA && PCI && PCIEASPM
As Sashiko pointed out [1], I think adding the PCIEASPM dependency is
an issue. The PCI core should provide stubs or whatever is necessary
to make ath12k work even if PCIEASPM isn't selected.
I'm guessing this hardware depends on the ability to disable ASPM even
without PCIEASPM so we probably would need more than just empty stubs.
We do build aspm.c unconditionally now and we provide LTR and L1SS
save/restore regardless of PCIEASPM. Maybe we need something similar
here.
[1] https://lore.kernel.org/all/20260708144904.0CC4F1F000E9@smtp.kernel.org
> select QCOM_QMI_HELPERS
> select MHI_BUS
> select QRTR
> diff --git a/drivers/net/wireless/ath/ath12k/pci.c b/drivers/net/wireless/ath/ath12k/pci.c
> index d9a22d6afbb0..6d48fb25690d 100644
> --- a/drivers/net/wireless/ath/ath12k/pci.c
> +++ b/drivers/net/wireless/ath/ath12k/pci.c
> @@ -884,19 +884,9 @@ static void ath12k_pci_free_region(struct ath12k_pci *ab_pci)
>
> static void ath12k_pci_aspm_disable(struct ath12k_pci *ab_pci)
> {
> - struct ath12k_base *ab = ab_pci->ab;
> -
> - pcie_capability_read_word(ab_pci->pdev, PCI_EXP_LNKCTL,
> - &ab_pci->link_ctl);
> -
> - ath12k_dbg(ab, ATH12K_DBG_PCI, "pci link_ctl 0x%04x L0s %d L1 %d\n",
> - ab_pci->link_ctl,
> - u16_get_bits(ab_pci->link_ctl, PCI_EXP_LNKCTL_ASPM_L0S),
> - u16_get_bits(ab_pci->link_ctl, PCI_EXP_LNKCTL_ASPM_L1));
> + ab_pci->aspm_states = pcie_aspm_enabled(ab_pci->pdev);
>
> - /* disable L0s and L1 */
> - pcie_capability_clear_word(ab_pci->pdev, PCI_EXP_LNKCTL,
> - PCI_EXP_LNKCTL_ASPMC);
> + pci_disable_link_state(ab_pci->pdev, PCIE_LINK_STATE_ASPM_ALL);
>
> set_bit(ATH12K_PCI_ASPM_RESTORE, &ab_pci->flags);
> }
> @@ -925,10 +915,7 @@ static void ath12k_pci_aspm_restore(struct ath12k_pci *ab_pci)
> {
> if (ab_pci->ab->hw_params->supports_aspm &&
> test_and_clear_bit(ATH12K_PCI_ASPM_RESTORE, &ab_pci->flags))
> - pcie_capability_clear_and_set_word(ab_pci->pdev, PCI_EXP_LNKCTL,
> - PCI_EXP_LNKCTL_ASPMC,
> - ab_pci->link_ctl &
> - PCI_EXP_LNKCTL_ASPMC);
> + pci_force_enable_link_state(ab_pci->pdev, ab_pci->aspm_states);
> }
>
> static void ath12k_pci_cancel_workqueue(struct ath12k_base *ab)
> diff --git a/drivers/net/wireless/ath/ath12k/pci.h b/drivers/net/wireless/ath/ath12k/pci.h
> index 0e0e2020c6ae..409ef063cd69 100644
> --- a/drivers/net/wireless/ath/ath12k/pci.h
> +++ b/drivers/net/wireless/ath/ath12k/pci.h
> @@ -128,7 +128,9 @@ struct ath12k_pci {
>
> /* enum ath12k_pci_flags */
> unsigned long flags;
> - u16 link_ctl;
> +
> + /* Cached PCIe ASPM states */
> + u32 aspm_states;
> unsigned long irq_flags;
> const struct ath12k_pci_ops *pci_ops;
> u32 qmi_instance;
>
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: (subset) [PATCH v9 00/14] firmware: qcom: Add OP-TEE PAS service support
From: Jeff Johnson @ 2026-07-10 20:01 UTC (permalink / raw)
To: Bjorn Andersson, konradybcio, Sumit Garg
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, robh, krzk+dt,
conor+dt, robin.clark, sean, akhilpo, lumag, abhinav.kumar,
jesszhan0024, marijn.suijten, airlied, simona, vikash.garodia,
bod, mchehab, elder, andrew+netdev, davem, edumazet, kuba, pabeni,
jjohnson, mathieu.poirier, trilokkumar.soni, mukesh.ojha,
pavan.kondeti, jorge.ramirez, tonyh, vignesh.viswanathan,
srinivas.kandagatla, amirreza.zarrabi, jenswi, op-tee, apurupa,
skare, linux-kernel, Sumit Garg
In-Reply-To: <178362521364.2422497.1305957434056184382.b4-ty@kernel.org>
On 7/9/2026 12:32 PM, Bjorn Andersson wrote:
>
> On Thu, 02 Jul 2026 17:28:16 +0530, Sumit Garg wrote:
>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>
>> Qcom platforms has the legacy of using non-standard SCM calls
>> splintered over the various kernel drivers. These SCM calls aren't
>> compliant with the standard SMC calling conventions which is a
>> prerequisite to enable migration to the FF-A specifications from Arm.
>>
>> [...]
>
> Applied, thanks!
>
> [01/14] firmware: qcom: Add a generic PAS service
> commit: 08314e7c2c38b9ae6a5e01c58ed10a950859404d
> [02/14] firmware: qcom_scm: Migrate to generic PAS service
> commit: 5c1a2975d23c51c01aca51945d0f10a4ee4c9020
> [03/14] firmware: qcom: Add a PAS TEE service
> commit: b6f7978da0c4d26fe465aa6634f5a0b48f900de0
> [14/14] MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service
> commit: 6701259025d49139131a0eb2257659a066dcca22
>
> This is available as an immutable branch, for other subsystems to pull at:
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git 20260702115835.167602-2-sumit.garg@kernel.org
I've merged this branch into ath/ath-next so it is available for ongoing
ath12k support.
/jeff
^ permalink raw reply
* Re: [PATCH] wifi: brcmfmac: drain bus_reset work on device removal
From: Arend van Spriel @ 2026-07-10 19:18 UTC (permalink / raw)
To: Eddie Phillips, Fan Wu
Cc: Arend van Spriel, Kalle Valo, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Chung-Hsien Hsu, David S . Miller,
Jakub Kicinski, linux-wireless, brcm80211-dev-list.pdl,
SHA-cyfmac-dev-list, netdev, linux-kernel, stable
In-Reply-To: <20260710002451.500112-1-eddiephillips@google.com>
On 10/07/2026 02:23, Eddie Phillips wrote:
> On Thu, 9 Jul 2026 10:16:35 +0000 Fan Wu <fanwu01@zju.edu.cn> wrote:
>
>> brcmf_fw_crashed() and the debugfs "reset" entry both schedule
>> drvr->bus_reset, whose callback recovers drvr through container_of()
>> and dereferences it. The teardown paths free drvr (brcmf_free ->
>> wiphy_free) without draining the work, so a bus_reset callback pending
>> or running during removal can outlive drvr.
>>
[...]
>>
>> This issue was found by an in-house static analysis tool.
>>
>> Fixes: 4684997d9eea ("brcmfmac: reset PCIe bus on a firmware crash")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
>> Assisted-by: Codex:gpt-5.5
>> ---
>> .../broadcom/brcm80211/brcmfmac/bcmsdh.c | 13 ++++++++
>> .../broadcom/brcm80211/brcmfmac/bus.h | 6 ++++
>> .../broadcom/brcm80211/brcmfmac/core.c | 33 +++++++++++++++++--
>> .../broadcom/brcm80211/brcmfmac/pcie.c | 6 ++++
>> .../broadcom/brcm80211/brcmfmac/sdio.c | 6 ++++
>> .../broadcom/brcm80211/brcmfmac/sdio.h | 1 +
>> .../broadcom/brcm80211/brcmfmac/usb.c | 3 ++
>> 7 files changed, 66 insertions(+), 2 deletions(-)
[...]
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>> index fed9cd5f2..b934feb9b 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
>> @@ -1164,6 +1164,35 @@ static int brcmf_revinfo_read(struct seq_file *s, void *data)
>> return 0;
>> }
>>
>> +/* Serialize bus_reset arming (debugfs reset write, brcmf_fw_crashed) against the
>> + * teardown drain: the remove path takes bus_reset_lock, sets ->removing and cancels
>> + * the work under it, so a racing armer either schedules before the cancel (and is
>> + * drained) or observes ->removing and desists.
>> + */
>> +static void brcmf_bus_schedule_reset(struct brcmf_bus *bus_if)
>> +{
>> + mutex_lock(&bus_if->bus_reset_lock);
>> + if (bus_if->drvr && bus_if->drvr->bus_reset.func && !bus_if->removing)
>> + schedule_work(&bus_if->drvr->bus_reset);
>> + mutex_unlock(&bus_if->bus_reset_lock);
>> +}
>
> Is this safe in a softIRQ context?
> mutex_lock() sleeps until it can get the lock.
What softIRQ context? brcmf_fw_crashed() is called by PCIe (thread) and
SDIO (worker).
>> +
>> +void brcmf_bus_cancel_reset_work(struct brcmf_bus *bus_if)
>> +{
>> + mutex_lock(&bus_if->bus_reset_lock);
>> + bus_if->removing = true;
>> + if (bus_if->drvr)
>> + cancel_work_sync(&bus_if->drvr->bus_reset);
>> + mutex_unlock(&bus_if->bus_reset_lock);
>> +}
>
> How about if brcmf_pcie_remove() calls brcmf_bus_cancel_reset_work(),
> takes the lock and calls cancel_work_sync(), sleeps. If debugfs
> path is already running, it can invoke the worker thread. Is there
> potential that both try to reset?
What is "both" here?
Regards,
Arend
^ permalink raw reply
* [PATCH] wifi: mt76: mt7921: validate CLC firmware records
From: Laxman Acharya Padhya @ 2026-07-10 18:54 UTC (permalink / raw)
To: Felix Fietkau
Cc: Lorenzo Bianconi, Ryder Lee, Shayne Chen, Sean Wang,
linux-wireless, linux-mediatek, linux-kernel
The CLC region is supplied by firmware, but the loader trusts the
region count and each record length. A malformed image can make the
region table pointer precede the firmware buffer, make the record loop
fail to advance, or index phy->clc past its end. Validate the table and
record bounds before dereferencing or copying.
Fixes: 23bdc5d8cadf ("wifi: mt76: mt7921: introduce Country Location
Control support")
Signed-off-by: Laxman Acharya Padhya <acharyalaxman8848@gmail.com>
---
drivers/net/wireless/mediatek/mt76/mt7921/mcu.c | 28 +++++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c
b/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c
index 25b9437250f7..564dd836e0b3 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c
@@ -415,7 +415,8 @@ static int mt7921_load_clc(struct mt792x_dev *dev,
const char *fw_name)
struct mt76_dev *mdev = &dev->mt76;
struct mt792x_phy *phy = &dev->phy;
const struct firmware *fw;
- int ret, i, len, offset = 0;
+ size_t clc_len, fw_data_len, len, offset = 0;
+ int ret, i;
u8 *clc_base = NULL, hw_encap = 0;
dev->phy.clc_chan_conf = 0xff;
@@ -441,13 +442,21 @@ static int mt7921_load_clc(struct mt792x_dev
*dev, const char *fw_name)
}
hdr = (const void *)(fw->data + fw->size - sizeof(*hdr));
+ if (hdr->n_region > (fw->size - sizeof(*hdr)) / sizeof(*region)) {
+ dev_err(mdev->dev, "Invalid firmware region table\n");
+ ret = -EINVAL;
+ goto out;
+ }
+ fw_data_len = fw->size - sizeof(*hdr) -
+ hdr->n_region * sizeof(*region);
+
for (i = 0; i < hdr->n_region; i++) {
region = (const void *)((const u8 *)hdr -
(hdr->n_region - i) * sizeof(*region));
len = le32_to_cpu(region->len);
/* check if we have valid buffer size */
- if (offset + len > fw->size) {
+ if (len > fw_data_len - offset) {
dev_err(mdev->dev, "Invalid firmware region\n");
ret = -EINVAL;
goto out;
@@ -464,8 +473,19 @@ static int mt7921_load_clc(struct mt792x_dev
*dev, const char *fw_name)
if (!clc_base)
goto out;
- for (offset = 0; offset < len; offset += le32_to_cpu(clc->len)) {
+ for (offset = 0; offset < len; offset += clc_len) {
+ if (len - offset < sizeof(*clc)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
clc = (const struct mt7921_clc *)(clc_base + offset);
+ clc_len = le32_to_cpu(clc->len);
+ if (clc_len < sizeof(*clc) || clc_len > len - offset ||
+ clc->idx >= ARRAY_SIZE(phy->clc)) {
+ ret = -EINVAL;
+ goto out;
+ }
/* do not init buf again if chip reset triggered */
if (phy->clc[clc->idx])
@@ -477,7 +497,7 @@ static int mt7921_load_clc(struct mt792x_dev *dev,
const char *fw_name)
continue;
phy->clc[clc->idx] = devm_kmemdup(mdev->dev, clc,
- le32_to_cpu(clc->len),
+ clc_len,
GFP_KERNEL);
if (!phy->clc[clc->idx]) {
^ permalink raw reply related
* [PATCH 2/2] wifi: ath12k: implement custom wake_tx_queue with flow control
From: Jose Ignacio Tornos Martinez @ 2026-07-10 15:54 UTC (permalink / raw)
To: jjohnson
Cc: ath11k, ath12k, linux-wireless, linux-kernel,
Jose Ignacio Tornos Martinez
In-Reply-To: <20260710155443.1761760-1-jtornosm@redhat.com>
Under heavy traffic, ath12k can hang and experiences -ENOMEM errors
("failed to transmit frame -12") when the hardware TCL ring fills up.
This issue is more commonly observed in VMs with PCIe passthrough but
also occurs on bare metal systems.
Implement a custom wake_tx_queue operation that:
1. Checks hardware ring space before dequeuing packets from mac80211
2. Uses per-packet locking to serialize ring access and prevent races
3. Syncs with hardware state to get accurate free slot count
4. Returns early during firmware crash in the same way as other tx paths
This approach follows the pattern used in the iwlwifi driver, adapted
for ath12k's hardware ring architecture.
This prevents hangs, eliminates -ENOMEM errors, and improves throughput
by optimizing resource usage and preventing unnecessary packet drops.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
drivers/net/wireless/ath/ath12k/dp.c | 1 +
drivers/net/wireless/ath/ath12k/dp.h | 2 +
drivers/net/wireless/ath/ath12k/hal.c | 1 +
drivers/net/wireless/ath/ath12k/wifi7/hw.c | 50 +++++++++++++++++++++-
4 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath12k/dp.c b/drivers/net/wireless/ath/ath12k/dp.c
index af5f11fc1d84..3d46cfbf0a1c 100644
--- a/drivers/net/wireless/ath/ath12k/dp.c
+++ b/drivers/net/wireless/ath/ath12k/dp.c
@@ -1539,6 +1539,7 @@ static int ath12k_dp_setup(struct ath12k_base *ab)
}
for (i = 0; i < ab->hw_params->max_tx_ring; i++) {
+ spin_lock_init(&dp->tx_ring[i].wake_tx_lock);
dp->tx_ring[i].tcl_data_ring_id = i;
dp->tx_ring[i].tx_status_head = 0;
diff --git a/drivers/net/wireless/ath/ath12k/dp.h b/drivers/net/wireless/ath/ath12k/dp.h
index f8cfc7bb29dd..68d2020be9b8 100644
--- a/drivers/net/wireless/ath/ath12k/dp.h
+++ b/drivers/net/wireless/ath/ath12k/dp.h
@@ -58,6 +58,8 @@ struct dp_tx_ring {
u8 tcl_data_ring_id;
struct dp_srng tcl_data_ring;
struct dp_srng tcl_comp_ring;
+ /* Serializes wake_tx_queue operations for this ring */
+ spinlock_t wake_tx_lock;
struct hal_wbm_completion_ring_tx *tx_status;
int tx_status_head;
int tx_status_tail;
diff --git a/drivers/net/wireless/ath/ath12k/hal.c b/drivers/net/wireless/ath/ath12k/hal.c
index a164563fff28..c1c656e4550b 100644
--- a/drivers/net/wireless/ath/ath12k/hal.c
+++ b/drivers/net/wireless/ath/ath12k/hal.c
@@ -390,6 +390,7 @@ int ath12k_hal_srng_src_num_free(struct ath12k_base *ab, struct hal_srng *srng,
else
return ((srng->ring_size - hp + tp) / srng->entry_size) - 1;
}
+EXPORT_SYMBOL(ath12k_hal_srng_src_num_free);
void *ath12k_hal_srng_src_next_peek(struct ath12k_base *ab,
struct hal_srng *srng)
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hw.c b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
index d9fdd2fc8298..e3a6f9cdee24 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/hw.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
@@ -1100,9 +1100,57 @@ static void ath12k_wifi7_mac_op_tx(struct ieee80211_hw *hw,
}
}
+static void ath12k_wifi7_mac_op_wake_tx_queue(struct ieee80211_hw *hw,
+ struct ieee80211_txq *txq)
+{
+ struct ath12k_hw *ah = ath12k_hw_to_ah(hw);
+ struct ieee80211_tx_control control = {
+ .sta = txq->sta,
+ };
+ struct ath12k *ar = ah->radio;
+ struct dp_tx_ring *tx_ring;
+ struct hal_srng *tcl_ring;
+ struct ath12k_dp *dp;
+ struct sk_buff *skb;
+ int num_free;
+
+ if (!ar)
+ return;
+
+ if (unlikely(test_bit(ATH12K_FLAG_CRASH_FLUSH, &ar->ab->dev_flags)))
+ return;
+
+ dp = ar->ab->dp;
+ tx_ring = &dp->tx_ring[txq->ac % dp->hw_params->max_tx_ring];
+ tcl_ring = &dp->hal->srng_list[tx_ring->tcl_data_ring.ring_id];
+
+ while (1) {
+ spin_lock_bh(&tx_ring->wake_tx_lock);
+
+ spin_lock(&tcl_ring->lock);
+ num_free = ath12k_hal_srng_src_num_free(ar->ab, tcl_ring, true);
+ spin_unlock(&tcl_ring->lock);
+
+ if (num_free == 0) {
+ spin_unlock_bh(&tx_ring->wake_tx_lock);
+ break;
+ }
+
+ skb = ieee80211_tx_dequeue(hw, txq);
+ if (!skb) {
+ spin_unlock_bh(&tx_ring->wake_tx_lock);
+ break;
+ }
+
+ ath12k_wifi7_mac_op_tx(hw, &control, skb);
+
+ spin_unlock_bh(&tx_ring->wake_tx_lock);
+ }
+}
+
static const struct ieee80211_ops ath12k_ops_wifi7 = {
.tx = ath12k_wifi7_mac_op_tx,
- .wake_tx_queue = ieee80211_handle_wake_tx_queue,
+ .wake_tx_queue = ath12k_wifi7_mac_op_wake_tx_queue,
.start = ath12k_mac_op_start,
.stop = ath12k_mac_op_stop,
.reconfig_complete = ath12k_mac_op_reconfig_complete,
--
2.54.0
^ permalink raw reply related
* [PATCH 1/2] wifi: ath11k: implement custom wake_tx_queue with flow control
From: Jose Ignacio Tornos Martinez @ 2026-07-10 15:54 UTC (permalink / raw)
To: jjohnson
Cc: ath11k, ath12k, linux-wireless, linux-kernel,
Jose Ignacio Tornos Martinez
In-Reply-To: <20260710155443.1761760-1-jtornosm@redhat.com>
Under heavy traffic, ath11k experiences frequent -ENOMEM errors
("failed to transmit frame -12") when the hardware TCL ring fills up.
This issue is more commonly observed in VMs with PCIe passthrough but
also occurs on bare metal systems. It is particularly problematic on
devices with a single shared TCL ring where all traffic classes
compete for the same 512 descriptor slots.
Implement a custom wake_tx_queue operation that:
1. Checks hardware ring space before dequeuing packets from mac80211
2. Uses per-packet locking to serialize ring access and prevent races
3. Syncs with hardware state to get accurate free slot count
4. Returns early during firmware crash in the same way as other tx paths
This approach follows the pattern used in the iwlwifi driver, adapted
for ath11k's hardware ring architecture.
This eliminates -ENOMEM errors and improves throughput by optimizing
resource usage and preventing unnecessary packet drops.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
drivers/net/wireless/ath/ath11k/dp.c | 1 +
drivers/net/wireless/ath/ath11k/dp.h | 2 ++
drivers/net/wireless/ath/ath11k/mac.c | 49 ++++++++++++++++++++++++++-
3 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath11k/dp.c b/drivers/net/wireless/ath/ath11k/dp.c
index f389b97acbdd..2e5978ec2b05 100644
--- a/drivers/net/wireless/ath/ath11k/dp.c
+++ b/drivers/net/wireless/ath/ath11k/dp.c
@@ -1087,6 +1087,7 @@ int ath11k_dp_alloc(struct ath11k_base *ab)
for (i = 0; i < ab->hw_params.hal_params->num_tx_rings; i++) {
idr_init(&dp->tx_ring[i].txbuf_idr);
spin_lock_init(&dp->tx_ring[i].tx_idr_lock);
+ spin_lock_init(&dp->tx_ring[i].wake_tx_lock);
dp->tx_ring[i].tcl_data_ring_id = i;
dp->tx_ring[i].tx_status_head = 0;
diff --git a/drivers/net/wireless/ath/ath11k/dp.h b/drivers/net/wireless/ath/ath11k/dp.h
index 84f66839f0c6..6d99501aa269 100644
--- a/drivers/net/wireless/ath/ath11k/dp.h
+++ b/drivers/net/wireless/ath/ath11k/dp.h
@@ -87,6 +87,8 @@ struct dp_tx_ring {
struct idr txbuf_idr;
/* Protects txbuf_idr and num_pending */
spinlock_t tx_idr_lock;
+ /* Serializes wake_tx_queue operations for this ring */
+ spinlock_t wake_tx_lock;
struct hal_wbm_release_ring *tx_status;
int tx_status_head;
int tx_status_tail;
diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index 2d55cdc4d165..48a9e2b45e3d 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -10065,9 +10065,56 @@ static int ath11k_mac_op_sta_state(struct ieee80211_hw *hw,
return ret;
}
+static void ath11k_mac_op_wake_tx_queue(struct ieee80211_hw *hw,
+ struct ieee80211_txq *txq)
+{
+ struct ieee80211_tx_control control = {
+ .sta = txq->sta,
+ };
+ struct ath11k *ar = hw->priv;
+ struct dp_tx_ring *tx_ring;
+ struct hal_srng *tcl_ring;
+ struct sk_buff *skb;
+ int num_free;
+ u8 ring_id;
+
+ if (!ar)
+ return;
+
+ if (unlikely(test_bit(ATH11K_FLAG_CRASH_FLUSH, &ar->ab->dev_flags)))
+ return;
+
+ ring_id = txq->ac % ar->ab->hw_params.hal_params->num_tx_rings;
+ tx_ring = &ar->ab->dp.tx_ring[ring_id];
+ tcl_ring = &ar->ab->hal.srng_list[tx_ring->tcl_data_ring.ring_id];
+
+ while (1) {
+ spin_lock_bh(&tx_ring->wake_tx_lock);
+
+ spin_lock(&tcl_ring->lock);
+ num_free = ath11k_hal_srng_src_num_free(ar->ab, tcl_ring, true);
+ spin_unlock(&tcl_ring->lock);
+
+ if (num_free == 0) {
+ spin_unlock_bh(&tx_ring->wake_tx_lock);
+ break;
+ }
+
+ skb = ieee80211_tx_dequeue(hw, txq);
+ if (!skb) {
+ spin_unlock_bh(&tx_ring->wake_tx_lock);
+ break;
+ }
+
+ ath11k_mac_op_tx(hw, &control, skb);
+
+ spin_unlock_bh(&tx_ring->wake_tx_lock);
+ }
+}
+
static const struct ieee80211_ops ath11k_ops = {
.tx = ath11k_mac_op_tx,
- .wake_tx_queue = ieee80211_handle_wake_tx_queue,
+ .wake_tx_queue = ath11k_mac_op_wake_tx_queue,
.start = ath11k_mac_op_start,
.stop = ath11k_mac_op_stop,
.reconfig_complete = ath11k_mac_op_reconfig_complete,
--
2.54.0
^ permalink raw reply related
* [PATCH 0/2] ath11k/ath12k: implement TX flow control
From: Jose Ignacio Tornos Martinez @ 2026-07-10 15:54 UTC (permalink / raw)
To: jjohnson
Cc: ath11k, ath12k, linux-wireless, linux-kernel,
Jose Ignacio Tornos Martinez
This series implements custom wake_tx_queue operations for ath11k and
ath12k drivers to prevent hardware ring overflow issues under heavy
traffic.
Without proper flow control, both drivers experience -ENOMEM errors
("failed to transmit frame -12") when the hardware TCL ring fills up.
Additionally, ath12k can hang under sustained high throughput. These
issues are more commonly observed in VMs with PCIe passthrough but
also occur on bare metal systems.
The implementation follows the pattern used in the iwlwifi driver,
checking hardware ring space before dequeuing packets from mac80211.
Per-packet locking serializes ring access while allowing TX completions
to run, preventing deadlocks.
Testing shows stable operation with eliminated -ENOMEM errors, no hangs,
and improved throughput under heavy traffic conditions.
Jose Ignacio Tornos Martinez (2):
wifi: ath11k: implement custom wake_tx_queue with flow control
wifi: ath12k: implement custom wake_tx_queue with flow control
drivers/net/wireless/ath/ath11k/dp.c | 1 +
drivers/net/wireless/ath/ath11k/dp.h | 2 +
drivers/net/wireless/ath/ath11k/mac.c | 49 ++++++++++++++++++++-
drivers/net/wireless/ath/ath12k/dp.c | 1 +
drivers/net/wireless/ath/ath12k/dp.h | 2 +
drivers/net/wireless/ath/ath12k/hal.c | 1 +
drivers/net/wireless/ath/ath12k/wifi7/hw.c | 50 +++++++++++++++++++++-
7 files changed, 104 insertions(+), 2 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH] wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie()
From: Deepanshu Kartikey @ 2026-07-10 15:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel, syzbot+cc867e537e4bd36f69bb
In-Reply-To: <6be574903752d95ae7125461c38cc30b8a641d24.camel@sipsolutions.net>
On Fri, Jul 10, 2026 at 12:09 PM Johannes Berg
<johannes@sipsolutions.net> wrote:
>
> I don't believe you'd need to even export this, and we also already have
> validate_ie_attr() in nl80211, written in a better way too...
>
> johannes
Hi Johannes,
validate_ie_attr() takes a struct nlattr * but the wext path
works with a raw char * buffer, so it cannot be called directly.
I have reused the same approach using for_each_element() and
for_each_element_completed() instead. Is this acceptable?
Thanks
Deepanshu
^ permalink raw reply
* Re: [GIT PULL] wireless-2026-07-09
From: patchwork-bot+netdevbpf @ 2026-07-10 14:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <20260709115038.243870-3-johannes@sipsolutions.net>
Hello:
This pull request was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Thu, 9 Jul 2026 13:49:05 +0200 you wrote:
> Hi,
>
> Sorry, I meant to send this yesterday, hoping it'd get
> in/out before netdevconf and all that, because it's
> actually really big. Mostly I've now collected many
> random LLM-induced robustness fixes (I can't really
> call most of them security fixes, though there likely
> are a few).
>
> [...]
Here is the summary with links:
- [GIT,PULL] wireless-2026-07-09
https://git.kernel.org/netdev/net/c/a0d82fb85053
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] wifi: mwifiex: bound uAP association event IEs to the event buffer
From: Francesco Dolcini @ 2026-07-10 14:23 UTC (permalink / raw)
To: Johannes Berg, skyexpoc
Cc: Francesco Dolcini, Brian Norris, Miri Korenblit, Kalle Valo,
Kees Cook, linux-wireless, linux-kernel
In-Reply-To: <1462bcdb0944bfd3ae7ac9618cc59ab6cf75dfc6.camel@sipsolutions.net>
On Fri, Jul 10, 2026 at 09:41:26AM +0200, Johannes Berg wrote:
> On Fri, 2026-07-10 at 09:21 +0200, Francesco Dolcini wrote:
> > I think we received a few patches that are validating the data received
> > from the firmware (including this one).
> >
> > I did not review any of them yet, what is your opinion on those?
> >
> > Should we consider the firmware trust-worth or should we validate
> > everything we receive from it? Is there some agreement on this topic in
> > general?
>
> I don't really know fully "in general", but I/we generally treat these
> as issues. I'm not going to worry too much about them, but I think we
> should fix them.
Ack
On Fri, Jul 10, 2026 at 07:44:27PM +0900, skyexpoc wrote:
> > Should we consider the firmware trust-worthy or should we validate
> > everything we receive from it? Is there some agreement on this topic
> > in general?
>
> For mwifiex there's a concrete reason not to trust it: besides the
> SDIO/PCIe parts, mwifiex also drives USB dongles (8797/8801/8997), so the
> "firmware" can sit on a hot-pluggable, potentially attacker-supplied
> device. A malformed event from such a device is the same threat model as
> any other malicious USB peripheral, not just a hypothetical firmware bug.
...
> So I'd say it's consistent with how the driver already treats
> firmware-reported lengths and agreed, worth fixing.
... and ack.
Johannes, Brian: I will try to review those patches, unless someone
gets to them earlier and they are merged.
Francesco
^ permalink raw reply
* Re: [PATCH v2 0/7] usb: fix UAF related to dynamic ID
From: Greg Kroah-Hartman @ 2026-07-10 13:13 UTC (permalink / raw)
To: Gary Guo
Cc: Rafael J. Wysocki, Danilo Krummrich,
Toke Høiland-Jørgensen, Johan Hovold,
Mauro Carvalho Chehab, Petko Manolov, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Chas Williams, Alan Stern, linux-usb, driver-core, linux-wireless,
linux-media, linux-atm-general, netdev, usb-storage, linux-kernel,
Manuel Ebner
In-Reply-To: <20260707-usb_dyn_id_uaf-v2-0-632dcf3adfba@garyguo.net>
On Tue, Jul 07, 2026 at 01:26:39PM +0100, Gary Guo wrote:
> This is the USB version of the dynamic ID UAF fix similar to that of PCI
> [1]. usb_match_dynamic_id returns a pointer to field of usb_dynid, which
> can be freed when dynamic ID is removed via sysfs. It can be triggered with
> the following sequence:
>
> echo <vid> <pid> > /sys/bus/usb/drivers/<name>/new_id
> <probe start>
> echo <vid> <pid> > /sys/bus/usb/drivers/<name>/remove_id
> <probe use ID>
>
> Fix it by making a stack copy of the ID. This does mean that the lifetime
> of ID is scoped to probe (which is already the case but never spelled out
> explicitly). Drivers use these device IDs creatively, so this series also
> fix these drivers.
>
> The following coccinelle script is used to find all cases that are deemed
> suspicious. Only useful case for IDs should be access its fields, or
> forwarding (without type cast) to functions that do so.
>
> @usage@
> identifier fn, id;
> position p;
> @@
> fn(..., struct usb_device_id *id, ...)
> {
> ...
> id@p
> ...
> }
>
> // Due to cocci isomorphism this needs to be explicit
> @bad@
> identifier fn, id;
> type T;
> position usage.p;
> @@
> fn(..., struct usb_device_id *id, ...)
> {
> ...
> (T*)id@p
> ...
> }
>
> // Good use cases
> @good@
> identifier fn, id, fld;
> expression E;
> position usage.p;
> @@
> fn(..., struct usb_device_id *id, ...)
> {
> ...
> (
> id@p->fld
> |
> E(..., id@p, ...)
> |
> // Redundant checks, but ignore
> !id@p
> |
> // Redundant checks, but ignore
> id ? ... : ...
> )
> ...
> }
>
> @script:python depends on usage && (bad || !good)@
> p << usage.p;
> @@
> coccilib.report.print_report(p[0], "suspicious use of device ID")
>
> There're 3 drivers that store usb_device_id, and they're converted to just
> use driver_info instead. The other fields of usb_device_id can be easily
> retrieved from usb_device via descriptor.id{Vendor,Product}.
>
> There're also a few users that rely on pointer arithmetics. Pegaus and
> xusbatm are converted to use driver_info. All unusal USB mass storage
> drivers rely on pointer arithemtic to index into a side table, because USB
> storage subsystem is using the driver_data for flags. Luckily all these
> drivers set no_dynamic_id. Ideally these could be fixed too but their
> maintainers probably have a better idea of how.
>
> Link: https://lore.kernel.org/driver-core/20260706-pci_id_fix-v3-0-2d48fc025acc@garyguo.net [1]
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Thanks for these. I had an old patch series that attempted to do some
locking in this area to fix this up, but this version is much nicer.
I'll go queue it up now.
greg k-h
^ permalink raw reply
* Re: (subset) [PATCH v9 00/14] firmware: qcom: Add OP-TEE PAS service support
From: Sumit Garg @ 2026-07-10 12:12 UTC (permalink / raw)
To: Bjorn Andersson
Cc: konradybcio, linux-arm-msm, devicetree, dri-devel, freedreno,
linux-media, netdev, linux-wireless, ath12k, linux-remoteproc,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jenswi, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <178362521364.2422497.1305957434056184382.b4-ty@kernel.org>
Hi Bjorn,
On Thu, Jul 09, 2026 at 02:32:39PM -0500, Bjorn Andersson wrote:
>
> On Thu, 02 Jul 2026 17:28:16 +0530, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >
> > Qcom platforms has the legacy of using non-standard SCM calls
> > splintered over the various kernel drivers. These SCM calls aren't
> > compliant with the standard SMC calling conventions which is a
> > prerequisite to enable migration to the FF-A specifications from Arm.
> >
> > [...]
>
> Applied, thanks!
>
> [01/14] firmware: qcom: Add a generic PAS service
> commit: 08314e7c2c38b9ae6a5e01c58ed10a950859404d
> [02/14] firmware: qcom_scm: Migrate to generic PAS service
> commit: 5c1a2975d23c51c01aca51945d0f10a4ee4c9020
> [03/14] firmware: qcom: Add a PAS TEE service
> commit: b6f7978da0c4d26fe465aa6634f5a0b48f900de0
> [14/14] MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service
> commit: 6701259025d49139131a0eb2257659a066dcca22
>
> This is available as an immutable branch, for other subsystems to pull at:
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git 20260702115835.167602-2-sumit.garg@kernel.org
>
>
> [04/14] remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs
> commit: 254030af0d81b12b7624d9ce85c6bdd3171629c6
> [05/14] remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs
> commit: f3b1357673ddb37ae8b9a8fe44df73cbd2a519c5
> [06/14] remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs
> commit: ea3b5245f5deba916320b32a8e6510a74c034c17
> [07/14] remoteproc: qcom: Select QCOM_PAS generic service
> commit: c4383254ac7a529736577e304176a10371c2ee0b
>
Thanks for picking the partial set although I expected for you to pick
the entire set given acks from all the other subsystem maintainers. Let
me know how we should proceed further.
-Sumit
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: update IPQ5332 BDF address offset
From: Rameshkumar Sundaram @ 2026-07-10 11:50 UTC (permalink / raw)
To: Aaradhana Sahu, ath12k; +Cc: linux-wireless
In-Reply-To: <20260710053534.879233-1-aaradhana.sahu@oss.qualcomm.com>
On 7/10/2026 11:05 AM, Aaradhana Sahu wrote:
> In the ath12k driver, the BDF_MEM_REGION_TYPE address is derived by
> adding a fixed bdf_addr_offset to the WCSS Q6 region base address.
>
> The current offset (0xC00000) works only when the Q6 region contains
> the IPQ5332 ucode alone. On some IPQ5332 platform variants, additional
> devices share the same WCSS Q6 processor and place their firmware
> ucode in the same Q6 region. This results in multiple ucode sections
> within the region, and the existing offset can cause the BDF memory
> region to overlap with firmware read-only sections, which can lead to
> firmware crash and driver boot failure.
>
> Increase the bdf_addr_offset to 0x1A00000, determined by analyzing
> firmware memory maps across all known IPQ5332 platform variants. This
> value represents the upper bound of the largest combined firmware and
> ensures all IPQ5332 variants can allocate the BDF region safely without
> overlapping firmware regions.
>
> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] wifi: mwifiex: bound uAP association event IEs to the event buffer
From: skyexpoc @ 2026-07-10 10:44 UTC (permalink / raw)
To: Johannes Berg, Brian Norris, Francesco Dolcini
Cc: Kees Cook, linux-kernel, Kalle Valo, linux-wireless,
Miri Korenblit
In-Reply-To: <1462bcdb0944bfd3ae7ac9618cc59ab6cf75dfc6.camel@sipsolutions.net>
[-- Attachment #1.1: Type: text/plain, Size: 1710 bytes --]
> Should we consider the firmware trust-worthy or should we validate
> everything we receive from it? Is there some agreement on this topic
> in general?
For mwifiex there's a concrete reason not to trust it: besides the
SDIO/PCIe parts, mwifiex also drives USB dongles (8797/8801/8997), so the
"firmware" can sit on a hot-pluggable, potentially attacker-supplied
device. A malformed event from such a device is the same threat model as
any other malicious USB peripheral, not just a hypothetical firmware bug.
There is also precedent inside mwifiex itself: commit 119585281617
("wifi: mwifiex: Fix OOB and integer underflow when rx packets") already
added exactly these bounds checks to the receive-data path. This patch is
the same class of fix for the uAP event path, which that commit did not
cover.
So I'd say it's consistent with how the driver already treats
firmware-reported lengths and agreed, worth fixing.
Thanks,
HE WEI（ギカク）
> On Friday, Jul 10, 2026 at 4:41 PM, Johannes Berg <johannes@sipsolutions.net (mailto:johannes@sipsolutions.net)> wrote:
> On Fri, 2026-07-10 at 09:21 +0200, Francesco Dolcini wrote:
> > I think we received a few patches that are validating the data received
> > from the firmware (including this one).
> >
> > I did not review any of them yet, what is your opinion on those?
> >
> > Should we consider the firmware trust-worth or should we validate
> > everything we receive from it? Is there some agreement on this topic in
> > general?
>
> I don't really know fully "in general", but I/we generally treat these
> as issues. I'm not going to worry too much about them, but I think we
> should fix them.
>
> johannes
[-- Attachment #1.2: Type: text/html, Size: 2672 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 885 bytes --]
^ permalink raw reply
* Re: [PATCH] wifi: mwifiex: bound uAP association event IEs to the event buffer
From: Johannes Berg @ 2026-07-10 7:41 UTC (permalink / raw)
To: Francesco Dolcini, HE WEI (ギカク),
Brian Norris
Cc: Miri Korenblit, Kalle Valo, Kees Cook, linux-wireless,
linux-kernel
In-Reply-To: <20260710072140.GA17790@francesco-nb>
On Fri, 2026-07-10 at 09:21 +0200, Francesco Dolcini wrote:
> I think we received a few patches that are validating the data received
> from the firmware (including this one).
>
> I did not review any of them yet, what is your opinion on those?
>
> Should we consider the firmware trust-worth or should we validate
> everything we receive from it? Is there some agreement on this topic in
> general?
I don't really know fully "in general", but I/we generally treat these
as issues. I'm not going to worry too much about them, but I think we
should fix them.
johannes
^ permalink raw reply
* Re: [PATCH] wifi: mwifiex: bound uAP association event IEs to the event buffer
From: Francesco Dolcini @ 2026-07-10 7:21 UTC (permalink / raw)
To: HE WEI (ギカク), Brian Norris, Johannes Berg
Cc: Brian Norris, Francesco Dolcini, Miri Korenblit, Johannes Berg,
Kalle Valo, Kees Cook, linux-wireless, linux-kernel
In-Reply-To: <20260629120333.94222-1-skyexpoc@gmail.com>
Hello Brian, Johannes
On Mon, Jun 29, 2026 at 09:03:33PM +0900, HE WEI (ギカク) wrote:
> mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the
> (re)association request IEs that the firmware copies into the event:
>
> sinfo->assoc_req_ies = &event->data[len];
> len = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control;
> sinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len;
>
> event->len is supplied by the device firmware and is never validated,
I think we received a few patches that are validating the data received
from the firmware (including this one).
I did not review any of them yet, what is your opinion on those?
Should we consider the firmware trust-worth or should we validate
everything we receive from it? Is there some agreement on this topic in
general?
Francesco
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: update IPQ5332 BDF address offset
From: Baochen Qiang @ 2026-07-10 6:58 UTC (permalink / raw)
To: Aaradhana Sahu, ath12k; +Cc: linux-wireless
In-Reply-To: <20260710053534.879233-1-aaradhana.sahu@oss.qualcomm.com>
On 7/10/2026 1:35 PM, Aaradhana Sahu wrote:
> In the ath12k driver, the BDF_MEM_REGION_TYPE address is derived by
> adding a fixed bdf_addr_offset to the WCSS Q6 region base address.
>
> The current offset (0xC00000) works only when the Q6 region contains
> the IPQ5332 ucode alone. On some IPQ5332 platform variants, additional
> devices share the same WCSS Q6 processor and place their firmware
> ucode in the same Q6 region. This results in multiple ucode sections
> within the region, and the existing offset can cause the BDF memory
> region to overlap with firmware read-only sections, which can lead to
> firmware crash and driver boot failure.
>
> Increase the bdf_addr_offset to 0x1A00000, determined by analyzing
> firmware memory maps across all known IPQ5332 platform variants. This
> value represents the upper bound of the largest combined firmware and
> ensures all IPQ5332 variants can allocate the BDF region safely without
> overlapping firmware regions.
>
> Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie()
From: Johannes Berg @ 2026-07-10 6:39 UTC (permalink / raw)
To: Deepanshu Kartikey
Cc: linux-wireless, linux-kernel, syzbot+cc867e537e4bd36f69bb
In-Reply-To: <20260710024637.16729-1-kartikey406@gmail.com>
On Fri, 2026-07-10 at 08:16 +0530, Deepanshu Kartikey wrote:
>
> +bool cfg80211_validate_ies(const u8 *ies, size_t ies_len)
> +{
> + size_t pos = 0;
> +
> + while (pos < ies_len) {
> + if (pos + 2 > ies_len)
> + return false;
> + if (pos + 2 + ies[pos + 1] > ies_len)
> + return false;
> + pos += 2 + ies[pos + 1];
> + }
> +
> + return true;
> +}
> +EXPORT_SYMBOL(cfg80211_validate_ies);
I don't believe you'd need to even export this, and we also already have
validate_ie_attr() in nl80211, written in a better way too...
johannes
^ permalink raw reply
* [ath-next] wifi: ath10k: trigger hardware recovery upon rx failures
From: Manikanta Pubbisetty @ 2026-07-10 6:04 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Manikanta Pubbisetty
When an error occurs during RX packet processing (e.g., MSDU done
failure), the driver sets rx_confused and drops all subsequent RX
packets until a Wi-Fi ON/OFF cycle clears the flag. This can leave
the device in a bad state where it cannot process RX data traffic.
Instead of leaving the device in such a state, trigger hardware
recovery so that such an error state can be reset and the device
can function again normally.
Tested-on: WCN3990 hw1.0 WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
Signed-off-by: Manikanta Pubbisetty <manikanta.pubbisetty@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index faac359aa9ac..1005daaaf158 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2343,10 +2343,8 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
if (ret < 0) {
ath10k_warn(ar, "rx ring became corrupted: %d\n", ret);
__skb_queue_purge(&amsdu);
- /* FIXME: It's probably a good idea to reboot the
- * device instead of leaving it inoperable.
- */
htt->rx_confused = true;
+ ath10k_core_start_recovery(ar);
return ret;
}
@@ -3311,6 +3309,7 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
if (ret < 0) {
ath10k_warn(ar, "failed to pop paddr list: %d\n", ret);
htt->rx_confused = true;
+ ath10k_core_start_recovery(ar);
return -EIO;
}
@@ -3344,6 +3343,7 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
ath10k_warn(ar, "failed to extract amsdu: %d\n", ret);
htt->rx_confused = true;
__skb_queue_purge(&list);
+ ath10k_core_start_recovery(ar);
return -EIO;
}
}
base-commit: 913998f903fb1432c0046c33003db38a9e8bedb1
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next] wifi: ath12k: update IPQ5332 BDF address offset
From: Aaradhana Sahu @ 2026-07-10 5:35 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, Aaradhana Sahu
In the ath12k driver, the BDF_MEM_REGION_TYPE address is derived by
adding a fixed bdf_addr_offset to the WCSS Q6 region base address.
The current offset (0xC00000) works only when the Q6 region contains
the IPQ5332 ucode alone. On some IPQ5332 platform variants, additional
devices share the same WCSS Q6 processor and place their firmware
ucode in the same Q6 region. This results in multiple ucode sections
within the region, and the existing offset can cause the BDF memory
region to overlap with firmware read-only sections, which can lead to
firmware crash and driver boot failure.
Increase the bdf_addr_offset to 0x1A00000, determined by analyzing
firmware memory maps across all known IPQ5332 platform variants. This
value represents the upper bound of the largest combined firmware and
ensures all IPQ5332 variants can allocate the BDF region safely without
overlapping firmware regions.
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/wifi7/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hw.c b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
index e5bf9d218104..03f87374881f 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/hw.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
@@ -689,7 +689,7 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
.ce_ie_addr = &ath12k_wifi7_ce_ie_addr_ipq5332,
.ce_remap = &ath12k_wifi7_ce_remap_ipq5332,
- .bdf_addr_offset = 0xC00000,
+ .bdf_addr_offset = 0x1A00000,
.dp_primary_link_only = true,
.client = {
base-commit: e36b3c776adc9891d8574241be77640ded819ee7
--
2.34.1
^ permalink raw reply related
* rtw89: 8922a hw_scan on an MLO association blacks out traffic ~3 s per scan (45-62% loss under load, AP kicks STA with DISASSOC_LOW_ACK)
From: Louis Kotze @ 2026-07-10 5:31 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless, Bitterblue Smith, loukot
Hi Ping-Ke,
On an RTL8922AU station associated to a Wi-Fi 7 AP MLD, every full
hw_scan takes the link off-channel for about 3.3 s essentially
contiguously, with roughly 2 s of completely dead downlink per scan.
Under moderate load with a periodic background scan this costs 45-62%
of the traffic, and the AP sometimes deauthenticates the station with
reason 34 (DISASSOC_LOW_ACK) a few seconds into the first scan. The
same client and the same scan are fine on a non-MLO association, and
an Intel client is fine on the same AP MLD, so the failure needs the
rtw89 + MLO combination. Evidence below; I can provide full captures.
Environment
-----------
- RTL8922AU (USB 0bda:8912), firmware 0.35.80.3 (8ef4f0cf), cmd
version 1, rtw8922a_fw-4.bin from linux-firmware 20260622.
- Driver: rtw89 out-of-tree USB snapshot r1868 (morrownr; the
scan-offload H2C code matches current wireless-next). Kernel 7.1.3.
- AP: TP-Link Deco BE65 v2 (Qualcomm), EHT AP MLD, 5+6 GHz.
- Association: EHT160, tested both single-link (5 GHz) and EMLSR
dual-link (5+6 GHz anchor on 6 GHz). Same behavior.
- Test: iperf3 UDP downlink to the STA, full "iw dev wlan0 scan
trigger" every 5-8 s, loss measured at the STA; AP-side per-station
tx_errors read from the AP where available.
The differential (three-way control, 2026-06-19 campaign)
---------------------------------------------------------
Identical 100 Mbit/s downlink + full scan every 5 s, 60 s per cell:
- rtw89 on the AP MLD (EHT160): 62.3% loss (repeats 60.4, 61.8),
AP tx_errors +282k, ~2 s dead
downlink on EVERY one of 12 scans.
- Intel AX210 on the SAME AP MLD,
same channel, same test: 3.5% loss, tx_errors +4.7k,
0 dead seconds.
- Same rtw89 client on a non-MLO
AP (Archer AX20, HE80), same
driver and scan: 5.0% loss, no blackout.
- No-scan controls on all cells: ~0% loss.
- A short scan (single channel, or
8 non-DFS 5 GHz channels) on the
AP MLD link: 4.9-6.9% loss, 0 dead seconds.
So off-channel DURATION is the driver: the full-scan ~3.3 s excursion
is what kills the link, and only on the MLO association. The loss is
direction-symmetric (uplink also loses ~62%, with AP tx_errors not
moving, so this is not just an AP buffering question; the station is
simply away too long in one stretch).
Still present on current firmware (2026-07-10)
----------------------------------------------
Re-ran on fw 0.35.80.3 / driver r1868 / EMLSR dual-link, 18 Mbit/s
downlink, full scan every 8 s, 40 s:
- Control (no scans): 0.0% loss.
- Run 1: 27.2% loss, and the AP deauthenticated the
station with reason 34 (DISASSOC_LOW_ACK)
about 3 s into the first scan.
- Run 2: 45.3% loss across 5 scans.
Why this looks like a firmware scan-scheduling issue on MLO
-----------------------------------------------------------
The BE scan-offload design should protect an associated link: the
driver requests opmode=RTW89_SCAN_OPMODE_INTV with an op-channel
revisit interval, num_opch=1 and txnull=1, and I confirmed with an
instrumented H2C builder that this is armed with the correct link
BSSID. RTW89_OFF_CHAN_TIME should cap contiguous off-channel time at
about 100 ms. The C2H LEAVE/ENTER notifications do arrive at the
driver during the scan. Yet the observed result on the MLO
association is a ~3.3 s contiguous blackout per scan, as if the
op-channel revisits do not give the link usable airtime.
Two more over-the-air observations (AX210 in monitor mode):
- The station's PM=1 nullfuncs are visible and roughly double during
scan periods, so PM signaling is not absent. But the AP sets TIM
for this station in only ~59 of ~624 beacons during the test,
versus ~98 of ~632 for the AX210 under the same load, and its
tx_errors climb throughout: the doze windows evidently do not
line up with the actual off-channel excursions.
- As an experiment I had the driver send an additional PM=1 nullfunc
at each LEAVE_OP and PM=0 at ENTER_OP: downlink loss dropped from
~37% to 0% and the AP buffered correctly. Not a viable fix (it
fights the firmware's own scan-time PM handling and eventually
destabilizes the connection), but it shows well-timed PM framing
fully protects the downlink on this AP.
Questions for the firmware team
-------------------------------
1. On an MLO/EMLSR association, does the BE scan-offload firmware
actually perform the periodic op-channel revisit (INTV opmode)
during a full multi-band scan, or does it batch the whole scan as
one long excursion?
2. Is the per-excursion txnull PM frame sent at the right time and
on the right link for an MLD association (and with the associated
link address)?
3. Is there anything the driver should be doing differently for MLO
scans (splitting the channel list, different opch policy) that
would bound the off-channel time?
Practical impact: any periodic background scan (wpa_supplicant or
NetworkManager bgscan, roaming scans) triggers this; on APs with an
aggressive low-ack policy it escalates to the AP kicking the station
mid-scan.
I am happy to share the full capture campaign (client iperf3 JSON,
monitor-mode pcaps, AP-side tx_errors series, per-second traces), the
H2C instrumentation patch, and to test debug firmware or patches on
this setup.
Best regards,
Louis Kotze
^ permalink raw reply
* [PATCH] wifi: rtw89: 8852au: Add support for Mercusys MA72XH
From: Abhishek Tamboli @ 2026-07-10 3:00 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, linux-kernel
Add the ID 2c4e:0124 to the rtw_8852au_id_table to
support the Mercusys MA72XH usb adapter.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221738
Signed-off-by: Abhishek Tamboli <abhishektamboli9@gmail.com>
---
drivers/net/wireless/realtek/rtw89/rtw8852au.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852au.c b/drivers/net/wireless/realtek/rtw89/rtw8852au.c
index 29b7f7769370..1f93b3c89039 100644
--- a/drivers/net/wireless/realtek/rtw89/rtw8852au.c
+++ b/drivers/net/wireless/realtek/rtw89/rtw8852au.c
@@ -64,6 +64,8 @@ static const struct usb_device_id rtw_8852au_id_table[] = {
.driver_info = (kernel_ulong_t)&rtw89_8852au_info },
{ USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0141, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)&rtw89_8852au_info },
+ { USB_DEVICE_AND_INTERFACE_INFO(0x2c4e, 0x0124, 0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t)&rtw89_8852au_info },
{ USB_DEVICE_AND_INTERFACE_INFO(0x3625, 0x010d, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)&rtw89_8852au_info },
{ USB_DEVICE_AND_INTERFACE_INFO(0x3625, 0x010f, 0xff, 0xff, 0xff),
--
2.34.1
^ permalink raw reply related
* [PATCH] wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie()
From: Deepanshu Kartikey @ 2026-07-10 2:46 UTC (permalink / raw)
To: johannes
Cc: linux-wireless, linux-kernel, Deepanshu Kartikey,
syzbot+cc867e537e4bd36f69bb
Syzkaller reported a KASAN slab-out-of-bounds read in skip_ie()
and a fortify memcpy panic in cfg80211_sme_get_conn_ies().
The KASAN allocation trace shows that a malformed IE buffer is
stored via SIOCSIWGENIE (cfg80211_wext_siwgenie()) without any
validation. The crash trace shows that a subsequent SIOCSIWESSID
triggers a connection attempt which calls cfg80211_sme_get_conn_ies()
to process the stored IE buffer, causing:
- An out-of-bounds read in skip_ie() which reads ies[pos+1]
(the length byte) past the end of the 1-byte buffer.
- An integer underflow in the memcpy size argument when offs
returned by ieee80211_ie_split() exceeds ies_len, causing
unsigned subtraction to wrap to SIZE_MAX and triggering a
fortify panic.
Fix this by validating the IE buffer in cfg80211_wext_siwgenie()
before storing it. Add cfg80211_validate_ies() which walks the
buffer and verifies every element has at least 2 bytes (type +
length) and sufficient data bytes as indicated by its length
field. Return -EINVAL if validation fails.
Reported-by: syzbot+cc867e537e4bd36f69bb@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=cc867e537e4bd36f69bb
Tested-by: syzbot+cc867e537e4bd36f69bb@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
include/net/cfg80211.h | 1 +
net/wireless/util.c | 16 ++++++++++++++++
net/wireless/wext-sme.c | 2 ++
3 files changed, 19 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8188ad200de5..32cef926f8a4 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -10992,4 +10992,5 @@ void cfg80211_incumbent_signal_notify(struct wiphy *wiphy,
u32 signal_interference_bitmap,
gfp_t gfp);
+bool cfg80211_validate_ies(const u8 *ies, size_t ies_len);
#endif /* __NET_CFG80211_H */
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 24527bf321b2..a685020c8efc 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -3083,3 +3083,19 @@ bool cfg80211_wdev_channel_allowed(struct wireless_dev *wdev,
return false;
}
EXPORT_SYMBOL(cfg80211_wdev_channel_allowed);
+
+bool cfg80211_validate_ies(const u8 *ies, size_t ies_len)
+{
+ size_t pos = 0;
+
+ while (pos < ies_len) {
+ if (pos + 2 > ies_len)
+ return false;
+ if (pos + 2 + ies[pos + 1] > ies_len)
+ return false;
+ pos += 2 + ies[pos + 1];
+ }
+
+ return true;
+}
+EXPORT_SYMBOL(cfg80211_validate_ies);
diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
index 573b6b15a446..3e9b071f6d66 100644
--- a/net/wireless/wext-sme.c
+++ b/net/wireless/wext-sme.c
@@ -319,6 +319,8 @@ int cfg80211_wext_siwgenie(struct net_device *dev,
return 0;
if (ie_len) {
+ if (!cfg80211_validate_ies(extra, ie_len))
+ return -EINVAL;
ie = kmemdup(extra, ie_len, GFP_KERNEL);
if (!ie)
return -ENOMEM;
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox