* [PATCH 1/2] wifi: ath11k: fix error path leaks in some WMI WOW calls
From: Nicolas Escande @ 2026-04-24 14:48 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless
In-Reply-To: <20260424144813.1708214-1-nico.escande@gmail.com>
Fix two instances where we used to directly return the result of
ath11k_wmi_cmd_send(...). Because we did not check the return value, we
also did not free the skb in the error path.
Fixes: 79802b13a492 ("ath11k: implement WoW enable and wakeup commands")
Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
---
drivers/net/wireless/ath/ath11k/wmi.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/wmi.c b/drivers/net/wireless/ath/ath11k/wmi.c
index 40747fba3b0c..024c2aad9fb4 100644
--- a/drivers/net/wireless/ath/ath11k/wmi.c
+++ b/drivers/net/wireless/ath/ath11k/wmi.c
@@ -9332,6 +9332,7 @@ int ath11k_wmi_wow_host_wakeup_ind(struct ath11k *ar)
struct wmi_wow_host_wakeup_ind *cmd;
struct sk_buff *skb;
size_t len;
+ int ret;
len = sizeof(*cmd);
skb = ath11k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
@@ -9345,14 +9346,20 @@ int ath11k_wmi_wow_host_wakeup_ind(struct ath11k *ar)
ath11k_dbg(ar->ab, ATH11K_DBG_WMI, "tlv wow host wakeup ind\n");
- return ath11k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_HOSTWAKEUP_FROM_SLEEP_CMDID);
+ ret = ath11k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_HOSTWAKEUP_FROM_SLEEP_CMDID);
+ if (ret) {
+ ath11k_warn(ar->ab, "failed to send WMI_WOW_HOSTWAKEUP_FROM_SLEEP_CMDID\n");
+ dev_kfree_skb(skb);
+ }
+
+ return ret;
}
int ath11k_wmi_wow_enable(struct ath11k *ar)
{
struct wmi_wow_enable_cmd *cmd;
struct sk_buff *skb;
- int len;
+ int ret, len;
len = sizeof(*cmd);
skb = ath11k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
@@ -9367,7 +9374,13 @@ int ath11k_wmi_wow_enable(struct ath11k *ar)
cmd->pause_iface_config = WOW_IFACE_PAUSE_ENABLED;
ath11k_dbg(ar->ab, ATH11K_DBG_WMI, "tlv wow enable\n");
- return ath11k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ENABLE_CMDID);
+ ret = ath11k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ENABLE_CMDID);
+ if (ret) {
+ ath11k_warn(ar->ab, "failed to send WMI_WOW_ENABLE_CMDID\n");
+ dev_kfree_skb(skb);
+ }
+
+ return ret;
}
int ath11k_wmi_scan_prob_req_oui(struct ath11k *ar,
--
2.53.0
^ permalink raw reply related
* [PATCH ath 0/2] fix leaks in some WMI error path
From: Nicolas Escande @ 2026-04-24 14:48 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless
So this is similar work to what has been posted here [0] for ath12k.
When we use the pattern 'return ath11k_wmi_cmd_send(...)' without
explicitly checking the return value we fail to free the allocated skb.
This has been split into 2 patches per Jeff's guidance to hopefully
ease the backporting process.
[0] https://lore.kernel.org/linux-wireless/20260422163258.3013872-1-nico.escande@gmail.com/
Nicolas Escande (2):
wifi: ath11k: fix leak in error path of some WOW related WMI commands
wifi: ath11k: fix error path leaks in some WMI calls
drivers/net/wireless/ath/ath11k/wmi.c | 131 ++++++++++++++++++++++----
1 file changed, 112 insertions(+), 19 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH] wifi: mac80211: restore monitor injection when coexisting with another VIF
From: Óscar Alfonso Díaz @ 2026-04-24 14:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: Brite, linux-wireless, linux-kernel, stable, fjhhz1997
In-Reply-To: <9f7df38831598001ac6cd79ab4fb95b4b6e042fd.camel@sipsolutions.net>
Dropping? Do you mean it will not be taken into consideration?
I tested this patch thoroughly, and it works very well. I am well
aware that kernel developers are reluctant to accept anything created
by AI or LLMs, of course. But please, I think you should review the
approach and perhaps use the idea to implement it in the way you think
is most appropriate.
Brite has put a lot of effort and time into this, and both he and I
have spent a great deal of time testing everything. It has been tested
as he describes on kernel 7.0 and on the backported versions. Side
effects have been addressed, and everything is finally working well.
All we ask is that it be taken into consideration for adding a
solution upstream.
I already have a .deb package that works for me on the Linux
distribution I use, but it would be wonderful to provide a fix to the
whole community so it works for everyone. Please, I kindly ask that
you take some time to review it.
Thanks so much, as always. Kind regards.
--
Oscar
OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--
El vie, 24 abr 2026 a las 15:55, Johannes Berg
(<johannes@sipsolutions.net>) escribió:
>
> On Sat, 2026-04-25 at 00:08 +1200, Brite wrote:
> >
> > Earlier attempts on this thread addressed the same bug but had side
> > effects - notably full VM freezes during the airgeddon evil-twin flow,
> > reported by Óscar in the thread. This patch takes a different approach
> > and has not exhibited those side effects across the tested configurations.
> >
>
> I don't believe that all this complexity is necessary, and the code
> changes have are fairly clearly LLM-created w/o such disclosures.
> Dropping.
>
> johannes
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
From: Mark Pearson @ 2026-04-24 14:14 UTC (permalink / raw)
To: Kyle Farnung, Santiago Ruano Rincón, Jeff Johnson,
linux-wireless@vger.kernel.org, ath11k@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: koike@igalia.com, Kyle Farnung
In-Reply-To: <IA2P223MB1199153665E2AFF709BD2F52D02B2@IA2P223MB1199.NAMP223.PROD.OUTLOOK.COM>
On Thu, Apr 23, 2026, at 10:07 PM, Kyle Farnung wrote:
>>
>>
>>
>> ________________________________________
>> From: Santiago Ruano Rincón <santiagorr@riseup.net>
>> Sent: Thursday, April 23, 2026 2:14 PM
>> To: Jeff Johnson; linux-wireless@vger.kernel.org; ath11k@lists.infradead.org; linux-kernel@vger.kernel.org
>> Cc: Mark Pearson; kfarnung@outlook.com; koike@igalia.com
>> Subject: [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
>>
>> 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.
>
> Lenovo products have a pair of IDs, you'll want 21J6 [3] and 21MF [4] as
> well. I submitted a patch myself [5], but I've been investigating another
> symptom.
>
Thanks - you beat me to it.
Confirmed that you'll want to add those two.
Mark
^ permalink raw reply
* Re: [PATCH] wifi: mac80211: restore monitor injection when coexisting with another VIF
From: Johannes Berg @ 2026-04-24 13:55 UTC (permalink / raw)
To: Brite; +Cc: linux-wireless, linux-kernel, stable, fjhhz1997,
oscar.alfonso.diaz
In-Reply-To: <20260424120807.25005-1-brite.airgeddon@gmail.com>
On Sat, 2026-04-25 at 00:08 +1200, Brite wrote:
>
> Earlier attempts on this thread addressed the same bug but had side
> effects - notably full VM freezes during the airgeddon evil-twin flow,
> reported by Óscar in the thread. This patch takes a different approach
> and has not exhibited those side effects across the tested configurations.
>
I don't believe that all this complexity is necessary, and the code
changes have are fairly clearly LLM-created w/o such disclosures.
Dropping.
johannes
^ permalink raw reply
* [PATCH] wifi: mac80211: drop stray 'static' from fast-RX rx_result
From: Catherine @ 2026-04-24 13:14 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, linux-kernel, stable, Catherine
ieee80211_invoke_fast_rx() is documented as safe for parallel RX, but
its per-invocation rx_result is declared static. Concurrent callers then
share one instance and can overwrite each other's result between
ieee80211_rx_mesh_data() and the switch on res.
That can make a packet that was queued or consumed by
ieee80211_rx_mesh_data() fall through into ieee80211_rx_8023(), or make
a packet that should continue return as queued.
Make res an automatic variable so each invocation keeps its own result.
Fixes: 3468e1e0c639 ("wifi: mac80211: add mesh fast-rx support")
Cc: stable@vger.kernel.org
Signed-off-by: Catherine <enderaoelyther@gmail.com>
---
net/mac80211/rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 3e5d1c47a..8719db8f3 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -4971,7 +4971,7 @@ static bool ieee80211_invoke_fast_rx(struct ieee80211_rx_data *rx,
struct sk_buff *skb = rx->skb;
struct ieee80211_hdr *hdr = (void *)skb->data;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
- static ieee80211_rx_result res;
+ ieee80211_rx_result res;
int orig_len = skb->len;
int hdrlen = ieee80211_hdrlen(hdr->frame_control);
int snap_offs = hdrlen;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH] wifi: mac80211: restore monitor injection when coexisting with another VIF
From: Greg KH @ 2026-04-24 12:17 UTC (permalink / raw)
To: Brite
Cc: Johannes Berg, linux-wireless, linux-kernel, stable, fjhhz1997,
oscar.alfonso.diaz
In-Reply-To: <20260424120807.25005-1-brite.airgeddon@gmail.com>
On Sat, Apr 25, 2026 at 12:08:07AM +1200, Brite wrote:
> Monitor-mode packet injection is broken on drivers that implement
> real channel context ops (mt76 and others) when the
> monitor interface runs alongside another interface (typically AP).
> The monitor VIF never gets a chanctx of its own in this case, so
> ieee80211_monitor_start_xmit() finds vif.bss_conf.chanctx_conf ==
> NULL and takes the fail_rcu path, silently dropping the skb. In
> practice this breaks tooling like mdk4 and aireplay-ng on mt76
> hardware, including airgeddon's evil-twin deauth flow, which runs
> hostapd on an AP VIF and injects deauth frames from a coexisting
> monitor VIF.
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- It looks like you did not use your "real" name for the patch on either
the Signed-off-by: line, or the From: line (both of which have to
match). Please read the kernel file,
Documentation/process/submitting-patches.rst for how to do this
correctly.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* Re: [PATCH 0/9] bitfield: add FIELD_GET_SIGNED()
From: Jonathan Cameron @ 2026-04-24 12:09 UTC (permalink / raw)
To: Yury Norov
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, David Lechner,
Nuno Sá, Andy Shevchenko, Ping-Ke Shih, Richard Cochran,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Alexandre Belloni, Yury Norov, Rasmus Villemoes,
Hans de Goede, Linus Walleij, Sakari Ailus, Salah Triki,
Achim Gratz, Ben Collins, linux-kernel, linux-iio, linux-wireless,
netdev, linux-rtc
In-Reply-To: <20260417173621.368914-1-ynorov@nvidia.com>
On Fri, 17 Apr 2026 13:36:11 -0400
Yury Norov <ynorov@nvidia.com> wrote:
> The bitfields are designed in assumption that fields contain unsigned
> integer values, thus extracting the values from the field implies
> zero-extending.
>
> Some drivers need to sign-extend their fields, and currently do it like:
>
> dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
>
> It's error-prone because it relies on user to provide the correct
> index of the most significant bit.
>
> This series adds a signed version of FIELD_GET(), which is the more
> convenient and compiles (on x86_64) to just a couple instructions:
> shl and sar.
>
> Patch #1 adds FIELD_GET_SIGNED(), and the rest of the series applies it
> tree-wide.
>
Just a quick heads up that I'm beginning to assume that this series
will land in some form. If it does can we do it as an immutable branch
as I'm suggesting it gets used in some other patches in that should land
in the new cycle.
Thanks,
Jonathan
> Yury Norov (9):
> bitfield: add FIELD_GET_SIGNED()
> x86/extable: switch to using FIELD_GET_SIGNED()
> iio: intel_dc_ti_adc: switch to using
> iio: magnetometer: yas530: switch to using FIELD_GET_SIGNED()
> iio: pressure: bmp280: switch to using
> iio: mcp9600: switch to using FIELD_GET_SIGNED()
> wifi: rtw89: switch to using FIELD_GET_SIGNED()
> rtc: rv3032: switch to using FIELD_GET_SIGNED()
> ptp: switch to using FIELD_GET_SIGNED()
>
> arch/x86/include/asm/extable_fixup_types.h | 13 ++++---------
> arch/x86/mm/extable.c | 2 +-
> drivers/iio/adc/intel_dc_ti_adc.c | 4 ++--
> drivers/iio/magnetometer/yamaha-yas530.c | 12 ++++++------
> drivers/iio/pressure/bmp280-core.c | 2 +-
> drivers/iio/temperature/mcp9600.c | 2 +-
> .../net/wireless/realtek/rtw89/rtw8852a_rfk.c | 4 ++--
> .../net/wireless/realtek/rtw89/rtw8852b_common.c | 4 ++--
> .../net/wireless/realtek/rtw89/rtw8852b_rfk.c | 4 ++--
> drivers/net/wireless/realtek/rtw89/rtw8852c.c | 4 ++--
> drivers/ptp/ptp_fc3.c | 4 ++--
> drivers/rtc/rtc-rv3032.c | 2 +-
> include/linux/bitfield.h | 16 ++++++++++++++++
> 13 files changed, 42 insertions(+), 31 deletions(-)
>
^ permalink raw reply
* [PATCH] wifi: mac80211: restore monitor injection when coexisting with another VIF
From: Brite @ 2026-04-24 12:08 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, linux-kernel, stable, fjhhz1997,
oscar.alfonso.diaz, Brite
In-Reply-To: <CA+bbHrVWmSpWZ9GBVJ5vffh1qYEye=EWMq9tKA-_uzfW+raC8A@mail.gmail.com>
Monitor-mode packet injection is broken on drivers that implement
real channel context ops (mt76 and others) when the
monitor interface runs alongside another interface (typically AP).
The monitor VIF never gets a chanctx of its own in this case, so
ieee80211_monitor_start_xmit() finds vif.bss_conf.chanctx_conf ==
NULL and takes the fail_rcu path, silently dropping the skb. In
practice this breaks tooling like mdk4 and aireplay-ng on mt76
hardware, including airgeddon's evil-twin deauth flow, which runs
hostapd on an AP VIF and injects deauth frames from a coexisting
monitor VIF.
Earlier attempts on this thread addressed the same bug but had side
effects - notably full VM freezes during the airgeddon evil-twin flow,
reported by Óscar in the thread. This patch takes a different approach
and has not exhibited those side effects across the tested configurations.
Fix in two independent pieces:
1) Snapshot-based fallback. Maintain an RCU-published snapshot,
local->sole_chandef, of the single active cfg80211_chan_def
when exactly one non-transitional chanctx exists on the device,
and NULL otherwise (MCC, mid-swap, idle, allocation failure).
The snapshot is refreshed from four chanctx call sites
(new/free/assign/change) under wiphy->mtx, and consumed
lock-free by ieee80211_monitor_start_xmit() under rcu_read_lock().
The wrapper struct carries an rcu_head so stale snapshots retire
via kfree_rcu(). Fail-closed on ambiguous channel state rather
than injecting on a guess.
This restores AP+monitor coexistence injection on 2.4 GHz.
2) Surrogate sdata for the regulatory check on 5 GHz. Once the
snapshot supplies a chandef, sdata is still the monitor
interface (injection tools usually spoof the source MAC so the
earlier addr2 match does not reassign sdata). On 5 GHz channels
cfg80211_reg_can_beacon() then rejects the frame because
NL80211_IFTYPE_MONITOR cannot satisfy the regulatory requirements
for that band. In the coexistence scenario there is already a
non-monitor VIF on the same channel that is authorised to operate
there; locate a running non-monitor sdata with a matching chandef
(cfg80211_chandef_identical: band, width, both center freqs) and
use it for the regulatory check. An AP sdata satisfies the check,
so the frame goes out on the correct channel instead of being
dropped. If no such sdata exists the monitor interface is left in
place and the existing code paths apply.
Tested on mt7921u (mt76) usb with mdk4 and aireplay-ng deauth on
2.4 GHz and 5 GHz while co-running an AP on the same channel.
Tested on 6.18.12, 6.19.12 and 7.0.0-rc5
Cc: stable@vger.kernel.org
Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
Reported-by: Óscar Alfonso Díaz <oscar.alfonso.diaz@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218763
Link: https://github.com/morrownr/USB-WiFi/issues/682
Signed-off-by: Brite <brite.airgeddon@gmail.com>
---
net/mac80211/chan.c | 75 ++++++++++++++++++++++++++++++++++++++
net/mac80211/ieee80211_i.h | 17 +++++++++
net/mac80211/main.c | 7 ++++
net/mac80211/tx.c | 69 +++++++++++++++++++++++++++++++++--
4 files changed, 165 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 05f45e66999b..9efab86f57d0 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -12,6 +12,61 @@
#include "driver-ops.h"
#include "rate.h"
+/**
+ * ieee80211_update_sole_chandef - refresh the sole-chanctx snapshot
+ * @local: the mac80211 device
+ *
+ * Walk chanctx_list. If exactly one non-transitional, valid chanctx
+ * is present, kmalloc a snapshot of its chandef and RCU-publish it on
+ * local->sole_chandef. If zero or more than one chanctx are active,
+ * publish NULL (fail-closed; injection disabled for MCC or idle).
+ *
+ * The prior snapshot is freed via kfree_rcu after all RCU readers that
+ * hold a reference to it complete.
+ *
+ * Context: Must be called with wiphy->mtx held.
+ * Always process context - GFP_KERNEL is safe and appropriate.
+ */
+void ieee80211_update_sole_chandef(struct ieee80211_local *local)
+{
+ struct ieee80211_chanctx *ctx, *found = NULL;
+ struct ieee80211_sole_chandef *snap = NULL;
+ struct ieee80211_sole_chandef *old;
+
+ lockdep_assert_wiphy(local->hw.wiphy);
+
+ list_for_each_entry(ctx, &local->chanctx_list, list) {
+ /*
+ * REPLACES_OTHER: this entry is the incoming side of a
+ * swap; the outgoing context is still live. Skip it to
+ * avoid counting a context that is not yet active.
+ */
+ if (ctx->replace_state == IEEE80211_CHANCTX_REPLACES_OTHER)
+ continue;
+ if (!cfg80211_chandef_valid(&ctx->conf.def))
+ continue;
+
+ if (found) {
+ /* MCC or unexpected multi-channel state. */
+ found = NULL;
+ break;
+ }
+ found = ctx;
+ }
+
+ if (found) {
+ snap = kmalloc(sizeof(*snap), GFP_KERNEL);
+ if (snap)
+ snap->def = found->conf.def;
+ /* alloc failure -> snap == NULL -> publish NULL below */
+ }
+
+ old = rcu_replace_pointer(local->sole_chandef, snap,
+ lockdep_is_held(&local->hw.wiphy->mtx));
+ if (old)
+ kfree_rcu(old, rcu_head);
+}
+
struct ieee80211_chanctx_user_iter {
struct ieee80211_chan_req *chanreq;
struct ieee80211_sub_if_data *sdata;
@@ -729,6 +784,9 @@ static void ieee80211_change_chanctx(struct ieee80211_local *local,
const struct ieee80211_chan_req *chanreq)
{
_ieee80211_change_chanctx(local, ctx, old_ctx, chanreq, NULL);
+
+ /* Hook 4/4: channel parameters changed; refresh snapshot */
+ ieee80211_update_sole_chandef(local);
}
/* Note: if successful, the returned chanctx is reserved for the link */
@@ -902,6 +960,13 @@ ieee80211_new_chanctx(struct ieee80211_local *local,
WARN_ON_ONCE(err && !local->in_reconfig);
list_add_rcu(&ctx->list, &local->chanctx_list);
+ /*
+ * Hook 1/4: new context is now on the list.
+ * Publish a fresh snapshot so monitor injection can use this
+ * channel immediately.
+ */
+ ieee80211_update_sole_chandef(local);
+
return ctx;
}
@@ -928,6 +993,13 @@ static void ieee80211_free_chanctx(struct ieee80211_local *local,
WARN_ON_ONCE(ieee80211_chanctx_refcount(local, ctx) != 0);
list_del_rcu(&ctx->list);
+ /*
+ * Hook 2/4: context is now off the list.
+ * Republish so that a context removed during AP teardown is no
+ * longer visible to the monitor injection fallback.
+ */
+ ieee80211_update_sole_chandef(local);
+
ieee80211_del_chanctx(local, ctx, skip_idle_recalc);
kfree_rcu(ctx, rcu_head);
}
@@ -1061,6 +1133,9 @@ static int ieee80211_assign_link_chanctx(struct ieee80211_link_data *link,
ieee80211_recalc_chanctx_min_def(local, new_ctx);
}
+ /* Hook 3/4: VIF assigned or unassigned; refresh snapshot */
+ ieee80211_update_sole_chandef(local);
+
if (conf) {
new_idle = false;
} else {
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index e60b814dd89e..14c412a18868 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -40,6 +40,22 @@ extern const struct cfg80211_ops mac80211_config_ops;
struct ieee80211_local;
struct ieee80211_mesh_fast_tx;
+/**
+ * struct ieee80211_sole_chandef - kfree_rcu-capable chandef snapshot
+ *
+ * cfg80211_chan_def has no embedded rcu_head so it cannot be freed
+ * with kfree_rcu() directly. This wrapper adds one.
+ *
+ * @rcu_head: for kfree_rcu() deferred freeing
+ * @def: point-in-time copy of the active cfg80211_chan_def
+ */
+struct ieee80211_sole_chandef {
+ struct rcu_head rcu_head;
+ struct cfg80211_chan_def def;
+};
+
+/* Defined in chan.c */
+void ieee80211_update_sole_chandef(struct ieee80211_local *local);
/* Maximum number of broadcast/multicast frames to buffer when some of the
* associated stations are using power saving. */
@@ -1586,6 +1602,7 @@ struct ieee80211_local {
/* channel contexts */
struct list_head chanctx_list;
+ struct ieee80211_sole_chandef __rcu *sole_chandef;
#ifdef CONFIG_MAC80211_LEDS
struct led_trigger tx_led, rx_led, assoc_led, radio_led;
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 616f86b1a7e4..387ed2786b32 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -1745,6 +1745,13 @@ void ieee80211_free_hw(struct ieee80211_hw *hw)
kfree(local->hw.wiphy->bands[band]);
}
+ /*
+ * All interfaces are gone by this point, so every chanctx has been
+ * freed and ieee80211_update_sole_chandef() has already published
+ * NULL. Assert the invariant.
+ */
+ WARN_ON_ONCE(rcu_access_pointer(local->sole_chandef));
+
wiphy_free(local->hw.wiphy);
}
EXPORT_SYMBOL(ieee80211_free_hw);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index b90c0537d0c5..54d06cfb670c 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2398,10 +2398,73 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
rcu_dereference(tmp_sdata->vif.bss_conf.chanctx_conf);
}
- if (chanctx_conf)
+ if (chanctx_conf) {
chandef = &chanctx_conf->def;
- else
- goto fail_rcu;
+ } else {
+ /*
+ * Real-chanctx drivers (e.g. mt76) do not assign a chanctx to
+ * the monitor VIF, so vif.bss_conf.chanctx_conf is NULL here.
+ * Fall back to the sole_chandef snapshot maintained by
+ * ieee80211_update_sole_chandef(). NULL means MCC or no active
+ * channel - drop the frame.
+ *
+ * The snapshot is valid for this whole function: it is freed
+ * via kfree_rcu() after a full grace period, and we are inside
+ * rcu_read_lock() throughout.
+ */
+ struct ieee80211_sole_chandef *sole =
+ rcu_dereference(local->sole_chandef);
+ chandef = sole ? &sole->def : NULL;
+ if (!chandef)
+ goto fail_rcu;
+ }
+
+ /*
+ * If sdata is still the monitor interface, addr2 did not match any
+ * local non-monitor interface - the normal case for injection tools
+ * (mdk4, aireplay-ng) that spoof the source MAC.
+ *
+ * On 5 GHz, cfg80211_reg_can_beacon() below commonly rejects
+ * NL80211_IFTYPE_MONITOR because a monitor interface cannot
+ * satisfy the regulatory requirements for the band (NO_IR on
+ * many channels; radar-detection responsibility on DFS channels).
+ * Pick a running non-monitor sdata operating on the same channel
+ * (identical band, width and both center frequencies) and use
+ * that for the check: an AP sdata is already authorised for the
+ * channel, so the check passes and the frame goes out on the
+ * correct channel instead of being dropped.
+ *
+ * If no such sdata exists, leave sdata as the monitor interface and
+ * let the existing code paths handle the MONITOR case (CHAN_CAN_MONITOR
+ * branch, or fail_rcu if regulatory does not permit).
+ */
+ if (sdata->vif.type == NL80211_IFTYPE_MONITOR) {
+ struct ieee80211_sub_if_data *picked = NULL;
+
+ list_for_each_entry_rcu(tmp_sdata, &local->interfaces, list) {
+ struct ieee80211_chanctx_conf *tx_conf;
+
+ if (!ieee80211_sdata_running(tmp_sdata))
+ continue;
+ if (tmp_sdata->vif.type == NL80211_IFTYPE_MONITOR ||
+ tmp_sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ continue;
+
+ tx_conf = rcu_dereference(tmp_sdata->vif.bss_conf.chanctx_conf);
+
+ if (!tx_conf)
+ continue;
+
+ if (!cfg80211_chandef_identical(&tx_conf->def, chandef))
+ continue;
+
+ picked = tmp_sdata;
+ break;
+ }
+
+ if (picked)
+ sdata = picked;
+ }
/*
* If driver/HW supports IEEE80211_CHAN_CAN_MONITOR we still
--
2.53.0
^ permalink raw reply related
* [PATCH v4] wifi: ath11k: fix peer resolution on rx path when peer_id=0
From: Matthew Leach @ 2026-04-24 9:50 UTC (permalink / raw)
To: Jeff Johnson
Cc: Baochen Qiang, Rameshkumar Sundaram, linux-wireless, ath11k,
linux-kernel, kernel, Matthew Leach
It has been observed that on certain chipsets a peer can be assigned
peer_id=0. For reception of non-aggregated MPDUs this is fine as
ath11k_dp_rx_h_find_peer() has a fallback case where it locates the peer
based upon the source MAC address. On an aggregated link, the mpdu_start
header is only populated by hardware on the first sub-MSDU. This causes
the peer resolution to be skipped for the subsequent MSDUs and the
encryption type of these frames to be set to an incorrect value,
resulting in these MSDUs being dropped by ieee80211.
ath11k_pci 0000:03:00.0: data rx skb 000000002f4b704d len 1534 peer xx:xx:xx:xx:xx:xx 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 1 last_msdu 0
ath11k_pci 0000:03:00.0: data rx skb 0000000038acd580 len 1534 peer (null) 0 ucast sn 3063 he160 rate_idx 9 vht_nss 2 freq 5240 band 1 flag 0x40d00 fcs-err 0 mic-err 0 amsdu-more 0 peer_id 0 first_msdu 0 last_msdu 1
Remove the null peer_id checks in ath11k_dp_rx_h_find_peer() and
ath11k_hal_rx_parse_mon_status_tlv(), allowing peers with an assigned ID
of 0 to be resolved.
Fixes: 2167fa606c0f ("ath11k: Add support for RX decapsulation offload")
Tested-on: QCA2066 hw2.1 PCI WLAN.HSP.1.1-03926.13-QCAHSPSWPL_V2_SILICONZ_CE-2.52297.9
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
---
Changes in v4:
- Prefix subsystem with 'wifi:'.
- Added the 'Tested-by' and 'Fixes' trailers.
- Link to v3: https://patch.msgid.link/20260417-ath11k-null-peerid-workaround-v3-1-d04302284486@collabora.com
Changes in v3:
- Clarified that the mpdu_start header isn't populated by the h/w for
all sub-MSDUs in the commit message.
- Fix second null-peer check in ath11k_hal_rx_parse_mon_status_tlv().
- Link to v2: https://patch.msgid.link/20260415-ath11k-null-peerid-workaround-v2-1-2abae3bbac16@collabora.com
Changes in v2:
- Since peer_id=0 is a valid condition on some chips, remove the guard
that prevented the peer lookup.
- Link to v1: https://patch.msgid.link/20260326-ath11k-null-peerid-workaround-v1-1-0c2fd53202f8@collabora.com
To: Jeff Johnson <jjohnson@kernel.org>
Cc: linux-wireless@vger.kernel.org
Cc: ath11k@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/wireless/ath/ath11k/dp_rx.c | 3 +--
drivers/net/wireless/ath/ath11k/hal_rx.c | 5 +----
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
index 49d959b2e148..ff2c78a4e5f3 100644
--- a/drivers/net/wireless/ath/ath11k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
@@ -2215,8 +2215,7 @@ ath11k_dp_rx_h_find_peer(struct ath11k_base *ab, struct sk_buff *msdu)
lockdep_assert_held(&ab->base_lock);
- if (rxcb->peer_id)
- peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
+ peer = ath11k_peer_find_by_id(ab, rxcb->peer_id);
if (peer)
return peer;
diff --git a/drivers/net/wireless/ath/ath11k/hal_rx.c b/drivers/net/wireless/ath/ath11k/hal_rx.c
index 753bd93f0212..51e0840bc0d1 100644
--- a/drivers/net/wireless/ath/ath11k/hal_rx.c
+++ b/drivers/net/wireless/ath/ath11k/hal_rx.c
@@ -1467,11 +1467,8 @@ ath11k_hal_rx_parse_mon_status_tlv(struct ath11k_base *ab,
case HAL_RX_MPDU_START: {
struct hal_rx_mpdu_info *mpdu_info =
(struct hal_rx_mpdu_info *)tlv_data;
- u16 peer_id;
- peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
- if (peer_id)
- ppdu_info->peer_id = peer_id;
+ ppdu_info->peer_id = ath11k_hal_rx_mpduinfo_get_peerid(ab, mpdu_info);
break;
}
case HAL_RXPCU_PPDU_END_INFO: {
---
base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
change-id: 20260326-ath11k-null-peerid-workaround-625a129781b1
Best regards,
--
Matt
^ permalink raw reply related
* Re: [PATCH] NFC: trf7970a: Ignore antenna noise when checking for RF field
From: Krzysztof Kozlowski @ 2026-04-24 9:39 UTC (permalink / raw)
To: Paul Geurts, mgreer, sameo, linux-wireless, netdev, linux-kernel
Cc: martijn.de.gouw
In-Reply-To: <20260422100930.581237-1-paul.geurts@prodrive-technologies.com>
On 22/04/2026 12:09, Paul Geurts wrote:
> The main channel Received Signal Strength Indicator (RSSI) measurement
> is used to determine whether an RF field is present or not. RSSI != 0
> is interpreted as an RF Field is present. This does not take RF noise
> and measurement inaccuracy into account, and results in false positives
> in the field.
>
> Define a noise level and make sure the RF field is only interpreted as
> present when the RSSI is above the noise level.
>
> Fixes: 851ee3cbf850 ("NFC: trf7970a: Don't turn on RF if there is already an RF field")
> Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
> ---
> drivers/nfc/trf7970a.c | 3 ++-
Looks reasonable so a poor man's review:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [bug report] wifi: ath12k: Add support for reading variant from ACPI to download board data file
From: Dan Carpenter @ 2026-04-24 8:59 UTC (permalink / raw)
To: Lingbo Kong; +Cc: linux-wireless, ath12k
Hello Lingbo Kong,
Commit 0a43c3a520e9 ("wifi: ath12k: Add support for reading variant
from ACPI to download board data file") from Jan 13, 2025
(linux-next), leads to the following Smatch static checker warning:
drivers/net/wireless/ath/ath12k/acpi.c:395 ath12k_acpi_start()
warn: set error code if 'ab->acpi.bdf_string[0] == 0'
drivers/net/wireless/ath/ath12k/acpi.c
351 int ath12k_acpi_start(struct ath12k_base *ab)
352 {
353 acpi_status status;
354 int ret;
355
356 ab->acpi.acpi_tas_enable = false;
357 ab->acpi.acpi_disable_11be = false;
358 ab->acpi.acpi_disable_rfkill = false;
359 ab->acpi.acpi_bios_sar_enable = false;
360 ab->acpi.acpi_cca_enable = false;
361 ab->acpi.acpi_band_edge_enable = false;
362 ab->acpi.acpi_enable_bdf = false;
363 ab->acpi.bdf_string[0] = '\0';
364
365 if (!ab->hw_params->acpi_guid)
366 /* not supported with this hardware */
367 return 0;
368
369 ret = ath12k_acpi_dsm_get_data(ab, ATH12K_ACPI_DSM_FUNC_SUPPORT_FUNCS);
370 if (ret) {
371 ath12k_dbg(ab, ATH12K_DBG_BOOT, "failed to get ACPI DSM data: %d\n", ret);
372 return ret;
373 }
374
375 if (ATH12K_ACPI_FUNC_BIT_VALID(ab->acpi, ATH12K_ACPI_FUNC_BIT_DISABLE_FLAG)) {
376 ret = ath12k_acpi_dsm_get_data(ab, ATH12K_ACPI_DSM_FUNC_DISABLE_FLAG);
377 if (ret) {
378 ath12k_warn(ab, "failed to get ACPI DISABLE FLAG: %d\n", ret);
379 return ret;
380 }
381
382 if (ATH12K_ACPI_CHEK_BIT_VALID(ab->acpi,
383 ATH12K_ACPI_DSM_DISABLE_11BE_BIT))
384 ab->acpi.acpi_disable_11be = true;
385
386 if (!ATH12K_ACPI_CHEK_BIT_VALID(ab->acpi,
387 ATH12K_ACPI_DSM_DISABLE_RFKILL_BIT))
388 ab->acpi.acpi_disable_rfkill = true;
389 }
390
391 if (ATH12K_ACPI_FUNC_BIT_VALID(ab->acpi, ATH12K_ACPI_FUNC_BIT_BDF_EXT)) {
392 ret = ath12k_acpi_dsm_get_data(ab, ATH12K_ACPI_DSM_FUNC_BDF_EXT);
393 if (ret || ab->acpi.bdf_string[0] == '\0') {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Should we set the error code for an empty string?
394 ath12k_warn(ab, "failed to get ACPI BDF EXT: %d\n", ret);
--> 395 return ret;
396 }
397
398 ab->acpi.acpi_enable_bdf = true;
399 }
400
401 if (ATH12K_ACPI_FUNC_BIT_VALID(ab->acpi, ATH12K_ACPI_FUNC_BIT_TAS_CFG)) {
402 ret = ath12k_acpi_dsm_get_data(ab, ATH12K_ACPI_DSM_FUNC_TAS_CFG);
403 if (ret) {
404 ath12k_warn(ab, "failed to get ACPI TAS config table: %d\n", ret);
This email is a free service from the Smatch-CI project [smatch.sf.net].
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] ssb: fix reference leaks on failed flash device registration
From: Guangshuo Li @ 2026-04-24 8:47 UTC (permalink / raw)
To: Michael Buesch, Rafał Miłecki, John W. Linville,
linux-wireless, linux-kernel
Cc: stable
In-Reply-To: <20260415183002.3752935-1-lgs201920130244@gmail.com>
Hi,
Please disregard this patch.
On Thu, 16 Apr 2026 at 02:30, Guangshuo Li <lgs201920130244@gmail.com> wrote:
>
> When platform_device_register() fails in ssb_devices_register(), the
> embedded struct device in ssb_pflash_dev or ssb_sflash_dev has already
> been initialized by device_initialize(), but the failure paths only
> report the error and do not drop the device reference for the current
> platform device:
>
> ssb_devices_register()
> -> platform_device_register(&ssb_pflash_dev)
> -> device_initialize(&ssb_pflash_dev.dev)
> -> setup_pdev_dma_masks(&ssb_pflash_dev)
> -> platform_device_add(&ssb_pflash_dev)
>
> ssb_devices_register()
> -> platform_device_register(&ssb_sflash_dev)
> -> device_initialize(&ssb_sflash_dev.dev)
> -> setup_pdev_dma_masks(&ssb_sflash_dev)
> -> platform_device_add(&ssb_sflash_dev)
>
> This leads to reference leaks when platform_device_register() fails.
> Fix this by calling platform_device_put() after reporting the error.
>
> The issue was identified by a static analysis tool I developed and
> confirmed by manual review.
>
> Fixes: c7a4a9e3880cc ("ssb: register platform device for parallel flash")
> Fixes: 7b5d6043de312 ("ssb: register serial flash as platform device")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/ssb/main.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
> index b2d339eb57d5..5cdf612a8516 100644
> --- a/drivers/ssb/main.c
> +++ b/drivers/ssb/main.c
> @@ -535,16 +535,20 @@ static int ssb_devices_register(struct ssb_bus *bus)
> #ifdef CONFIG_SSB_DRIVER_MIPS
> if (bus->mipscore.pflash.present) {
> err = platform_device_register(&ssb_pflash_dev);
> - if (err)
> + if (err) {
> pr_err("Error registering parallel flash\n");
> + platform_device_put(&ssb_pflash_dev);
> + }
> }
> #endif
>
> #ifdef CONFIG_SSB_SFLASH
> if (bus->mipscore.sflash.present) {
> err = platform_device_register(&ssb_sflash_dev);
> - if (err)
> + if (err) {
> pr_err("Error registering serial flash\n");
> + platform_device_put(&ssb_sflash_dev);
> + }
> }
> #endif
>
> --
> 2.43.0
>
After re-checking it, ssb_pflash_dev and ssb_sflash_dev are global
platform_device objects and they do not provide dev.release callbacks.
Therefore calling platform_device_put() on the platform_device_register()
failure paths is not appropriate here and can trigger the missing release
callback warning.
This falls into the same static platform_device pattern pointed out in
the other reviews, so I will drop this patch.
Sorry for the noise.
Best regards,
Guangshuo Li
^ permalink raw reply
* Re: mac80211 HT/VHT MCS check change causing Wi-Fi speed drop (~20 Mbps cap) on iwlwifi
From: Johannes Berg @ 2026-04-24 8:41 UTC (permalink / raw)
To: Jayden Fowler, linux-wireless
In-Reply-To: <db830769-2681-48ea-a8aa-f4cf8f3dfa4d@gmail.com>
On Fri, 2026-04-24 at 04:28 -0400, Jayden Fowler wrote:
> Hello,
>
> I think I’ve run into a regression in mac80211 that affects Wi-Fi speeds
> on Intel iwlwifi (and possibly some Realtek cards too).
>
> After testing a bunch of kernels, I noticed something pretty consistent:
>
> Kernels with this commit Wi-Fi gets stuck around ~20 Mbps max
> Kernels without it (or after removing a small part of it) speeds go back
> to normal (hundreds of Mbps as expected)
>
> The commit I bisected it to is:
>
> 574faa0e936d12718e2cadad11ce1e184d9e5a32
> "wifi: mac80211: add HT and VHT basic set verification"
>
> The issue seems to come from the new HT/VHT MCS verification logic. When
> it runs, it sometimes decides the AP’s advertised rates are
> “unsupported” and then forces a downgrade in connection mode/bandwidth.
>
> That downgrade looks like it’s what causes the big speed drop.
Yeah, there are too many AP bugs ...
https://patchwork.kernel.org/project/linux-wireless/patch/99Mv9QEceyPrQhSP52MtAVmz0_kWJmzqotJjD9YW6LGLqk-AZloAueUyHCURilFkuqOh6Ecv8i2KKdSE1ujP3AnbU5QEouVisT1w_V3xdfc=@r26.me/
johannes
^ permalink raw reply
* mac80211 HT/VHT MCS check change causing Wi-Fi speed drop (~20 Mbps cap) on iwlwifi
From: Jayden Fowler @ 2026-04-24 8:28 UTC (permalink / raw)
To: linux-wireless
Hello,
I think I’ve run into a regression in mac80211 that affects Wi-Fi speeds
on Intel iwlwifi (and possibly some Realtek cards too).
After testing a bunch of kernels, I noticed something pretty consistent:
Kernels with this commit Wi-Fi gets stuck around ~20 Mbps max
Kernels without it (or after removing a small part of it) speeds go back
to normal (hundreds of Mbps as expected)
The commit I bisected it to is:
574faa0e936d12718e2cadad11ce1e184d9e5a32
"wifi: mac80211: add HT and VHT basic set verification"
The issue seems to come from the new HT/VHT MCS verification logic. When
it runs, it sometimes decides the AP’s advertised rates are
“unsupported” and then forces a downgrade in connection mode/bandwidth.
That downgrade looks like it’s what causes the big speed drop.
When I remove this from `net/mac80211/mlme.c`, Wi-Fi goes back to normal
speeds:
if (conn->mode >= IEEE80211_CONN_MODE_HT &&
!ieee80211_verify_sta_ht_mcs_support(sdata, sband,
elems->ht_operation)) {
conn->mode = IEEE80211_CONN_MODE_LEGACY;
conn->bw_limit = IEEE80211_CONN_BW_LIMIT_20;
link_id_info(sdata, link_id,
"required MCSes not supported, disabling HT\n");
}
if (conn->mode >= IEEE80211_CONN_MODE_VHT &&
!ieee80211_verify_sta_vht_mcs_support(sdata, link_id, sband,
elems->vht_operation)) {
conn->mode = IEEE80211_CONN_MODE_HT;
conn->bw_limit = min_t(enum ieee80211_conn_bw_limit,
conn->bw_limit,
IEEE80211_CONN_BW_LIMIT_40);
link_id_info(sdata, link_id,
"required MCSes not supported, disabling VHT\n");
}
This is my wifi card i'm testing on Network controller: Intel
Corporation Dual Band Wireless-AC 3168NGW [Stone Peak] (rev 10)
Thanks, Jayden Fowler.
^ permalink raw reply
* [PATCH rtw-next 3/3] wifi: rtw89: disable CSI STBC for VHT 160MHz
From: Ping-Ke Shih @ 2026-04-24 7:25 UTC (permalink / raw)
To: linux-wireless; +Cc: dian_syuan0116
In-Reply-To: <20260424072552.59220-1-pkshih@realtek.com>
From: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Fix interoperability problem where CSI feedback with STBC enabled at
VHT 160MHz BW cannot be properly decoded by certain APs, causing CSI
reports to be rejected. This problem is specific to Wi-Fi 7 chips,
as Wi-Fi 6 defaults to 20MHz CSI BW. Therefore, disable STBC encoding
for CSI transmission in VHT 160MHz mode to ensure CSI feedback is
accepted by these APs and maintain smooth throughput.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/mac_be.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/mac_be.c b/drivers/net/wireless/realtek/rtw89/mac_be.c
index 39a28fd27412..4d61313a2a84 100644
--- a/drivers/net/wireless/realtek/rtw89/mac_be.c
+++ b/drivers/net/wireless/realtek/rtw89/mac_be.c
@@ -2750,6 +2750,10 @@ static int rtw89_mac_set_csi_para_reg_be(struct rtw89_dev *rtwdev,
sound_dim = min(sound_dim, t);
}
+ /* Disable stbc_en in VHT 160MHz to avoid IOT issues with certain APs */
+ if (link_sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ)
+ stbc_en = 0;
+
nc = min(nc, sound_dim);
nr = min(nr, sound_dim);
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 2/3] wifi: rtw89: disable HTC field in AP mode
From: Ping-Ke Shih @ 2026-04-24 7:25 UTC (permalink / raw)
To: linux-wireless; +Cc: dian_syuan0116
In-Reply-To: <20260424072552.59220-1-pkshih@realtek.com>
From: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Disable HE QoS HTC field when operating in AP mode to resolve
interoperability issues with some stations.
Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c
index 70feab97dccb..ca3f8e356434 100644
--- a/drivers/net/wireless/realtek/rtw89/core.c
+++ b/drivers/net/wireless/realtek/rtw89/core.c
@@ -931,6 +931,7 @@ __rtw89_core_tx_check_he_qos_htc(struct rtw89_dev *rtwdev,
enum btc_pkt_type pkt_type)
{
struct rtw89_sta_link *rtwsta_link = tx_req->rtwsta_link;
+ struct ieee80211_vif *vif = tx_req->vif;
struct sk_buff *skb = tx_req->skb;
struct ieee80211_hdr *hdr = (void *)skb->data;
struct ieee80211_link_sta *link_sta;
@@ -962,6 +963,9 @@ __rtw89_core_tx_check_he_qos_htc(struct rtw89_dev *rtwdev,
if (rtwsta_link && rtwsta_link->ra_report.might_fallback_legacy)
return false;
+ if (vif->type == NL80211_IFTYPE_AP)
+ return false;
+
return true;
}
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 1/3] wifi: rtw89: pci: no need to wait CLK ready for RTL8922DE
From: Ping-Ke Shih @ 2026-04-24 7:25 UTC (permalink / raw)
To: linux-wireless; +Cc: dian_syuan0116
In-Reply-To: <20260424072552.59220-1-pkshih@realtek.com>
The bit is to wait for CLK ready when entering PCIE L1SS. However, a
certain host might not enable CLK for a situation, causing device state
stuck and trigger PCIE SER. Unset this bit as default like earlier chips.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw89/pci.h | 2 ++
drivers/net/wireless/realtek/rtw89/pci_be.c | 12 ++++++++++++
2 files changed, 14 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw89/pci.h b/drivers/net/wireless/realtek/rtw89/pci.h
index e7da37b9da7d..d0d1e2b99698 100644
--- a/drivers/net/wireless/realtek/rtw89/pci.h
+++ b/drivers/net/wireless/realtek/rtw89/pci.h
@@ -33,6 +33,8 @@
#define RAC_REG_REV2 0x1B
#define BAC_CMU_EN_DLY_MASK GENMASK(15, 12)
#define PCIE_DPHY_DLY_25US 0x1
+#define RAC_ANA14 0x14
+#define EIEOS_L1SS_WAIT_CLKRDY BIT(2)
#define RAC_ANA19 0x19
#define B_PCIE_BIT_RD_SEL BIT(2)
#define RAC_REG_FLD_0 0x1D
diff --git a/drivers/net/wireless/realtek/rtw89/pci_be.c b/drivers/net/wireless/realtek/rtw89/pci_be.c
index dfffec1ff3c7..473d491eb3f4 100644
--- a/drivers/net/wireless/realtek/rtw89/pci_be.c
+++ b/drivers/net/wireless/realtek/rtw89/pci_be.c
@@ -83,6 +83,17 @@ static void _patch_pcie_power_wake_be(struct rtw89_dev *rtwdev, bool power_up)
rtw89_write32_clr(rtwdev, R_BE_HCI_OPT_CTRL, BIT_WAKE_CTRL_V1);
}
+static void _patch_pre_init_be(struct rtw89_dev *rtwdev)
+{
+ struct rtw89_hal *hal = &rtwdev->hal;
+
+ if (!(rtwdev->chip->chip_id == RTL8922D && hal->cid == RTL8922D_CID7090))
+ return;
+
+ rtw89_write16_clr(rtwdev, R_RAC_DIRECT_OFFSET_BE_LANE0_G2 +
+ RAC_ANA14 * RAC_MULT, EIEOS_L1SS_WAIT_CLKRDY);
+}
+
static void rtw89_pci_set_io_rcy_be(struct rtw89_dev *rtwdev)
{
const struct rtw89_pci_info *info = rtwdev->pci_info;
@@ -475,6 +486,7 @@ static int rtw89_pci_ops_mac_pre_init_be(struct rtw89_dev *rtwdev)
rtw89_pci_set_io_rcy_be(rtwdev);
_patch_pcie_power_wake_be(rtwdev, true);
+ _patch_pre_init_be(rtwdev);
rtw89_pci_ctrl_wpdma_pcie_be(rtwdev, false);
rtw89_pci_ctrl_trxdma_pcie_be(rtwdev, MAC_AX_PCIE_DISABLE,
MAC_AX_PCIE_DISABLE, MAC_AX_PCIE_DISABLE);
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 0/3] wifi: rtw89: update hardware settings to fix interoperability
From: Ping-Ke Shih @ 2026-04-24 7:25 UTC (permalink / raw)
To: linux-wireless; +Cc: dian_syuan0116
First is to clear CLK ready bit to prevent unstable for certain platforms.
The second one is to fix low throughput problem in AP mode. The last one
is related beamforming that CSI can't reply on 160MHz bandwidth for WiFi
6 chips.
Dian-Syuan Yang (2):
wifi: rtw89: disable HTC field in AP mode
wifi: rtw89: disable CSI STBC for VHT 160MHz
Ping-Ke Shih (1):
wifi: rtw89: pci: no need to wait CLK ready for RTL8922DE
drivers/net/wireless/realtek/rtw89/core.c | 4 ++++
drivers/net/wireless/realtek/rtw89/mac_be.c | 4 ++++
drivers/net/wireless/realtek/rtw89/pci.h | 2 ++
drivers/net/wireless/realtek/rtw89/pci_be.c | 12 ++++++++++++
4 files changed, 22 insertions(+)
base-commit: fa489a77e3267e05df95db96ba98e141ec07cbd9
--
2.25.1
^ permalink raw reply
* [PATCH] wifi: carl9170: fix stack-out-of-bounds in carl9170_cmd_callback
From: Deepanshu Kartikey @ 2026-04-24 3:17 UTC (permalink / raw)
To: chunkeey
Cc: linville, linux-wireless, linux-kernel, Deepanshu Kartikey,
syzbot+5c1ca6ccaa1215781cac
carl9170_cmd_callback() does not return after calling
carl9170_restart() when an invalid command response is detected.
This causes a fall-through into the memcpy block below, where
ar->readbuf is written with a device-controlled length (len - 4)
instead of the expected ar->readlen bytes.
A malicious or fuzzing USB device can send an oversized response
(e.g. 60 bytes) causing a stack-out-of-bounds write into ar->readbuf,
as detected by KASAN.
Fix this by adding a return after carl9170_restart() to match the
original intent stated in the comment ("Do not complete"). Also cap
the memcpy with min_t() as defense-in-depth to prevent overflow even
if the control flow changes in future.
The bug has been present since the initial driver submission in 2010.
Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend")
Reported-by: syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac
Tested-by: syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
drivers/net/wireless/ath/carl9170/rx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/carl9170/rx.c b/drivers/net/wireless/ath/carl9170/rx.c
index 6833430130f4..6a5923495a01 100644
--- a/drivers/net/wireless/ath/carl9170/rx.c
+++ b/drivers/net/wireless/ath/carl9170/rx.c
@@ -145,12 +145,14 @@ static void carl9170_cmd_callback(struct ar9170 *ar, u32 len, void *buffer)
* and we get a stack trace from there.
*/
carl9170_restart(ar, CARL9170_RR_INVALID_RSP);
+ return;
}
spin_lock(&ar->cmd_lock);
if (ar->readbuf) {
if (len >= 4)
- memcpy(ar->readbuf, buffer + 4, len - 4);
+ memcpy(ar->readbuf, buffer + 4,
+ min_t(u32, len - 4, ar->readlen));
ar->readbuf = NULL;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
From: Kyle Farnung @ 2026-04-24 2:07 UTC (permalink / raw)
To: Santiago Ruano Rincón, Jeff Johnson,
linux-wireless@vger.kernel.org, ath11k@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Mark Pearson, koike@igalia.com, Kyle Farnung
In-Reply-To: <20260423211458.458911-1-santiagorr@riseup.net>
>
>
>
> ________________________________________
> From: Santiago Ruano Rincón <santiagorr@riseup.net>
> Sent: Thursday, April 23, 2026 2:14 PM
> To: Jeff Johnson; linux-wireless@vger.kernel.org; ath11k@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: Mark Pearson; kfarnung@outlook.com; koike@igalia.com
> Subject: [PATCH] wifi: ath11k: Add two missing Lenovo IDs to the quirk table
>
> 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.
Lenovo products have a pair of IDs, you'll want 21J6 [3] and 21MF [4] as
well. I submitted a patch myself [5], but I've been investigating another
symptom.
I have the same "wake on power removed" issue, but I have another issue
that's more annoying where the wifi just dies randomly. I only have the
wake issue when power is disconnected, not when power is connected again.
I mostly leave my device connected, so I only realized the behavior while
doing the regression testing requested in the other patch.
[3] https://pcsupport.lenovo.com/jm/en/products/laptops-and-netbooks/thinkpad-p-series-laptops/thinkpad-p14s-gen-3-type-21j5-21j6/21j5
[4] https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-p-series-laptops/thinkpad-p14s-gen-5-type-21me-21mf/21me/21me000pge
[5] https://lore.kernel.org/all/ba4d194b-6d31-4d8a-a6a6-da116f9f56ac@oss.qualcomm.com/
>
> 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
* [syzbot] [wireless?] [usb?] KASAN: stack-out-of-bounds Write in carl9170_handle_command_response
From: syzbot @ 2026-04-24 0:23 UTC (permalink / raw)
To: chunkeey, linux-kernel, linux-usb, linux-wireless, netdev,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 2e6803928193 Merge tag 'tracefs-v7.1-2' of git://git.kerne..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=113342ce580000
kernel config: https://syzkaller.appspot.com/x/.config?x=37c3a614a8bc8d27
dashboard link: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12acb1ba580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16acb1ba580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/592131f484c3/disk-2e680392.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2ca791aa3d9c/vmlinux-2e680392.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3aaca7d6d8d9/bzImage-2e680392.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com
usb 4-1: received invalid command response:got 60, instead of 0
usb 4-1: restart device (9)
usb 4-1: received invalid command response:got -2, instead of 0
usb 4-1: received invalid command response:got 60, instead of 4
==================================================================
BUG: KASAN: stack-out-of-bounds in carl9170_cmd_callback drivers/net/wireless/ath/carl9170/rx.c:153 [inline]
BUG: KASAN: stack-out-of-bounds in carl9170_handle_command_response+0x21f/0xc50 drivers/net/wireless/ath/carl9170/rx.c:168
Write of size 60 at addr ffffc900001e7a38 by task swapper/1/0
CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x13d/0x4b0 mm/kasan/report.c:482
kasan_report+0xdf/0x1d0 mm/kasan/report.c:595
check_region_inline mm/kasan/generic.c:186 [inline]
kasan_check_range+0x10f/0x1e0 mm/kasan/generic.c:200
__asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106
carl9170_cmd_callback drivers/net/wireless/ath/carl9170/rx.c:153 [inline]
carl9170_handle_command_response+0x21f/0xc50 drivers/net/wireless/ath/carl9170/rx.c:168
carl9170_usb_rx_irq_complete+0xfc/0x1b0 drivers/net/wireless/ath/carl9170/usb.c:307
__usb_hcd_giveback_urb+0x38d/0x610 drivers/usb/core/hcd.c:1657
usb_hcd_giveback_urb+0x3ca/0x4a0 drivers/usb/core/hcd.c:1741
dummy_timer+0xda1/0x36c0 drivers/usb/gadget/udc/dummy_hcd.c:2005
__run_hrtimer kernel/time/hrtimer.c:1930 [inline]
__hrtimer_run_queues+0x470/0xa00 kernel/time/hrtimer.c:1994
hrtimer_run_softirq+0x17d/0x2c0 kernel/time/hrtimer.c:2011
handle_softirqs+0x1dd/0x9e0 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x160/0x210 kernel/softirq.c:735
irq_exit_rcu+0x9/0x30 kernel/softirq.c:752
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1061 [inline]
sysvec_apic_timer_interrupt+0x8f/0xb0 arch/x86/kernel/apic/apic.c:1061
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:pv_native_safe_halt+0xf/0x20 arch/x86/kernel/paravirt.c:63
Code: d4 b4 01 c3 cc cc cc cc 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 63 9d 15 00 fb f4 <e9> 7c f2 02 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90 90 90 90
RSP: 0018:ffffc9000013fe00 EFLAGS: 00000246
RAX: 0000000000046e1b RBX: ffff8881022d9dc0 RCX: ffffffff8770e3f5
RDX: 0000000000000000 RSI: ffffffff890d1d42 RDI: ffffffff87b03fe0
RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed103eae673d
R10: ffff8881f57339eb R11: 0000000000000000 R12: 0000000000000001
R13: ffffed102045b3b8 R14: 0000000000000001 R15: ffffffff8af1a1d0
arch_safe_halt arch/x86/include/asm/paravirt.h:62 [inline]
default_idle+0x9/0x10 arch/x86/kernel/process.c:767
default_idle_call+0x6c/0xb0 kernel/sched/idle.c:122
cpuidle_idle_call kernel/sched/idle.c:199 [inline]
do_idle+0x464/0x590 kernel/sched/idle.c:352
cpu_startup_entry+0x4f/0x60 kernel/sched/idle.c:451
start_secondary+0x21d/0x2d0 arch/x86/kernel/smpboot.c:312
common_startup_64+0x13e/0x148
</TASK>
The buggy address belongs to a 8-page vmalloc region starting at 0xffffc900001e0000 allocated at kernel_clone+0x12e/0x9c0 kernel/fork.c:2723
The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102aa7
flags: 0x200000000000000(node=0|zone=2)
raw: 0200000000000000 ffffea00040aa9c8 ffffea00040aa9c8 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x29c2(GFP_NOWAIT|__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_ZERO), pid 2, tgid 2 (kthreadd), ts 2543325669, free_ts 0
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x153/0x170 mm/page_alloc.c:1858
prep_new_page mm/page_alloc.c:1866 [inline]
get_page_from_freelist+0xf34/0x3a90 mm/page_alloc.c:3946
__alloc_frozen_pages_noprof+0x273/0x28a0 mm/page_alloc.c:5226
__alloc_pages_noprof+0xb/0x110 mm/page_alloc.c:5260
__alloc_pages_node_noprof include/linux/gfp.h:289 [inline]
alloc_pages_node_noprof include/linux/gfp.h:316 [inline]
vm_area_alloc_pages mm/vmalloc.c:3655 [inline]
__vmalloc_area_node mm/vmalloc.c:3878 [inline]
__vmalloc_node_range_noprof+0xe0c/0x1630 mm/vmalloc.c:4064
__vmalloc_node_noprof+0xad/0xf0 mm/vmalloc.c:4124
alloc_thread_stack_node kernel/fork.c:357 [inline]
dup_task_struct kernel/fork.c:926 [inline]
copy_process+0x7fb/0x7d20 kernel/fork.c:2088
kernel_clone+0x12e/0x9c0 kernel/fork.c:2723
kernel_thread+0xdb/0x120 kernel/fork.c:2784
create_kthread kernel/kthread.c:459 [inline]
kthreadd+0x498/0x7a0 kernel/kthread.c:817
ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
page_owner free stack trace missing
Memory state around the buggy address:
ffffc900001e7900: f1 f1 f1 00 00 00 f3 f3 f3 f3 f3 00 00 00 00 00
ffffc900001e7980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffc900001e7a00: 00 f1 f1 f1 f1 f1 f1 04 f2 04 f3 f3 f3 00 00 00
^
ffffc900001e7a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffc900001e7b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
----------------
Code disassembly (best guess), 1 bytes skipped:
0: b4 01 mov $0x1,%ah
2: c3 ret
3: cc int3
4: cc int3
5: cc int3
6: cc int3
7: 0f 1f 00 nopl (%rax)
a: 90 nop
b: 90 nop
c: 90 nop
d: 90 nop
e: 90 nop
f: 90 nop
10: 90 nop
11: 90 nop
12: 90 nop
13: 90 nop
14: 90 nop
15: 90 nop
16: 90 nop
17: 90 nop
18: 90 nop
19: 90 nop
1a: f3 0f 1e fa endbr64
1e: 66 90 xchg %ax,%ax
20: 0f 00 2d 63 9d 15 00 verw 0x159d63(%rip) # 0x159d8a
27: fb sti
28: f4 hlt
* 29: e9 7c f2 02 00 jmp 0x2f2aa <-- trapping instruction
2e: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1)
35: 00 00 00
38: 66 90 xchg %ax,%ax
3a: 90 nop
3b: 90 nop
3c: 90 nop
3d: 90 nop
3e: 90 nop
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH] mac80211: minstrel_ht: bound debugfs stats output construction
From: Pengpeng Hou @ 2026-04-23 22:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel, pengpeng
In-Reply-To: <20260417075642.32502-1-pengpeng@iscas.ac.cn>
Hi Johannes,
Thanks for reviewing it.
I rechecked the current minstrel group/rate bounds and agree that the
overflow claim does not hold statically. I'll drop this patch.
Thanks,
Pengpeng
^ permalink raw reply
* Re: [PATCH] mac80211: debugfs: bound queue state formatting to PAGE_SIZE
From: Pengpeng Hou @ 2026-04-23 22:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel, pengpeng
In-Reply-To: <20260417074604.18976-1-pengpeng@iscas.ac.cn>
Hi Johannes,
Thanks for reviewing it.
I rechecked the bounds and agree that the overflow claim is not
established for the current code. I'll drop this patch.
Thanks,
Pengpeng
^ permalink raw reply
* [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
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