* [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
From: Santiago Ruano Rincón @ 2026-04-23 21:14 UTC (permalink / raw)
To: Jeff Johnson, linux-wireless, ath11k, linux-kernel
Cc: Mark Pearson, kfarnung, koike
Commit 0eb002c93c3b4 ("wifi: ath11k: Add missing platform IDs for quirk
table") added some Lenovo platform IDs to the quirk table to address a
wakeup from suspend issue [1]. However, at least two more platform ID
are missing in that table: P14s Gen 5 AMD, as reported by Kyle Farnung [2]
and P14s Gen 3 AMD. This commit adds one ID for each.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=219196
[2] https://bugzilla.kernel.org/show_bug.cgi?id=219196#c23
Tested-on: P14s G3 AMD.
Fixes: ce8669a27016 ("wifi: ath11k: determine PM policy based on machine model")
Signed-off-by: Santiago Ruano Rincón <santiagorr@riseup.net>
---
drivers/net/wireless/ath/ath11k/core.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
index 3f6f4db5b7ee..56938d5d42a1 100644
--- a/drivers/net/wireless/ath/ath11k/core.c
+++ b/drivers/net/wireless/ath/ath11k/core.c
@@ -957,6 +957,13 @@ static const struct dmi_system_id ath11k_pm_quirk_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "21K4"),
},
},
+ {
+ .driver_data = (void *)ATH11K_PM_WOW,
+ .matches = { /* P14s G3 AMD */
+ DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "21J5"),
+ },
+ },
{
.driver_data = (void *)ATH11K_PM_WOW,
.matches = { /* P14s G4 AMD #1 */
@@ -971,6 +978,13 @@ static const struct dmi_system_id ath11k_pm_quirk_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "21K6"),
},
},
+ {
+ .driver_data = (void *)ATH11K_PM_WOW,
+ .matches = { /* P14s Gen 5 AMD */
+ DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "21ME"),
+ },
+ },
{
.driver_data = (void *)ATH11K_PM_WOW,
.matches = { /* T16 G2 AMD #1 */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH rtw-next v2 5/5] wifi: rtl8xxxu: Enable 40 MHz width by default
From: Bitterblue Smith @ 2026-04-23 19:34 UTC (permalink / raw)
To: Linux regressions mailing list, linux-wireless@vger.kernel.org
Cc: Ping-Ke Shih, Jes Sorensen, art1310
In-Reply-To: <8a4c664f-231f-437e-b010-b741c7ed7be8@leemhuis.info>
On 23/04/2026 16:39, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 11/20/25 15:13, Bitterblue Smith wrote:
>> 40 MHz support is hidden behind the ht40_2g module parameter with
>> this comment:
>>
>> /*
>> * Some APs will negotiate HT20_40 in a noisy environment leading
>> * to miserable performance. Rather than defaulting to this, only
>> * enable it if explicitly requested at module load time.
>> */
>
> FYI: this patch causes a regression that was reported to bugzilla
> (reporter CCed here): https://bugzilla.kernel.org/show_bug.cgi?id=221394
>
Hi Thorsten,
Thanks for letting us know. I replied at the Bugzilla.
> """
> Since kernel 6.19.0, the rtl8xxxu driver fails to maintain a connection
> with the Realtek RTL8188FTV (0bda:f179) USB Wi-Fi adapter. The device
> gets stuck "configuring interface" and eventually times out, effectively
> disappearing from the network manager.
>
> Regression Window:
> Works perfectly on: 6.12.x (LTS) and 6.18.x (LTS and non LTS).
> Broken on: 6.19.x, up through 7.0.0.
>
> Notes:
> - The device remains visible on the USB bus (lsusb still shows 0bda:f179).
> - The wlan0 interface is created.
> - NetworkManager attempts to associate, but authentication times out.
> - Disabling USB autosuspend (usbcore.autosuspend=-1) does not resolve
> the issue.
>
> Hardware:
> Bus 001 Device 002: ID 0bda:f179 Realtek Semiconductor Corp. RTL8188FTV
> 802.11b/g/n 1T1R 2.4G WLAN Adapter
> """
>
> Then later:
>
> """
> I confirmed that the Commit dbf9b7b "wifi: rtl8xxxu: Enable 40 MHz width
> by default" is the cause of the regression.
>
> I tested passing cfg80211_disable_40mhz_24ghz=1 to the cfg80211 module
> on 6.19.x and 7.0, and the adapter works perfectly again.
>
> In Windows, forcing the adapter to 20_40MHz causes it to be unable to
> connect to any AP, and it only works in 20MHz mode. In Linux 6.19+, it
> gets stuck configuring the interface and crashes. So this is most
> probably a hardware issue.
> """
>
> Ciao, Thorsten
>
>> This parameter was added in commit 26f1fad29ad9 ("New driver:
>> rtl8xxxu (mac80211)"). Back then rtl8xxxu only supported RTL8723AU
>> and the RTL8192CU family. It's entirely possible the miserable
>> performance was due to mistakes in the channel switching function,
>> which were fixed in a previous patch.
>>
>> Delete the ht40_2g module parameter. If someone still needs to
>> disable 40 MHz support, cfg80211 has the module parameter
>> cfg80211_disable_40mhz_24ghz. That works too.
>>
>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
>> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
>> ---
>> v2:
>> - Add Reviewed-by.
>> ---
>> drivers/net/wireless/realtek/rtl8xxxu/core.c | 19 ++++---------------
>> 1 file changed, 4 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c b/drivers/net/wireless/realtek/rtl8xxxu/core.c
>> index a18f73aea837..c06ad064f37c 100644
>> --- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
>> +++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
>> @@ -20,7 +20,6 @@
>> #define DRIVER_NAME "rtl8xxxu"
>>
>> int rtl8xxxu_debug;
>> -static bool rtl8xxxu_ht40_2g;
>> static bool rtl8xxxu_dma_aggregation;
>> static int rtl8xxxu_dma_agg_timeout = -1;
>> static int rtl8xxxu_dma_agg_pages = -1;
>> @@ -45,8 +44,6 @@ MODULE_FIRMWARE("rtlwifi/rtl8192fufw.bin");
>>
>> module_param_named(debug, rtl8xxxu_debug, int, 0600);
>> MODULE_PARM_DESC(debug, "Set debug mask");
>> -module_param_named(ht40_2g, rtl8xxxu_ht40_2g, bool, 0600);
>> -MODULE_PARM_DESC(ht40_2g, "Enable HT40 support on the 2.4GHz band");
>> module_param_named(dma_aggregation, rtl8xxxu_dma_aggregation, bool, 0600);
>> MODULE_PARM_DESC(dma_aggregation, "Enable DMA packet aggregation");
>> module_param_named(dma_agg_timeout, rtl8xxxu_dma_agg_timeout, int, 0600);
>> @@ -4896,8 +4893,7 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
>> sgi = 1;
>>
>> highest_rate = fls(ramask) - 1;
>> - if (rtl8xxxu_ht40_2g &&
>> - (sta->deflink.ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40))
>> + if (sta->deflink.ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40)
>> bw = RATE_INFO_BW_40;
>> else
>> bw = RATE_INFO_BW_20;
>> @@ -7851,7 +7847,8 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
>> sband->ht_cap.ht_supported = true;
>> sband->ht_cap.ampdu_factor = IEEE80211_HT_MAX_AMPDU_64K;
>> sband->ht_cap.ampdu_density = IEEE80211_HT_MPDU_DENSITY_16;
>> - sband->ht_cap.cap = IEEE80211_HT_CAP_SGI_20 | IEEE80211_HT_CAP_SGI_40;
>> + sband->ht_cap.cap = IEEE80211_HT_CAP_SGI_20 | IEEE80211_HT_CAP_SGI_40 |
>> + IEEE80211_HT_CAP_SUP_WIDTH_20_40;
>> memset(&sband->ht_cap.mcs, 0, sizeof(sband->ht_cap.mcs));
>> sband->ht_cap.mcs.rx_mask[0] = 0xff;
>> sband->ht_cap.mcs.rx_mask[4] = 0x01;
>> @@ -7860,15 +7857,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
>> sband->ht_cap.cap |= IEEE80211_HT_CAP_SGI_40;
>> }
>> sband->ht_cap.mcs.tx_params = IEEE80211_HT_MCS_TX_DEFINED;
>> - /*
>> - * Some APs will negotiate HT20_40 in a noisy environment leading
>> - * to miserable performance. Rather than defaulting to this, only
>> - * enable it if explicitly requested at module load time.
>> - */
>> - if (rtl8xxxu_ht40_2g) {
>> - dev_info(&udev->dev, "Enabling HT_20_40 on the 2.4GHz band\n");
>> - sband->ht_cap.cap |= IEEE80211_HT_CAP_SUP_WIDTH_20_40;
>> - }
>> +
>> hw->wiphy->bands[NL80211_BAND_2GHZ] = sband;
>>
>> hw->wiphy->rts_threshold = 2347;
>
> #regzbot introduced: dbf9b7b
> #regzbot title: wifi: rtl8xxxu: 40 MHz mode breaks things (just like in
> Windows)
> #regzbot dup: https://bugzilla.kernel.org/show_bug.cgi?id=221394
^ permalink raw reply
* Re: [PATCH v2 0/3] wifi: wcn36xx: fix OOB reads and heap overflow from firmware responses
From: Jeff Johnson @ 2026-04-23 19:29 UTC (permalink / raw)
To: Loic Poulain; +Cc: Johannes Berg, Tristan Madani, wcn36xx, linux-wireless
In-Reply-To: <CAFEp6-2jAe+-1xyZtMKzmrJ83yW+sZNMEjSCY1dYstn_=azqdw@mail.gmail.com>
On 4/17/2026 1:24 AM, Loic Poulain wrote:
> Hi Jeff,
>
> On Fri, Apr 17, 2026 at 2:01 AM Jeff Johnson
> <jeff.johnson@oss.qualcomm.com> wrote:
>>
>> On 4/16/2026 11:39 AM, Johannes Berg wrote:
>>> On Thu, 2026-04-16 at 09:25 -0700, Jeff Johnson wrote:
>>>> On 4/15/2026 3:37 PM, Tristan Madani wrote:
>>>>> From: Tristan Madani <tristan@talencesecurity.com>
>>>>>
>>>>> Hi Loic,
>>>>>
>>>>> Note: this is a v2 resubmission. The original was sent via Gmail which
>>>>> caused HTML rendering issues. This version uses git send-email for
>>>>> proper plain-text formatting.
>>>>>
>>>>> Three issues in wcn36xx HAL firmware response handling, including a heap
>>>>> overflow in the main response dispatcher:
>>>>>
>>>>> Proposed fixes in the following patches.
>>>>>
>>>>> Thanks,
>>>>> Tristan
>>>>
>>>> Are you able to cause these issues to occur?
>>>> My expectation is that this is testing things that firmware will never do, and
>>>> hence this adds code and processing with no actual benefit.
>>>
>>> We're not really supposed to completely trust firmware though, right? :)
>>
>> Like everything else in software there are tradeoffs. You have to mostly trust
>> firmware since everything it it is doing is on behalf of the driver. So that
>> is why I'm curious if these issues are actually exploitable, or if this is
>> just preventative for the sake of being preventative.
>
> I agree that some degree of trust in vendor firmware is unavoidable,
> as its internal behavior cannot be fully controlled or inspected.
> Nevertheless, the kernel and its drivers are expected to strictly
> validate and constrain all interactions with firmware, so that any
> faulty or compromised behavior is contained within its intended scope
> (network/wireless).
>
> So, it is the driver’s responsibility to control the firmware
> interface and ensure that firmware misbehavior, whether deliberate or
> the result of an exploited firmware bug, cannot lead to such kernel
> memory corruption, which could otherwise be exploited well beyond the
> driver’s original functional domain.
>
> While this issue may be largely theoretical, it has now been reported
> and a fix is available. In this context, addressing it seems to be the
> responsible course of action.
>
> With the increasing use of AI, we may indeed see more fixes proposed
> for issues that are theoretical or unlikely to occur in practice. I
> understand the concern about avoiding an influx of low‑value commits
> and the need for some level of filtering. That said, in this particular case,
> I believe the fix is legitimate.
Sounds reasonable to me. We do actually take this approach with the Qualcomm
downstream Android driver.
So if you ack these I'll take them :)
/jeff
/jeff
^ permalink raw reply
* Re: [PATCH v3] wifi: ath12k: use lockdep_assert_in_rcu_read_lock() for RCU assertions
From: Jeff Johnson @ 2026-04-23 18:01 UTC (permalink / raw)
To: Jeff Johnson, ath12k, Yu-Hsiang Tseng
Cc: Baochen Qiang, Rameshkumar Sundaram, Kalle Valo,
Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt,
linux-wireless, linux-kernel, linux-rt-devel
In-Reply-To: <20260422180814.1938317-1-asas1asas200@gmail.com>
On Thu, 23 Apr 2026 02:08:14 +0800, Yu-Hsiang Tseng wrote:
> Two functions in ath12k assert that the caller holds an RCU read lock:
> ath12k_mac_get_arvif() and ath12k_p2p_noa_update_vdev_iter(). Both use:
>
> WARN_ON(!rcu_read_lock_any_held());
>
> On kernels using preemptible RCU (CONFIG_PREEMPT=y or CONFIG_PREEMPT_RT=y)
> without CONFIG_DEBUG_LOCK_ALLOC, this produces a false positive splat
> whenever these functions are invoked from paths that do hold the RCU
> read lock (e.g. firmware stats processing or mac80211 interface
> iteration).
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: use lockdep_assert_in_rcu_read_lock() for RCU assertions
commit: 4498664e2d5888efabb96428196a926acdaa25ed
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] wifi: ath10k: snoc: select POWER_SEQUENCING
From: Jeff Johnson @ 2026-04-23 18:00 UTC (permalink / raw)
To: Jeff Johnson, Bartosz Golaszewski, Dmitry Baryshkov
Cc: linux-wireless, ath10k, linux-kernel, Luca Weiss
In-Reply-To: <20260418-ath10k-snoc-pwrseq-v1-1-832594ba3294@oss.qualcomm.com>
On Sat, 18 Apr 2026 22:37:00 +0300, Dmitry Baryshkov wrote:
> The commit afcf3ec615c9 ("wifi: ath10k: snoc: support powering on the
> device via pwrseq") made ath10k SNOC driver use devm_pwrseq_get().
> Select the corresponding Kconfig symbol to make sure that API call is
> always available and doesn't return an error per se.
>
>
Applied, thanks!
[1/1] wifi: ath10k: snoc: select POWER_SEQUENCING
commit: c4b6ad0e14f5df942eed5ebadaff84b468bd2496
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: fix OF node refcount imbalance in WSI graph traversal
From: Jeff Johnson @ 2026-04-23 18:00 UTC (permalink / raw)
To: ath12k, Aaradhana Sahu; +Cc: linux-wireless
In-Reply-To: <20260410071300.2323603-1-aaradhana.sahu@oss.qualcomm.com>
On Fri, 10 Apr 2026 12:43:00 +0530, Aaradhana Sahu wrote:
> ath12k_core_get_wsi_info() traverses the WSI (Wired Serial Interface)
> device graph starting from dev->of_node. The current code uses
> dev->of_node directly as the local traversal pointer and calls
> of_node_put() on error.
>
> Since the driver does not own a reference to dev->of_node, dropping it
> during traversal results in the following OF refcount underflow:
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: fix OF node refcount imbalance in WSI graph traversal
commit: f3ba9e05cc7b65f41f58bb4808f6c3a8f7894bb1
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-current] wifi: ath12k: prepare REO update element only for primary link
From: Jeff Johnson @ 2026-04-23 18:00 UTC (permalink / raw)
To: Jeff Johnson, Baochen Qiang; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260210-ath12k-rxtid-double-free-v1-1-8b523fb2886d@oss.qualcomm.com>
On Tue, 10 Feb 2026 11:07:31 +0800, Baochen Qiang wrote:
> Commit [1] introduces dp->reo_cmd_update_rx_queue_list for the purpose
> of tracking all pending REO queue flush commands. The helper
> ath12k_dp_prepare_reo_update_elem() allocates an element and populates
> it with REO queue information, then add it to the list. The element would
> be helpful during clean up stage to finally unmap/free the corresponding
> REO queue buffer.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: prepare REO update element only for primary link
commit: 4a1b534177395627579c1fb9e7f9100ee88955dd
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] linux-firmware: update firmware for MT7925 WiFi device
From: Sean Wang @ 2026-04-23 17:34 UTC (permalink / raw)
To: David Ruth
Cc: jb.tsai, Leon Yen, ben, Chris Lu (陸稚泓),
dwmw2, jwboyer, linux-firmware, linux-kernel, linux-mediatek,
linux-wireless, litien.chang, Lorenzo Bianconi, Felix Fietkau,
Quan Zhou, Sean Wang
In-Reply-To: <CAKHmtrRD35fnE_TsZHzfgQ5p7=WHE1Fz8wnV0t2SGxDcgmopjQ@mail.gmail.com>
Merged
https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/1015
On Wed, Apr 22, 2026 at 5:22 PM David Ruth <druth@chromium.org> wrote:
>
> Tested-by: David Ruth <druth@chromium.org>
>
^ permalink raw reply
* Re: [PATCH v3] wifi: ath12k: use lockdep_assert_in_rcu_read_lock() for RCU assertions
From: Sebastian Andrzej Siewior @ 2026-04-23 16:14 UTC (permalink / raw)
To: Jeff Johnson
Cc: Yu-Hsiang Tseng, Jeff Johnson, ath12k, Baochen Qiang,
Rameshkumar Sundaram, Kalle Valo, Clark Williams, Steven Rostedt,
linux-wireless, linux-kernel, linux-rt-devel
In-Reply-To: <caad3b9c-2c14-4e09-b8f8-840d2ec111be@oss.qualcomm.com>
On 2026-04-23 08:24:46 [-0700], Jeff Johnson wrote:
> On 4/22/2026 11:30 PM, Sebastian Andrzej Siewior wrote:
> > On 2026-04-23 02:08:14 [+0800], Yu-Hsiang Tseng wrote:
> >> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
> >
> > This could written in plain english as in "Tested on …". Not sure what
> > this "convention" is but anyway.
>
> FYI this is a long-standing convention for the ath family of wifi drivers,
> dating back to at least ath10k:
I see. Never mind then. The previous comment read like "don't use
non-standard tags" and the change was to use a blank line.
Anyway, not my department.
Sebastian
^ permalink raw reply
* Re: [PATCH v3] wifi: ath12k: use lockdep_assert_in_rcu_read_lock() for RCU assertions
From: Jeff Johnson @ 2026-04-23 15:24 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Yu-Hsiang Tseng
Cc: Jeff Johnson, ath12k, Baochen Qiang, Rameshkumar Sundaram,
Kalle Valo, Clark Williams, Steven Rostedt, linux-wireless,
linux-kernel, linux-rt-devel
In-Reply-To: <20260423063020.NAero6Rz@linutronix.de>
On 4/22/2026 11:30 PM, Sebastian Andrzej Siewior wrote:
> On 2026-04-23 02:08:14 [+0800], Yu-Hsiang Tseng wrote:
>> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
>
> This could written in plain english as in "Tested on …". Not sure what
> this "convention" is but anyway.
FYI this is a long-standing convention for the ath family of wifi drivers,
dating back to at least ath10k:
https://wireless.docs.kernel.org/en/latest/en/users/drivers/ath10k/submittingpatches.html#tested-on-tag
https://wireless.docs.kernel.org/en/latest/en/users/drivers/ath11k/submittingpatches.html#tested-on-tag
https://wireless.docs.kernel.org/en/latest/en/users/drivers/ath12k/submittingpatches.html#tested-on-tag
>
> The change is okay.
> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Thanks for your review!
/jeff
^ permalink raw reply
* Re: [PATCH rtw-next v2 5/5] wifi: rtl8xxxu: Enable 40 MHz width by default
From: Linux regression tracking (Thorsten Leemhuis) @ 2026-04-23 13:39 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
Cc: Ping-Ke Shih, Jes Sorensen, art1310,
Linux kernel regressions list
In-Reply-To: <4f053103-adfd-4ead-acb3-ef69127a4bab@gmail.com>
On 11/20/25 15:13, Bitterblue Smith wrote:
> 40 MHz support is hidden behind the ht40_2g module parameter with
> this comment:
>
> /*
> * Some APs will negotiate HT20_40 in a noisy environment leading
> * to miserable performance. Rather than defaulting to this, only
> * enable it if explicitly requested at module load time.
> */
FYI: this patch causes a regression that was reported to bugzilla
(reporter CCed here): https://bugzilla.kernel.org/show_bug.cgi?id=221394
"""
Since kernel 6.19.0, the rtl8xxxu driver fails to maintain a connection
with the Realtek RTL8188FTV (0bda:f179) USB Wi-Fi adapter. The device
gets stuck "configuring interface" and eventually times out, effectively
disappearing from the network manager.
Regression Window:
Works perfectly on: 6.12.x (LTS) and 6.18.x (LTS and non LTS).
Broken on: 6.19.x, up through 7.0.0.
Notes:
- The device remains visible on the USB bus (lsusb still shows 0bda:f179).
- The wlan0 interface is created.
- NetworkManager attempts to associate, but authentication times out.
- Disabling USB autosuspend (usbcore.autosuspend=-1) does not resolve
the issue.
Hardware:
Bus 001 Device 002: ID 0bda:f179 Realtek Semiconductor Corp. RTL8188FTV
802.11b/g/n 1T1R 2.4G WLAN Adapter
"""
Then later:
"""
I confirmed that the Commit dbf9b7b "wifi: rtl8xxxu: Enable 40 MHz width
by default" is the cause of the regression.
I tested passing cfg80211_disable_40mhz_24ghz=1 to the cfg80211 module
on 6.19.x and 7.0, and the adapter works perfectly again.
In Windows, forcing the adapter to 20_40MHz causes it to be unable to
connect to any AP, and it only works in 20MHz mode. In Linux 6.19+, it
gets stuck configuring the interface and crashes. So this is most
probably a hardware issue.
"""
Ciao, Thorsten
> This parameter was added in commit 26f1fad29ad9 ("New driver:
> rtl8xxxu (mac80211)"). Back then rtl8xxxu only supported RTL8723AU
> and the RTL8192CU family. It's entirely possible the miserable
> performance was due to mistakes in the channel switching function,
> which were fixed in a previous patch.
>
> Delete the ht40_2g module parameter. If someone still needs to
> disable 40 MHz support, cfg80211 has the module parameter
> cfg80211_disable_40mhz_24ghz. That works too.
>
> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
> ---
> v2:
> - Add Reviewed-by.
> ---
> drivers/net/wireless/realtek/rtl8xxxu/core.c | 19 ++++---------------
> 1 file changed, 4 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c b/drivers/net/wireless/realtek/rtl8xxxu/core.c
> index a18f73aea837..c06ad064f37c 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
> @@ -20,7 +20,6 @@
> #define DRIVER_NAME "rtl8xxxu"
>
> int rtl8xxxu_debug;
> -static bool rtl8xxxu_ht40_2g;
> static bool rtl8xxxu_dma_aggregation;
> static int rtl8xxxu_dma_agg_timeout = -1;
> static int rtl8xxxu_dma_agg_pages = -1;
> @@ -45,8 +44,6 @@ MODULE_FIRMWARE("rtlwifi/rtl8192fufw.bin");
>
> module_param_named(debug, rtl8xxxu_debug, int, 0600);
> MODULE_PARM_DESC(debug, "Set debug mask");
> -module_param_named(ht40_2g, rtl8xxxu_ht40_2g, bool, 0600);
> -MODULE_PARM_DESC(ht40_2g, "Enable HT40 support on the 2.4GHz band");
> module_param_named(dma_aggregation, rtl8xxxu_dma_aggregation, bool, 0600);
> MODULE_PARM_DESC(dma_aggregation, "Enable DMA packet aggregation");
> module_param_named(dma_agg_timeout, rtl8xxxu_dma_agg_timeout, int, 0600);
> @@ -4896,8 +4893,7 @@ rtl8xxxu_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> sgi = 1;
>
> highest_rate = fls(ramask) - 1;
> - if (rtl8xxxu_ht40_2g &&
> - (sta->deflink.ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40))
> + if (sta->deflink.ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40)
> bw = RATE_INFO_BW_40;
> else
> bw = RATE_INFO_BW_20;
> @@ -7851,7 +7847,8 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
> sband->ht_cap.ht_supported = true;
> sband->ht_cap.ampdu_factor = IEEE80211_HT_MAX_AMPDU_64K;
> sband->ht_cap.ampdu_density = IEEE80211_HT_MPDU_DENSITY_16;
> - sband->ht_cap.cap = IEEE80211_HT_CAP_SGI_20 | IEEE80211_HT_CAP_SGI_40;
> + sband->ht_cap.cap = IEEE80211_HT_CAP_SGI_20 | IEEE80211_HT_CAP_SGI_40 |
> + IEEE80211_HT_CAP_SUP_WIDTH_20_40;
> memset(&sband->ht_cap.mcs, 0, sizeof(sband->ht_cap.mcs));
> sband->ht_cap.mcs.rx_mask[0] = 0xff;
> sband->ht_cap.mcs.rx_mask[4] = 0x01;
> @@ -7860,15 +7857,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
> sband->ht_cap.cap |= IEEE80211_HT_CAP_SGI_40;
> }
> sband->ht_cap.mcs.tx_params = IEEE80211_HT_MCS_TX_DEFINED;
> - /*
> - * Some APs will negotiate HT20_40 in a noisy environment leading
> - * to miserable performance. Rather than defaulting to this, only
> - * enable it if explicitly requested at module load time.
> - */
> - if (rtl8xxxu_ht40_2g) {
> - dev_info(&udev->dev, "Enabling HT_20_40 on the 2.4GHz band\n");
> - sband->ht_cap.cap |= IEEE80211_HT_CAP_SUP_WIDTH_20_40;
> - }
> +
> hw->wiphy->bands[NL80211_BAND_2GHZ] = sband;
>
> hw->wiphy->rts_threshold = 2347;
#regzbot introduced: dbf9b7b
#regzbot title: wifi: rtl8xxxu: 40 MHz mode breaks things (just like in
Windows)
#regzbot dup: https://bugzilla.kernel.org/show_bug.cgi?id=221394
^ permalink raw reply
* [PATCH] iw: Makefile: support out-of-tree builds
From: Maxin John @ 2026-04-23 11:31 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes
Enable out-of-tree builds without modifying the source tree.
Out-of-tree builds are required by build frameworks such as OpenEmbedded.
Signed-off-by: Maxin John <maxin.john@gmail.com>
---
Makefile | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index 2652fac4e6ee..fbbc3042cd37 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,8 @@
MAKEFLAGS += --no-print-directory
+SRCDIR := $(dir $(lastword $(MAKEFILE_LIST)))
+VPATH := $(SRCDIR)
+
PREFIX ?= /usr
SBINDIR ?= $(PREFIX)/sbin
MANDIR ?= $(PREFIX)/share/man
@@ -21,7 +24,11 @@ CFLAGS += -D__SANE_USERSPACE_TYPES__
CFLAGS += $(CFLAGS_EVAL)
CFLAGS += $(EXTRA_CFLAGS)
-_OBJS := $(sort $(patsubst %.c,%.o,$(wildcard *.c)))
+CPPFLAGS += -I$(SRCDIR)
+CPPFLAGS += -I.
+
+_SRCS := $(wildcard $(SRCDIR)/*.c)
+_OBJS := $(sort $(patsubst $(SRCDIR)/%.c,%.o,$(_SRCS)))
VERSION_OBJS := $(filter-out version.o, $(_OBJS))
OBJS := $(VERSION_OBJS) version.o
@@ -92,16 +99,18 @@ endif
all: $(ALL)
-version.c: version.sh $(patsubst %.o,%.c,$(VERSION_OBJS)) nl80211.h iw.h Makefile \
- $(wildcard .git/index .git/refs/tags)
+version.c: $(SRCDIR)/version.sh \
+ $(patsubst %.o,$(SRCDIR)/%.c,$(VERSION_OBJS)) \
+ $(SRCDIR)/nl80211.h $(SRCDIR)/iw.h $(SRCDIR)/Makefile \
+ $(wildcard $(SRCDIR)/.git/index $(SRCDIR)/.git/refs/tags)
@$(NQ) ' GEN ' $@
- $(Q)./version.sh $@
+ $(Q)$(SRCDIR)/version.sh $@
-nl80211-commands.inc: nl80211.h
+nl80211-commands.inc: $(SRCDIR)/nl80211.h
@$(NQ) ' GEN ' $@
- $(Q)sed 's%^\tNL80211_CMD_%%;t n;d;:n s%^\([^=]*\),.*%\t[NL80211_CMD_\1] = \"\L\1\",%;t;d' nl80211.h | grep -v "reserved" > $@
+ $(Q)sed 's%^\tNL80211_CMD_%%;t n;d;:n s%^\([^=]*\),.*%\t[NL80211_CMD_\1] = \"\L\1\",%;t;d' $(SRCDIR)/nl80211.h | grep -v "reserved" > $@
-%.o: %.c iw.h nl80211.h nl80211-commands.inc
+%.o: %.c $(SRCDIR)/iw.h $(SRCDIR)/nl80211.h nl80211-commands.inc
@$(NQ) ' CC ' $@
$(Q)$(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3] wifi: ath12k: use lockdep_assert_in_rcu_read_lock() for RCU assertions
From: Sebastian Andrzej Siewior @ 2026-04-23 6:30 UTC (permalink / raw)
To: Yu-Hsiang Tseng
Cc: Jeff Johnson, ath12k, Baochen Qiang, Rameshkumar Sundaram,
Kalle Valo, Clark Williams, Steven Rostedt, linux-wireless,
linux-kernel, linux-rt-devel
In-Reply-To: <20260422180814.1938317-1-asas1asas200@gmail.com>
On 2026-04-23 02:08:14 [+0800], Yu-Hsiang Tseng wrote:
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
This could written in plain english as in "Tested on …". Not sure what
this "convention" is but anyway.
The change is okay.
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Changes in v3:
> - Use lockdep_assert_in_rcu_read_lock() instead of RCU_LOCKDEP_WARN()
> for clearer intent and more precise semantics (suggested by
> Sebastian Andrzej Siewior)
> - Reword commit message: this affects preemptible RCU in general,
> not only PREEMPT_RT
> - Move Tested-on before the official tags per ath convention
Sebastian
^ permalink raw reply
* Re: [PATCH ath] wifi: ath12k: fix leak in some ath12k_wmi_xxx() functions
From: Greg KH @ 2026-04-23 5:01 UTC (permalink / raw)
To: Jeff Johnson; +Cc: Nicolas Escande, ath12k, linux-wireless, stable
In-Reply-To: <0456ecb5-130e-481d-97d9-e88a7aaca02d@oss.qualcomm.com>
On Wed, Apr 22, 2026 at 05:08:59PM -0700, Jeff Johnson wrote:
> On 4/22/2026 9:32 AM, Nicolas Escande wrote:
> > Some wmi functions were using plain 'return ath12k_wmi_cmd_send(...)'
> > without explicitly handling the error code. This leads to leaking the skb
> > in case of error.
> >
> > Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1
> >
> > Fixes: 66a9448b1b89 ("wifi: ath12k: implement hardware data filter")
> > Fixes: 593174170919 ("wifi: ath12k: implement WoW enable and wakeup commands")
> > Fixes: 4a3c212eee0e ("wifi: ath12k: add basic WoW functionalities")
> > Fixes: 16f474d6d49d ("wifi: ath12k: add WoW net-detect functionality")
> > Fixes: 1666108c74c4 ("wifi: ath12k: support ARP and NS offload")
> > Fixes: aab4ae566fa1 ("wifi: ath12k: support GTK rekey offload")
> > Fixes: 7af01e569529 ("wifi: ath12k: handle keepalive during WoWLAN suspend and resume")
>
> @Stable team:
>
> are you OK with one patch that fixes a bunch of places, or would you prefer a
> separate patch per fixed commit?
I do not understand, we take what is in Linus's tree, so the same rules
apply here. If the patch should be broken up for Linus's tree, that's
good for us in stable. If it is one "big" one, then you have to deal
with the fall-out if it doesn't apply to all relevant stable releases by
providing a working backport for us :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] wifi: rsi: fix kthread lifetime race between self-exit and external-stop
From: Hillf Danton @ 2026-04-23 4:14 UTC (permalink / raw)
To: Jeongjun Park
Cc: Johannes Berg, Kalle Valo, linux-wireless, linux-kernel,
syzbot+5de83f57cd8531f55596, syzkaller-bugs, stable
In-Reply-To: <20260422173846.37640-1-aha310510@gmail.com>
On Thu, 23 Apr 2026 02:38:46 +0900 Jeongjun Park wrote:
> RSI driver use both self-exit(kthread_complete_and_exit) and external-stop
> (kthread_stop) when killing a kthread. Generally, kthread_stop() is called
> first, and in this case, no particular issues occur.
>
> However, in rare instances where kthread_complete_and_exit() is called
> first and then kthread_stop() is called, a UAF occurs because the kthread
> object, which has already exited and been freed, is accessed again.
>
Alternatively the race could be described with the regular diagram to better
understand the uaf.
rsi_kill_thread() rsi_tx_scheduler_thread()
--- ---
atomic_inc(&handle->thread_done); // set the done flag
rsi_set_event(&handle->event);
do {
something;
} while (atomic_read(&common->tx_thread.thread_done) == 0);
// exit after done
kthread_complete_and_exit(&common->tx_thread.completion, 0);
kthread_stop(handle->task); // uaf
> Therefore, to prevent this with minimal modification, you must remove
> kthread_stop() and change the code to wait until the self-exit operation
> is completed.
>
> Cc: <stable@vger.kernel.org>
> Reported-by: syzbot+5de83f57cd8531f55596@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/69e5d03b.a00a0220.1bd0ca.0064.GAE@google.com/
> Fixes: 4c62764d0fc2 ("rsi: improve kernel thread handling to fix kernel panic")
> Signed-off-by: Jeongjun Park <aha310510@gmail.com>
> ---
> drivers/net/wireless/rsi/rsi_common.h | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/rsi/rsi_common.h b/drivers/net/wireless/rsi/rsi_common.h
> index 591602beeec6..3cdf9ded876d 100644
> --- a/drivers/net/wireless/rsi/rsi_common.h
> +++ b/drivers/net/wireless/rsi/rsi_common.h
> @@ -70,12 +70,11 @@ static inline int rsi_create_kthread(struct rsi_common *common,
> return 0;
> }
>
> -static inline int rsi_kill_thread(struct rsi_thread *handle)
> +static inline void rsi_kill_thread(struct rsi_thread *handle)
> {
> atomic_inc(&handle->thread_done);
> rsi_set_event(&handle->event);
> -
> - return kthread_stop(handle->task);
> + wait_for_completion(&handle->completion);
> }
>
> void rsi_mac80211_detach(struct rsi_hw *hw);
> --
>
^ permalink raw reply
* Re: [PATCH ath] wifi: ath12k: fix leak in some ath12k_wmi_xxx() functions
From: Jeff Johnson @ 2026-04-23 0:08 UTC (permalink / raw)
To: Nicolas Escande, ath12k; +Cc: linux-wireless, stable
In-Reply-To: <20260422163258.3013872-1-nico.escande@gmail.com>
On 4/22/2026 9:32 AM, Nicolas Escande wrote:
> Some wmi functions were using plain 'return ath12k_wmi_cmd_send(...)'
> without explicitly handling the error code. This leads to leaking the skb
> in case of error.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1
>
> Fixes: 66a9448b1b89 ("wifi: ath12k: implement hardware data filter")
> Fixes: 593174170919 ("wifi: ath12k: implement WoW enable and wakeup commands")
> Fixes: 4a3c212eee0e ("wifi: ath12k: add basic WoW functionalities")
> Fixes: 16f474d6d49d ("wifi: ath12k: add WoW net-detect functionality")
> Fixes: 1666108c74c4 ("wifi: ath12k: support ARP and NS offload")
> Fixes: aab4ae566fa1 ("wifi: ath12k: support GTK rekey offload")
> Fixes: 7af01e569529 ("wifi: ath12k: handle keepalive during WoWLAN suspend and resume")
@Stable team:
are you OK with one patch that fixes a bunch of places, or would you prefer a
separate patch per fixed commit?
/jeff
> Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
> ---
> drivers/net/wireless/ath/ath12k/wmi.c | 103 ++++++++++++++++++++++----
> 1 file changed, 88 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
> index 65a05a9520ff..75c87edd2a8a 100644
> --- a/drivers/net/wireless/ath/ath12k/wmi.c
> +++ b/drivers/net/wireless/ath/ath12k/wmi.c
> @@ -10251,7 +10251,7 @@ int ath12k_wmi_hw_data_filter_cmd(struct ath12k *ar, struct wmi_hw_data_filter_a
> {
> struct wmi_hw_data_filter_cmd *cmd;
> struct sk_buff *skb;
> - int len;
> + int ret, len;
>
> len = sizeof(*cmd);
> skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
> @@ -10275,7 +10275,13 @@ int ath12k_wmi_hw_data_filter_cmd(struct ath12k *ar, struct wmi_hw_data_filter_a
> "wmi hw data filter enable %d filter_bitmap 0x%x\n",
> arg->enable, arg->hw_filter_bitmap);
>
> - return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_HW_DATA_FILTER_CMDID);
> + ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_HW_DATA_FILTER_CMDID);
> + if (ret) {
> + ath12k_warn(ar->ab, "failed to send WMI_HW_DATA_FILTER_CMDID\n");
> + dev_kfree_skb(skb);
> + }
> +
> + return ret;
> }
>
> int ath12k_wmi_wow_host_wakeup_ind(struct ath12k *ar)
> @@ -10283,6 +10289,7 @@ int ath12k_wmi_wow_host_wakeup_ind(struct ath12k *ar)
> struct wmi_wow_host_wakeup_cmd *cmd;
> struct sk_buff *skb;
> size_t len;
> + int ret;
>
> len = sizeof(*cmd);
> skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
> @@ -10295,14 +10302,20 @@ int ath12k_wmi_wow_host_wakeup_ind(struct ath12k *ar)
>
> ath12k_dbg(ar->ab, ATH12K_DBG_WMI, "wmi tlv wow host wakeup ind\n");
>
> - return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_HOSTWAKEUP_FROM_SLEEP_CMDID);
> + ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_HOSTWAKEUP_FROM_SLEEP_CMDID);
> + if (ret) {
> + ath12k_warn(ar->ab, "failed to send WMI_WOW_HOSTWAKEUP_FROM_SLEEP_CMDID\n");
> + dev_kfree_skb(skb);
> + }
> +
> + return ret;
> }
>
> int ath12k_wmi_wow_enable(struct ath12k *ar)
> {
> struct wmi_wow_enable_cmd *cmd;
> struct sk_buff *skb;
> - int len;
> + int ret, len;
>
> len = sizeof(*cmd);
> skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
> @@ -10317,7 +10330,13 @@ int ath12k_wmi_wow_enable(struct ath12k *ar)
> cmd->pause_iface_config = cpu_to_le32(WOW_IFACE_PAUSE_ENABLED);
> ath12k_dbg(ar->ab, ATH12K_DBG_WMI, "wmi tlv wow enable\n");
>
> - return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ENABLE_CMDID);
> + ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ENABLE_CMDID);
> + if (ret) {
> + ath12k_warn(ar->ab, "failed to send WMI_WOW_ENABLE_CMDID\n");
> + dev_kfree_skb(skb);
> + }
> +
> + return ret;
> }
>
> int ath12k_wmi_wow_add_wakeup_event(struct ath12k *ar, u32 vdev_id,
> @@ -10327,6 +10346,7 @@ int ath12k_wmi_wow_add_wakeup_event(struct ath12k *ar, u32 vdev_id,
> struct wmi_wow_add_del_event_cmd *cmd;
> struct sk_buff *skb;
> size_t len;
> + int ret;
>
> len = sizeof(*cmd);
> skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
> @@ -10343,7 +10363,13 @@ int ath12k_wmi_wow_add_wakeup_event(struct ath12k *ar, u32 vdev_id,
> ath12k_dbg(ar->ab, ATH12K_DBG_WMI, "wmi tlv wow add wakeup event %s enable %d vdev_id %d\n",
> wow_wakeup_event(event), enable, vdev_id);
>
> - return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ENABLE_DISABLE_WAKE_EVENT_CMDID);
> + ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ENABLE_DISABLE_WAKE_EVENT_CMDID);
> + if (ret) {
> + ath12k_warn(ar->ab, "failed to send WMI_WOW_ENABLE_DISABLE_WAKE_EVENT_CMDID\n");
> + dev_kfree_skb(skb);
> + }
> +
> + return ret;
> }
>
> int ath12k_wmi_wow_add_pattern(struct ath12k *ar, u32 vdev_id, u32 pattern_id,
> @@ -10356,6 +10382,7 @@ int ath12k_wmi_wow_add_pattern(struct ath12k *ar, u32 vdev_id, u32 pattern_id,
> struct sk_buff *skb;
> void *ptr;
> size_t len;
> + int ret;
>
> len = sizeof(*cmd) +
> sizeof(*tlv) + /* array struct */
> @@ -10435,7 +10462,13 @@ int ath12k_wmi_wow_add_pattern(struct ath12k *ar, u32 vdev_id, u32 pattern_id,
> ath12k_dbg_dump(ar->ab, ATH12K_DBG_WMI, NULL, "wow bitmask: ",
> bitmap->bitmaskbuf, pattern_len);
>
> - return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ADD_WAKE_PATTERN_CMDID);
> + ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ADD_WAKE_PATTERN_CMDID);
> + if (ret) {
> + ath12k_warn(ar->ab, "failed to send WMI_WOW_ADD_WAKE_PATTERN_CMDID\n");
> + dev_kfree_skb(skb);
> + }
> +
> + return ret;
> }
>
> int ath12k_wmi_wow_del_pattern(struct ath12k *ar, u32 vdev_id, u32 pattern_id)
> @@ -10443,6 +10476,7 @@ int ath12k_wmi_wow_del_pattern(struct ath12k *ar, u32 vdev_id, u32 pattern_id)
> struct wmi_wow_del_pattern_cmd *cmd;
> struct sk_buff *skb;
> size_t len;
> + int ret;
>
> len = sizeof(*cmd);
> skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
> @@ -10459,7 +10493,13 @@ int ath12k_wmi_wow_del_pattern(struct ath12k *ar, u32 vdev_id, u32 pattern_id)
> ath12k_dbg(ar->ab, ATH12K_DBG_WMI, "wmi tlv wow del pattern vdev_id %d pattern_id %d\n",
> vdev_id, pattern_id);
>
> - return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_DEL_WAKE_PATTERN_CMDID);
> + ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_DEL_WAKE_PATTERN_CMDID);
> + if (ret) {
> + ath12k_warn(ar->ab, "failed to send WMI_WOW_DEL_WAKE_PATTERN_CMDID\n");
> + dev_kfree_skb(skb);
> + }
> +
> + return ret;
> }
>
> static struct sk_buff *
> @@ -10595,6 +10635,7 @@ int ath12k_wmi_wow_config_pno(struct ath12k *ar, u32 vdev_id,
> struct wmi_pno_scan_req_arg *pno_scan)
> {
> struct sk_buff *skb;
> + int ret;
>
> if (pno_scan->enable)
> skb = ath12k_wmi_op_gen_config_pno_start(ar, vdev_id, pno_scan);
> @@ -10604,7 +10645,13 @@ int ath12k_wmi_wow_config_pno(struct ath12k *ar, u32 vdev_id,
> if (IS_ERR_OR_NULL(skb))
> return -ENOMEM;
>
> - return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_NETWORK_LIST_OFFLOAD_CONFIG_CMDID);
> + ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_NETWORK_LIST_OFFLOAD_CONFIG_CMDID);
> + if (ret) {
> + ath12k_warn(ar->ab, "failed to send WMI_NETWORK_LIST_OFFLOAD_CONFIG_CMDID\n");
> + dev_kfree_skb(skb);
> + }
> +
> + return ret;
> }
>
> static void ath12k_wmi_fill_ns_offload(struct ath12k *ar,
> @@ -10717,6 +10764,7 @@ int ath12k_wmi_arp_ns_offload(struct ath12k *ar,
> void *buf_ptr;
> size_t len;
> u8 ns_cnt, ns_ext_tuples = 0;
> + int ret;
>
> ns_cnt = offload->ipv6_count;
>
> @@ -10752,7 +10800,13 @@ int ath12k_wmi_arp_ns_offload(struct ath12k *ar,
> if (ns_ext_tuples)
> ath12k_wmi_fill_ns_offload(ar, offload, &buf_ptr, enable, 1);
>
> - return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_SET_ARP_NS_OFFLOAD_CMDID);
> + ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_SET_ARP_NS_OFFLOAD_CMDID);
> + if (ret) {
> + ath12k_warn(ar->ab, "failed to send WMI_SET_ARP_NS_OFFLOAD_CMDID\n");
> + dev_kfree_skb(skb);
> + }
> +
> + return ret;
> }
>
> int ath12k_wmi_gtk_rekey_offload(struct ath12k *ar,
> @@ -10762,7 +10816,7 @@ int ath12k_wmi_gtk_rekey_offload(struct ath12k *ar,
> struct wmi_gtk_rekey_offload_cmd *cmd;
> struct sk_buff *skb;
> __le64 replay_ctr;
> - int len;
> + int ret, len;
>
> len = sizeof(*cmd);
> skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
> @@ -10789,7 +10843,13 @@ int ath12k_wmi_gtk_rekey_offload(struct ath12k *ar,
>
> ath12k_dbg(ar->ab, ATH12K_DBG_WMI, "offload gtk rekey vdev: %d %d\n",
> arvif->vdev_id, enable);
> - return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_GTK_OFFLOAD_CMDID);
> + ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_GTK_OFFLOAD_CMDID);
> + if (ret) {
> + ath12k_warn(ar->ab, "failed to send WMI_GTK_OFFLOAD_CMDID offload\n");
> + dev_kfree_skb(skb);
> + }
> +
> + return ret;
> }
>
> int ath12k_wmi_gtk_rekey_getinfo(struct ath12k *ar,
> @@ -10797,7 +10857,7 @@ int ath12k_wmi_gtk_rekey_getinfo(struct ath12k *ar,
> {
> struct wmi_gtk_rekey_offload_cmd *cmd;
> struct sk_buff *skb;
> - int len;
> + int ret, len;
>
> len = sizeof(*cmd);
> skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
> @@ -10811,7 +10871,13 @@ int ath12k_wmi_gtk_rekey_getinfo(struct ath12k *ar,
>
> ath12k_dbg(ar->ab, ATH12K_DBG_WMI, "get gtk rekey vdev_id: %d\n",
> arvif->vdev_id);
> - return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_GTK_OFFLOAD_CMDID);
> + ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_GTK_OFFLOAD_CMDID);
> + if (ret) {
> + ath12k_warn(ar->ab, "failed to send WMI_GTK_OFFLOAD_CMDID getinfo\n");
> + dev_kfree_skb(skb);
> + }
> +
> + return ret;
> }
>
> int ath12k_wmi_sta_keepalive(struct ath12k *ar,
> @@ -10822,6 +10888,7 @@ int ath12k_wmi_sta_keepalive(struct ath12k *ar,
> struct wmi_sta_keepalive_cmd *cmd;
> struct sk_buff *skb;
> size_t len;
> + int ret;
>
> len = sizeof(*cmd) + sizeof(*arp);
> skb = ath12k_wmi_alloc_skb(wmi->wmi_ab, len);
> @@ -10849,7 +10916,13 @@ int ath12k_wmi_sta_keepalive(struct ath12k *ar,
> "wmi sta keepalive vdev %d enabled %d method %d interval %d\n",
> arg->vdev_id, arg->enabled, arg->method, arg->interval);
>
> - return ath12k_wmi_cmd_send(wmi, skb, WMI_STA_KEEPALIVE_CMDID);
> + ret = ath12k_wmi_cmd_send(wmi, skb, WMI_STA_KEEPALIVE_CMDID);
> + if (ret) {
> + ath12k_warn(ar->ab, "failed to send WMI_STA_KEEPALIVE_CMDID\n");
> + dev_kfree_skb(skb);
> + }
> +
> + return ret;
> }
>
> int ath12k_wmi_mlo_setup(struct ath12k *ar, struct wmi_mlo_setup_arg *mlo_params)
^ permalink raw reply
* Re: [PATCH] linux-firmware: update firmware for MT7925 WiFi device
From: David Ruth @ 2026-04-22 22:19 UTC (permalink / raw)
To: jb.tsai
Cc: Leon Yen, ben, Chris Lu (陸稚泓), dwmw2,
jwboyer, linux-firmware, linux-kernel, linux-mediatek,
linux-wireless, litien.chang, Lorenzo Bianconi, Felix Fietkau,
Quan Zhou, Sean Wang
Tested-by: David Ruth <druth@chromium.org>
^ permalink raw reply
* Re: [PATCH v3 1/2] wifi: wilc1000: fix integer underflow in wilc_network_info_received()
From: Johannes Berg @ 2026-04-22 21:26 UTC (permalink / raw)
To: Tristan Madani, Ajay Singh, Claudiu Beznea; +Cc: linux-wireless, Tristan Madani
In-Reply-To: <20260421135001.343596-2-tristmd@gmail.com>
> @@ -1594,7 +1595,15 @@ void wilc_network_info_received(struct wilc *wilc, u8 *buffer, u32 length)
> if (IS_ERR(msg))
> goto out;
>
> - msg->body.net_info.frame_len = get_unaligned_le16(&buffer[6]) - 1;
> + frame_len = get_unaligned_le16(&buffer[6]);
> + if (frame_len == 0 || frame_len > length - 9) {
> + netdev_err(vif->ndev,
> + "%s: invalid frame_len %u (buffer %u)\n",
> + __func__, frame_len, length);
> + kfree(msg);
> + goto out;
> + }
>
It seems it'd be trivial to check this *before* allocating the 'msg',
and be much better that way.
johannes
^ permalink raw reply
* Re: [PATCH v3 1/2] wifi: libertas: fix OOB read from firmware pkt_ptr offset in RX path
From: Johannes Berg @ 2026-04-22 21:23 UTC (permalink / raw)
To: Tristan Madani; +Cc: libertas-dev, linux-wireless, Tristan Madani
In-Reply-To: <20260421135027.357622-2-tristmd@gmail.com>
On Tue, 2026-04-21 at 13:50 +0000, Tristan Madani wrote:
> From: Tristan Madani <tristan@talencesecurity.com>
>
> lbs_process_rxed_packet() uses the firmware-supplied pkt_ptr as an
> offset into the skb data without validating that it falls within the
> skb buffer bounds. A malicious pkt_ptr value causes out-of-bounds
> memory access when the function subsequently reads ethernet header
> fields from p_rx_pkt.
>
> Add a bounds check to ensure pkt_ptr plus the minimum packet header
> size does not exceed skb->len.
Please generally put a bit more thought into your patches.
> Fixes: e45d8e534b67 ("libertas: add support for Marvell SD8688 chip")
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
I'll also note again that I don't find any tool/LLM disclosure
improbably, nobody really cares about these rivers any more?
> p_rx_pd = (struct rxpd *) skb->data;
> +
> + if (le32_to_cpu(p_rx_pd->pkt_ptr) + sizeof(struct rxpackethdr) >
> + skb->len) {
>
At this point you don't even know yet that the skb is long enough to
access p_r x_pd->pkt_ptr *itself*, so this can't be right.
There's a length check later that checks for
if (skb->len < (ETH_HLEN + 8 + sizeof(struct rxpd))) {
which probably needs to be moved up _and_ improved, but you're not
actually checking things correctly.
How is it that whatever tool you're using to find these isn't
complaining about the fix??
johannes
^ permalink raw reply
* Re: [PATCH v3 3/6] wifi: mwifiex: fix OOB read from firmware sta_count in station list response
From: Johannes Berg @ 2026-04-22 20:09 UTC (permalink / raw)
To: Brian Norris; +Cc: Tristan Madani, linux-wireless, linux-kernel, Tristan Madani
In-Reply-To: <30b51a051a7ddec5fc5ec72a685789594c7440df.camel@sipsolutions.net>
On Wed, 2026-04-22 at 21:57 +0200, Johannes Berg wrote:
> On Wed, 2026-04-22 at 12:54 -0700, Brian Norris wrote:
> > > But regardless, I question the sanity of checking the size against the
> > > size the firmware said the whole thing was going to be, rather than
> > > checking against the actual buffer size ...
> >
> > Admittedly, I get lost in this driver sometimes...
> > ...but I think you have a very good point. AFAICT, we never do anything
> > to check the size of adapter->curr_cmd->resp_skb. We generally assume
> > it's big enough to fit 'struct host_cmd_ds_command' (since we allocate
> > it ourselves). But we don't ever go back to check these
> > dynamically-sized fields don't overflow it.
> >
>
> There are some (response) buffers where the size is checked before
> copying, but I didn't trace this back further than the SKB coming from
> pcie/sdio/usb, but I don't see any check of the firmware-advertised size
> vs. the actual skb->len.
>
In PCIe for example it looks like there are multiple length fields, and
various mwifiex_map_pci_memory() calls with different sizes
- MWIFIEX_UPLD_SIZE (2312)
- MWIFIEX_RX_DATA_BUF_SIZE (4k)
- MAX_EVENT_SIZE (2k)
If we assume strict iommu we'll get protection there (even if bounce-
buffered due to the weird sizes).
I don't see however any cross-check of the cmd_resp->size vs. the actual
size. If we had _that_ then we could rely on the cmd_resp->size later I
guess...
This all seems way too complicated anyway - should probably only ever
have whole pages allocated, for example.
johannes
^ permalink raw reply
* Re: [PATCH v3 10/15] drm/msm: Switch to generic PAS TZ APIs
From: Dmitry Baryshkov @ 2026-04-22 20:04 UTC (permalink / raw)
To: Sumit Garg
Cc: lumag, robin.clark, linux-arm-msm, devicetree, dri-devel,
freedreno, linux-media, netdev, linux-wireless, ath12k,
linux-remoteproc, andersson, konradybcio, robh, krzk+dt, conor+dt,
sean, akhilpo, abhinav.kumar, jesszhan0024, marijn.suijten,
airlied, simona, vikash.garodia, dikshita.agarwal, 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, jens.wiklander, op-tee, apurupa, skare,
harshal.dev, linux-kernel, Sumit Garg
In-Reply-To: <aeduRrAMOAW4f5TU@sumit-xelite>
On Tue, Apr 21, 2026 at 06:02:06PM +0530, Sumit Garg wrote:
> Hey Rob, Dmitry,
>
> On Fri, Mar 27, 2026 at 06:40:38PM +0530, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >
> > Switch drm/msm client drivers over to generic PAS TZ APIs. Generic PAS
> > TZ service allows to support multiple TZ implementation backends like QTEE
> > based SCM PAS service, OP-TEE based PAS service and any further future TZ
> > backend service.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > ---
> > drivers/gpu/drm/msm/Kconfig | 1 +
> > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++--
> > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 ++++++-----
> > 3 files changed, 9 insertions(+), 7 deletions(-)
> >
>
> Can I get an ack from you on this change? I expect this complete
> patch-set to land via Qcom SoC tree.
>
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 3/6] wifi: mwifiex: fix OOB read from firmware sta_count in station list response
From: Johannes Berg @ 2026-04-22 19:57 UTC (permalink / raw)
To: Brian Norris; +Cc: Tristan Madani, linux-wireless, linux-kernel, Tristan Madani
In-Reply-To: <aeknaNDFrmtuTQP1@google.com>
On Wed, 2026-04-22 at 12:54 -0700, Brian Norris wrote:
> > But regardless, I question the sanity of checking the size against the
> > size the firmware said the whole thing was going to be, rather than
> > checking against the actual buffer size ...
>
> Admittedly, I get lost in this driver sometimes...
> ...but I think you have a very good point. AFAICT, we never do anything
> to check the size of adapter->curr_cmd->resp_skb. We generally assume
> it's big enough to fit 'struct host_cmd_ds_command' (since we allocate
> it ourselves). But we don't ever go back to check these
> dynamically-sized fields don't overflow it.
>
There are some (response) buffers where the size is checked before
copying, but I didn't trace this back further than the SKB coming from
pcie/sdio/usb, but I don't see any check of the firmware-advertised size
vs. the actual skb->len.
johannes
^ permalink raw reply
* Re: [PATCH v3 3/6] wifi: mwifiex: fix OOB read from firmware sta_count in station list response
From: Brian Norris @ 2026-04-22 19:54 UTC (permalink / raw)
To: Johannes Berg
Cc: Tristan Madani, linux-wireless, linux-kernel, Tristan Madani
In-Reply-To: <2e20cb23d2d156963c2b687c4c51635e5eec2c7c.camel@sipsolutions.net>
On Wed, Apr 22, 2026 at 09:12:11PM +0200, Johannes Berg wrote:
> On Wed, 2026-04-22 at 11:26 -0700, Brian Norris wrote:
> >
> > > + u16 resp_size = le16_to_cpu(resp->size);
> > > + u16 count = le16_to_cpu(sta_list->sta_count);
> > > + u16 max_count;
> > >
> > > - for (i = 0; i < (le16_to_cpu(sta_list->sta_count)); i++) {
> > > + if (resp_size < sizeof(*resp) - sizeof(resp->params) + sizeof(*sta_list))
> > > + return -EINVAL;
> > > + max_count = (resp_size - sizeof(*resp) + sizeof(resp->params) -
> > > + sizeof(*sta_list)) / sizeof(*sta_info);
> >
> > The repeated arithmetic is a bit weird, but I'm not sure if it'd
> > actually be better to stash it in its own variable. Seems good enough I
> > suppose.
>
> I think it might be simpler if instead trying to limit:
>
> > > + count = min(count, max_count);
>
> it'd just check the needed length based on the given count, and reject
> anything above that?
That might be better.
> Also, the whole sizeof(*resp) - sizeof(resp->params) etc. shouldn't be
> there, that should just be
>
> offsetofend(resp, sta_list.tlv)
TIL. I don't recall seeing that macro before. Or at least, I didn't know
it well enough to recommend it.
> and then suddenly it becomes _way_ simpler:
>
> if (resp_size < offsetofend(resp, sta_list.tlv))
> return -EINVAL;
> if (resp_size < offsetofend(resp, sta_list.tlv) +
> sizeof(*sta_info) * le16_to_cpu(sta_.list->sta_count))
> return -EINVAL;
Looks good to me.
> But regardless, I question the sanity of checking the size against the
> size the firmware said the whole thing was going to be, rather than
> checking against the actual buffer size ...
Admittedly, I get lost in this driver sometimes...
...but I think you have a very good point. AFAICT, we never do anything
to check the size of adapter->curr_cmd->resp_skb. We generally assume
it's big enough to fit 'struct host_cmd_ds_command' (since we allocate
it ourselves). But we don't ever go back to check these
dynamically-sized fields don't overflow it.
Brian
^ permalink raw reply
* Re: [PATCH v3 3/6] wifi: mwifiex: fix OOB read from firmware sta_count in station list response
From: Johannes Berg @ 2026-04-22 19:12 UTC (permalink / raw)
To: Brian Norris, Tristan Madani; +Cc: linux-wireless, linux-kernel, Tristan Madani
In-Reply-To: <aekS72ESOUlnqGIo@google.com>
On Wed, 2026-04-22 at 11:26 -0700, Brian Norris wrote:
>
> > + u16 resp_size = le16_to_cpu(resp->size);
> > + u16 count = le16_to_cpu(sta_list->sta_count);
> > + u16 max_count;
> >
> > - for (i = 0; i < (le16_to_cpu(sta_list->sta_count)); i++) {
> > + if (resp_size < sizeof(*resp) - sizeof(resp->params) + sizeof(*sta_list))
> > + return -EINVAL;
> > + max_count = (resp_size - sizeof(*resp) + sizeof(resp->params) -
> > + sizeof(*sta_list)) / sizeof(*sta_info);
>
> The repeated arithmetic is a bit weird, but I'm not sure if it'd
> actually be better to stash it in its own variable. Seems good enough I
> suppose.
I think it might be simpler if instead trying to limit:
> > + count = min(count, max_count);
it'd just check the needed length based on the given count, and reject
anything above that?
Also, the whole sizeof(*resp) - sizeof(resp->params) etc. shouldn't be
there, that should just be
offsetofend(resp, sta_list.tlv)
and then suddenly it becomes _way_ simpler:
if (resp_size < offsetofend(resp, sta_list.tlv))
return -EINVAL;
if (resp_size < offsetofend(resp, sta_list.tlv) +
sizeof(*sta_info) * le16_to_cpu(sta_.list->sta_count))
return -EINVAL;
But regardless, I question the sanity of checking the size against the
size the firmware said the whole thing was going to be, rather than
checking against the actual buffer size ...
johannes
^ permalink raw reply
* Re: [PATCH v3 3/6] wifi: mwifiex: fix OOB read from firmware sta_count in station list response
From: Johannes Berg @ 2026-04-22 19:06 UTC (permalink / raw)
To: Tristan Madani, Brian Norris; +Cc: linux-wireless, linux-kernel, Tristan Madani
In-Reply-To: <20260421134938.331334-4-tristmd@gmail.com>
On Tue, 2026-04-21 at 13:49 +0000, Tristan Madani wrote:
> From: Tristan Madani <tristan@talencesecurity.com>
>
> The firmware-controlled sta_count (u16) is used as an unbounded loop
> counter for iterating station info entries. An inflated count drives
> reads past the response buffer into kernel heap memory.
>
> Add a check that sta_count fits within the response size.
>
> Fixes: b21783e94e20 ("mwifiex: add sta_list firmware command")
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
> ---
> Changes in v3:
> - Regenerated from wireless-next with proper git format-patch to
> produce valid index hashes (v2 had post-processed index lines).
For the record, that wasn't the problem. I _think_ the problem was that
your post-processing also skipped whitespace-only lines, which are very
relevant in patches.
johannes
^ permalink raw reply
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