* Re: [patch 31/38] parisc: Select ARCH_HAS_RANDOM_ENTROPY
From: Helge Deller @ 2026-04-14 12:41 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: linux-parisc, Arnd Bergmann, x86, Lu Baolu, iommu,
Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka, linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120319.658485572@kernel.org>
On 4/10/26 14:21, Thomas Gleixner wrote:
> The only remaining non-architecture usage of get_cycles() is to provide
> random_get_entropy().
>
> Switch parisc over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY
> and providing random_get_entropy() in asm/random.h.
>
> Add 'asm/timex.h' includes to the relevant files, so the global include can
> be removed once all architectures are converted over.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Helge Deller <deller@gmx.de>
> Cc: linux-parisc@vger.kernel.org
> ---
> arch/parisc/Kconfig | 1 +
> arch/parisc/include/asm/random.h | 12 ++++++++++++
> arch/parisc/include/asm/timex.h | 6 ------
> arch/parisc/kernel/processor.c | 1 +
> arch/parisc/kernel/time.c | 1 +
> 5 files changed, 15 insertions(+), 6 deletions(-)
I tested this series on parisc.
Works as expected.
Tested-by: Helge Deller <deller@gmx.de>
Thanks!
Helge
^ permalink raw reply
* [PATCH] wifi: cfg80211: fix grammar in MLO group key error message
From: Louis Kotze @ 2026-04-14 12:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel
The error message emitted by nl80211_validate_key_link_id() when a group
key install on an MLO wdev is missing the link ID reads "link ID must
for MLO group key", which is missing the words "be set". This makes the
error harder to grep and parse in userspace logs, and is reported
verbatim by wpa_supplicant via its nl80211 extack relay, e.g.:
wpa_supplicant: nl80211: kernel reports: link ID must for MLO group key
The sibling error strings in the same helper already use grammatical
phrasing ("link ID not allowed for pairwise key", "invalid link ID for
MLO group key", "link ID not allowed for non-MLO group key"). Fix this
one to match.
No functional change.
Fixes: e7a7b84e3317 ("wifi: cfg80211: Add link_id parameter to various key operations for MLO")
Signed-off-by: Louis Kotze <loukot@gmail.com>
---
net/wireless/nl80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index f334cdef8..b0bb94f29 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5100,7 +5100,7 @@ static int nl80211_validate_key_link_id(struct genl_info *info,
if (wdev->valid_links) {
if (link_id == -1) {
GENL_SET_ERR_MSG(info,
- "link ID must for MLO group key");
+ "link ID must be set for MLO group key");
return -EINVAL;
}
if (!(wdev->valid_links & BIT(link_id))) {
--
2.53.0
^ permalink raw reply related
* Re: Firmware for reverse engineering b43?
From: Jonas Gorski @ 2026-04-14 12:24 UTC (permalink / raw)
To: Joshua Peisach; +Cc: Johannes Berg, b43-dev, linux-wireless
In-Reply-To: <DHSUDVMGW0PS.2LYWKGG1C1135@ubuntu.com>
Hi,
On Tue, Apr 14, 2026 at 1:31 PM Joshua Peisach <jpeisach@ubuntu.com> wrote:
>
> On Tue Apr 14, 2026 at 5:14 AM EDT, Johannes Berg wrote:
> > I think there's no easy answer - what are you even trying to achieve?
> > Does b43 not work sufficiently well? Do you even know if some specific
> > calibration have a tendency to go out of whack? Is there later firmware
> > that has some advantage (given how little actually happens in firmware
> > in these devices, I'd be surprised by that) but isn't compatible with
> > the driver now, and you want to change that?
> >
> > I'd be tempted to say that if there's no problem there don't try to fix
> > anything, the hardware is ancient anyway, likely has few users, and
> > those users would probably be fine with just leaving it?
> >
> > johannes
>
> The BCM4321 (nphy) doesn't connect to my 5G network, so I figured that
> by filling in TODOs and FIXME's, I could eventually get something
> working.
>
> Other than that, I was thinking of making improvements for the sake of
> improving the driver.
The initial version of the brcm80211 softmac driver [1] should also
help in making sense of some of the code (flag names etc). While it
officially only supports BCM43224 and newer on BCMA, it still had
remnants of support for older N-PHY revisions, so may help in finding
differences or explaining what code does.
I once considered trying to clean up b43 based on brcmsmac, but never
got around to it.
Best regards,
Jonas
[1] https://github.com/torvalds/linux/tree/a9533e7ea3c410fed2f4cd8b3e1e213e48529b75/drivers/staging/brcm80211
^ permalink raw reply
* Re: Firmware for reverse engineering b43?
From: Joshua Peisach @ 2026-04-14 11:30 UTC (permalink / raw)
To: Johannes Berg, Joshua Peisach, b43-dev, linux-wireless
In-Reply-To: <c62a448843f189d78187de18d3fcb955f2779d13.camel@sipsolutions.net>
On Tue Apr 14, 2026 at 5:14 AM EDT, Johannes Berg wrote:
> I think there's no easy answer - what are you even trying to achieve?
> Does b43 not work sufficiently well? Do you even know if some specific
> calibration have a tendency to go out of whack? Is there later firmware
> that has some advantage (given how little actually happens in firmware
> in these devices, I'd be surprised by that) but isn't compatible with
> the driver now, and you want to change that?
>
> I'd be tempted to say that if there's no problem there don't try to fix
> anything, the hardware is ancient anyway, likely has few users, and
> those users would probably be fine with just leaving it?
>
> johannes
The BCM4321 (nphy) doesn't connect to my 5G network, so I figured that
by filling in TODOs and FIXME's, I could eventually get something
working.
Other than that, I was thinking of making improvements for the sake of
improving the driver.
-Josh
^ permalink raw reply
* [PATCH AUTOSEL 6.19-5.10] wifi: brcmfmac: validate bsscfg indices in IF events
From: Sasha Levin @ 2026-04-14 11:25 UTC (permalink / raw)
To: patches, stable
Cc: Pengpeng Hou, Arend van Spriel, Johannes Berg, Sasha Levin,
linux-wireless, brcm80211, brcm80211-dev-list.pdl, linux-kernel
In-Reply-To: <20260414112509.410217-1-sashal@kernel.org>
From: Pengpeng Hou <pengpeng@iscas.ac.cn>
[ Upstream commit 304950a467d83678bd0b0f46331882e2ac23b12d ]
brcmf_fweh_handle_if_event() validates the firmware-provided interface
index before it touches drvr->iflist[], but it still uses the raw
bsscfgidx field as an array index without a matching range check.
Reject IF events whose bsscfg index does not fit in drvr->iflist[]
before indexing the interface array.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260323074551.93530-1-pengpeng@iscas.ac.cn
[add missing wifi prefix]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed for a complete analysis. Let me
compile the findings.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line**
- Subsystem: `wifi: brcmfmac`
- Action verb: "validate" — this is adding a missing safety check
- Summary: Adds bounds validation for firmware-provided `bsscfgidx`
before using it as an array index
- Record: [wifi: brcmfmac] [validate] [add missing bounds check for
bsscfgidx in IF event handler]
**Step 1.2: Tags**
- `Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>` — author
- `Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>` — Broadcom
subsystem maintainer acked it
- `Link:
https://patch.msgid.link/20260323074551.93530-1-pengpeng@iscas.ac.cn`
— original submission
- `Signed-off-by: Johannes Berg <johannes.berg@intel.com>` — applied by
wireless maintainer
- No Fixes: tag, no Cc: stable, no Reported-by — expected for manual
review candidates
**Step 1.3: Commit Body**
- The commit message explains that `brcmf_fweh_handle_if_event()`
already validates `ifidx` before using it to index `drvr->iflist[]`,
but does NOT validate `bsscfgidx` before using it the same way.
- Bug: out-of-bounds array access when firmware provides `bsscfgidx >=
BRCMF_MAX_IFS` (16)
- Failure mode: kernel crash / memory corruption / potential code
execution
**Step 1.4: Hidden Bug Fix?**
- This IS a bug fix. The word "validate" means adding a missing safety
check. The commit directly prevents an out-of-bounds array access from
firmware-controlled data.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- Single file: `drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c`
- +5 lines added, 0 removed
- Function modified: `brcmf_fweh_handle_if_event()`
- Scope: single-file surgical fix
**Step 2.2: Code Flow Change**
- BEFORE: `ifevent->bsscfgidx` is used directly as an array index at
line 157 (`ifp = drvr->iflist[ifevent->bsscfgidx]`) and at line 162
(`brcmf_add_if(drvr, ifevent->bsscfgidx, ...)`), with no bounds check.
- AFTER: A bounds check `ifevent->bsscfgidx >= BRCMF_MAX_IFS` is added
before any array access, returning early with an error log if out of
bounds.
- Only affects the error path for malformed IF events from firmware.
**Step 2.3: Bug Mechanism**
- Category: **Buffer overflow / out-of-bounds array access**
- `drvr->iflist` is declared as `struct brcmf_if *iflist[BRCMF_MAX_IFS]`
where `BRCMF_MAX_IFS = 16`
- `ifevent->bsscfgidx` is a `u8` from firmware (range 0-255), used as
index without validation
- This is the SAME class of bug as **CVE-2022-3628**, which was fixed in
the sibling code path by commit `6788ba8aed4e2`
**Critical insight**: There are TWO separate `bsscfgidx` fields from
firmware:
1. `event->emsg.bsscfgidx` (event message header) — validated by
CVE-2022-3628 fix in `brcmf_fweh_event_worker()`
2. `ifevent->bsscfgidx` (IF event payload, `struct brcmf_if_event`) —
**NOT validated** until this commit
For IF events (BRCMF_E_IF), `brcmf_fweh_event_worker()` calls
`brcmf_fweh_handle_if_event()` which uses `ifevent->bsscfgidx` from the
payload, bypassing the header check entirely.
Additionally, `brcmf_add_if()` at `core.c:860` also indexes
`drvr->iflist[bsscfgidx]` without its own bounds check, so the fix
protects that path too.
**Step 2.4: Fix Quality**
- Obviously correct: identical pattern to `ifidx` check 4 lines above
and `bsscfgidx` check in `brcmf_fweh_event_worker()` at line 275
- Minimal and surgical: 5 lines, one conditional, one log message, one
return
- Zero regression risk: only rejects malformed firmware events, does not
change any normal path
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
- The unchecked `drvr->iflist[ifevent->bsscfgidx]` at line 157 was
introduced by commit `37a869ec859308` (Hante Meuleman, 2015-10-29),
"brcmfmac: Use consistent naming for bsscfgidx." This was a rename of
an even older pattern.
- The buggy code has existed since at least 2015, present in ALL active
stable trees.
**Step 3.2: CVE-2022-3628 (Related Fix)**
- Commit `6788ba8aed4e2` fixed the same bug class (CVE-2022-3628) in
`brcmf_fweh_event_worker()` but missed the
`brcmf_fweh_handle_if_event()` path.
- That fix was explicitly Cc'd to stable and applied to all active
stable trees.
- This current commit completes the original CVE fix.
**Step 3.3: File History**
- The file has minimal recent changes. The last relevant bug fix was
`6788ba8aed4e2` (the CVE fix). No other patches touch this function.
- This commit is standalone — no dependencies.
**Step 3.4: Author**
- Pengpeng Hou also submitted other security-related bounds-check fixes
(NFC pn533, bnxt_en, ipv6 ioam6, Bluetooth btusb).
**Step 3.5: Dependencies**
- No dependencies. The check pattern already exists for `ifidx` in the
same function. Applies cleanly to any tree that has the original code.
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
**Step 4.1-4.2: Patch Discussion**
- Acked by Arend van Spriel (Broadcom brcmfmac maintainer) — no caveats
- Applied by Johannes Berg (wireless maintainer) with only a minor
subject prefix fixup
- Appears to be accepted on v1 (no version indicator in subject)
**Step 4.3: Bug Report**
- No external bug report — this was found by code inspection (comparing
against the CVE-2022-3628 fix)
**Step 4.4-4.5: Related Patches**
- Standalone fix, not part of a series.
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1-5.2: Functions and Callers**
- `brcmf_fweh_handle_if_event()` is called only from
`brcmf_fweh_event_worker()` (line 303)
- `brcmf_fweh_event_worker()` is a work queue handler processing
firmware events
- The firmware events come from the Broadcom WiFi hardware/firmware via
the event queue
**Step 5.3-5.4: Call Chain**
- Firmware sends events → `brcmf_fweh_process_event()` queues them →
`brcmf_fweh_event_worker()` processes → `brcmf_fweh_handle_if_event()`
handles IF events → unchecked array access
- The path is reachable from firmware-provided data. For USB-attached
Broadcom WiFi devices, a malicious device could craft events with
arbitrary bsscfgidx values.
**Step 5.5: Similar Patterns**
- The exact same check already exists in `brcmf_fweh_event_worker()` at
line 275 (for the header's bsscfgidx). This commit adds the equivalent
check for the payload's bsscfgidx.
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
**Step 6.1: Buggy Code in Stable Trees**
- The unvalidated `drvr->iflist[ifevent->bsscfgidx]` access has existed
since at least kernel 3.x (original brcmfmac code from 2012-2015).
- All active stable trees (5.15, 6.1, 6.6, 6.12) contain this bug.
- The CVE-2022-3628 fix (6788ba8aed4e2) is present in stable 5.15+, but
only covered the worker path.
**Step 6.2: Backport Complications**
- Expected: clean apply. The function has been stable, with no
structural changes since the CVE fix.
- The 5-line patch touches a single, well-isolated location.
**Step 6.3: Related Fixes Already in Stable**
- CVE-2022-3628 fix is in stable but incomplete — it doesn't cover this
code path.
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
**Step 7.1: Subsystem Criticality**
- Subsystem: WiFi driver (brcmfmac — Broadcom FullMAC WiFi)
- Criticality: IMPORTANT — widely used in Raspberry Pi, many laptops,
USB WiFi dongles
- Broadcom WiFi is one of the most common WiFi chipsets in consumer
hardware
**Step 7.2: Subsystem Activity**
- Moderate activity — recent vendor-specific event handling rework, but
the core event handler is mature code.
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Affected Users**
- All users with Broadcom brcmfmac WiFi hardware (Raspberry Pi, many
laptops, USB WiFi adapters)
**Step 8.2: Trigger Conditions**
- Triggered by malicious/buggy firmware sending an IF event with
`bsscfgidx >= 16`
- For USB WiFi: a malicious USB device can inject arbitrary firmware
events (physical access attack vector)
- For embedded firmware: a firmware bug could produce out-of-range
values
**Step 8.3: Failure Mode Severity**
- Out-of-bounds array access on `drvr->iflist[]` (16-element pointer
array)
- Consequence: kernel crash (GPF/oops), potential memory corruption,
potential code execution
- Severity: **CRITICAL** (same class as CVE-2022-3628)
**Step 8.4: Risk-Benefit**
- BENEFIT: Very high — prevents kernel crash and potential security
exploit from firmware-controlled data
- RISK: Very low — 5 lines, identical pattern to existing validated
checks, zero normal-path impact
- Ratio: Strongly favorable for backporting
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence Compilation**
FOR backporting:
- Fixes an out-of-bounds array access from firmware-controlled data
(same class as CVE-2022-3628)
- Completes an incomplete CVE fix
- Extremely small (5 lines), obviously correct, identical pattern to
existing checks
- Acked by Broadcom maintainer, applied by wireless maintainer
- Bug present in ALL stable trees
- Zero regression risk — only rejects malformed firmware events
- Hardware is widely used (Raspberry Pi, laptops, USB WiFi)
AGAINST backporting:
- No reported real-world trigger (found by code audit)
- No CVE assigned (yet) — but same class as CVE-2022-3628
**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — identical pattern to existing
checks, Acked by maintainer
2. Fixes a real bug? **YES** — out-of-bounds array access from firmware
data
3. Important issue? **YES** — kernel crash / security vulnerability
4. Small and contained? **YES** — 5 lines, single file, single function
5. No new features or APIs? **YES** — pure bug fix
6. Can apply to stable? **YES** — clean apply expected, no dependencies
**Step 9.3: Exception Categories**
- Not an exception category — this is a standard, clear-cut
security/stability bug fix.
**Step 9.4: Decision**
- Overwhelming evidence supports backporting. This is a surgical 5-line
fix completing a CVE fix that was already backported to stable.
## Verification
- [Phase 1] Parsed tags: Acked-by from Broadcom maintainer, Link to
patch submission, applied by Johannes Berg
- [Phase 2] Diff analysis: +5 lines in `brcmf_fweh_handle_if_event()`,
adds bounds check for `ifevent->bsscfgidx` before `drvr->iflist[]`
indexing
- [Phase 2] Verified TWO separate bsscfgidx fields: `struct
brcmf_event_msg_be.bsscfgidx` (fweh.h:234) vs `struct
brcmf_if_event.bsscfgidx` (fweh.h:283) — confirmed different
structures, different data sources
- [Phase 2] Verified `brcmf_add_if()` at core.c:860 also uses bsscfgidx
as array index without its own bounds check — this fix protects that
path too
- [Phase 3] git blame: line 157 (`drvr->iflist[ifevent->bsscfgidx]`)
introduced by commit 37a869ec859308 (2015-10-29)
- [Phase 3] git show 6788ba8aed4e2: confirmed CVE-2022-3628 fix only
added bounds check in `brcmf_fweh_event_worker()`, NOT in
`brcmf_fweh_handle_if_event()`
- [Phase 3] Verified BRCMF_MAX_IFS = 16, iflist array is 16 elements
(core.h:118)
- [Phase 4] Patch acked by Arend van Spriel (Broadcom maintainer) with
no caveats
- [Phase 5] Traced call chain: firmware → brcmf_fweh_process_event() →
queue → brcmf_fweh_event_worker() → brcmf_fweh_handle_if_event() →
unchecked array access
- [Phase 5] Confirmed event->emsg.bsscfgidx check at line 275 does NOT
protect ifevent->bsscfgidx used at line 157 (different data fields)
- [Phase 6] Code exists in all active stable trees (5.15, 6.1, 6.6,
6.12) — verified via git log
- [Phase 6] CVE-2022-3628 fix (6788ba8aed4e2) is in stable since 5.15,
but incomplete
- [Phase 8] Failure mode: out-of-bounds read/write on pointer array →
kernel GPF/oops, severity CRITICAL
**YES**
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
index c2d98ee6652f3..1d25dc9ebca8b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
@@ -153,6 +153,11 @@ static void brcmf_fweh_handle_if_event(struct brcmf_pub *drvr,
bphy_err(drvr, "invalid interface index: %u\n", ifevent->ifidx);
return;
}
+ if (ifevent->bsscfgidx >= BRCMF_MAX_IFS) {
+ bphy_err(drvr, "invalid bsscfg index: %u\n",
+ ifevent->bsscfgidx);
+ return;
+ }
ifp = drvr->iflist[ifevent->bsscfgidx];
--
2.53.0
^ permalink raw reply related
* Re: Firmware for reverse engineering b43?
From: Johannes Berg @ 2026-04-14 9:14 UTC (permalink / raw)
To: Joshua Peisach, b43-dev, linux-wireless
In-Reply-To: <DHS1BJ5XFYRC.GCF9PXS0OSRI@ubuntu.com>
Hi,
> As I've been getting into kernel development,
Welcome :)
> When it comes to figuring out what code to write and how to implement
> functions, I see that there has been a mix of answers across the driver.
>
> Lots of functions refer to specs RE'd from the 4.x firmware[1], but
> my own install uses 5.x firmware. Additionally, the 6.x firmware is
> available.
>
> For my reverse engineering process, I opened the firmware in Ghidra
> and basically try to map the functionality to the driver, which appears
> to be what was done with the 4.x specs?
Pretty much, though no Ghidra or AI assist or anything back then, we had
to hand-roll our own tools ;-)
The concern then was that we should have two teams so nobody can claim
copyright violations, but I obviously don't know what Broadcom's stance
on this is (now or then.) I do know they were impressed by the level of
reverse engineering, especially down into the device firmware itself :)
> But, as I compare to the newer firmware, some functions have been moved
> or replaced. And sometimes, the newer firmware functions contradict the
> RE'd 4.x specs, or have extra steps in its process.
No surprise I guess, things could even just shift by compiling them
differently.
> Take b43_nphy_perical, or as known in the v4 firmware,
> wlc_phy_perical_nphy. I got to this function because wlc_nphy_init calls
> it. But actually, the RE'd version says init calls
> wlc_phy_perical_nphy_run, which the firmware says is not the case
> (it goes through wlc_phy_perical_nphy first, which has its own
> conditions).
>
> So, which is the best source of truth(s) for this driver? The v4.x
> specs, the v5 firmware, or the v6 firmware? Which one should be used,
> and which has a higher priority level over the other?
I think there's no easy answer - what are you even trying to achieve?
Does b43 not work sufficiently well? Do you even know if some specific
calibration have a tendency to go out of whack? Is there later firmware
that has some advantage (given how little actually happens in firmware
in these devices, I'd be surprised by that) but isn't compatible with
the driver now, and you want to change that?
I'd be tempted to say that if there's no problem there don't try to fix
anything, the hardware is ancient anyway, likely has few users, and
those users would probably be fine with just leaving it?
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v4 11/14] wifi: cfg80211: add PD-specific preamble and bandwidth capabilities
From: Johannes Berg @ 2026-04-14 8:35 UTC (permalink / raw)
To: Peddolla Harshavardhan Reddy; +Cc: linux-wireless, kavita.kavita
In-Reply-To: <20260320175938.2547288-12-peddolla.reddy@oss.qualcomm.com>
On Fri, 2026-03-20 at 23:29 +0530, Peddolla Harshavardhan Reddy wrote:
> +++ b/net/wireless/nl80211.c
> @@ -2482,6 +2482,20 @@ nl80211_send_pmsr_ftm_capa(const struct cfg80211_pmsr_capabilities *cap,
> cap->pd_max_peer_rsta_role))
> return -ENOBUFS;
> }
> +
> + if (nla_put_u32(msg, NL80211_PMSR_FTM_CAPA_ATTR_PD_EDCA_PREAMBLES,
> + cap->ftm.pd_edca_preambles))
> + return -ENOBUFS;
> + if (nla_put_u32(msg, NL80211_PMSR_FTM_CAPA_ATTR_PD_NTB_PREAMBLES,
> + cap->ftm.pd_ntb_preambles))
> + return -ENOBUFS;
> + if (nla_put_u32(msg, NL80211_PMSR_FTM_CAPA_ATTR_PD_EDCA_BANDWIDTHS,
> + cap->ftm.pd_edca_bandwidths))
> + return -ENOBUFS;
> + if (nla_put_u32(msg, NL80211_PMSR_FTM_CAPA_ATTR_PD_NTB_BANDWIDTHS,
> + cap->ftm.pd_ntb_bandwidths))
> + return -ENOBUFS;
That probably should be contingent on pd_support or so, otherwise you
end up with a bunch of zero values in userspace, which is odd?
> + if (out->ftm.pd_request &&
> + !(rdev->wiphy.pmsr_capa->ftm.pd_edca_bandwidths & BIT(out->chandef.width)) &&
> + !(rdev->wiphy.pmsr_capa->ftm.pd_ntb_bandwidths & BIT(out->chandef.width))) {
> + NL_SET_ERR_MSG(info->extack, "FTM: unsupported bandwidth for pd request");
> + return -EINVAL;
> + }
This seems odd to me, why are you adding *two* fields when they're never
treated differently? Shouldn't you check if it's an NTB or EDCA request?
> + if (out->ftm.pd_request &&
> + !(capa->ftm.pd_ntb_preambles & BIT(preamble)) &&
> + !(capa->ftm.pd_edca_preambles & BIT(preamble))) {
> + NL_SET_ERR_MSG_ATTR(info->extack,
> + tb[NL80211_PMSR_FTM_REQ_ATTR_PREAMBLE],
> + "FTM: invalid preamble for PD request");
> + return -EINVAL;
> + }
>
Same here.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v4 10/14] wifi: cfg80211: add ingress/egress distance thresholds for FTM
From: Stern, Avraham @ 2026-04-14 8:12 UTC (permalink / raw)
To: peddolla.reddy@oss.qualcomm.com
Cc: johannes@sipsolutions.net, kavita.kavita@oss.qualcomm.com,
linux-wireless@vger.kernel.org
+ * @ <NL80211_PMSR_FTM_REQ_ATTR_INGRESS: the measurement result of the peer
+ * < needs to be indicated in case the device moves into this range.
+ * < (units mm, u64).
+ * @ <NL80211_PMSR_FTM_REQ_ATTR_EGRESS: the measurement result of the peer
+ * < needs to be indicated in case the device moves out of this range.
> + * (units mm, u64).
Please specify that these are optional, and what is the expected behavior if none/only one is specified.
---------------------------------------------------------------------
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* Re: [PATCH] ath11k: workaround firmware bug where peer_id=0
From: Baochen Qiang @ 2026-04-14 7:06 UTC (permalink / raw)
To: Matthew Leach, Jeff Johnson; +Cc: linux-wireless, ath11k, linux-kernel, kernel
In-Reply-To: <87h5pxlpg4.fsf@collabora.com>
On 3/30/2026 3:57 PM, Matthew Leach wrote:
> Hello,
>
> Matthew Leach <matthew.leach@collabora.com> writes:
>
>> This patch caches the peer enctype during the MSDU processing loop,
>> caching it on the first AMSDU sub-frame (is_first_msdu=1
>> is_last_msdu=0) and setting the correct enctype for any subsequent
>> sub-MSDUs.
>
> I've been looking at creating a patch that addresses the root cause,
> rather than patching incoming frame's flags:
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/drivers/net/wireless/ath/ath11k/peer.c b/drivers/net/wireless/ath/ath11k/peer.c
> index 6d0126c39301..98348ccfdfbe 100644
> --- a/drivers/net/wireless/ath/ath11k/peer.c
> +++ b/drivers/net/wireless/ath/ath11k/peer.c
> @@ -347,7 +347,7 @@ static int __ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, const u8 *addr)
> return 0;
> }
>
> -int ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, u8 *addr)
> +int ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, const u8 *addr)
> {
> int ret;
>
> @@ -372,7 +372,7 @@ int ath11k_peer_create(struct ath11k *ar, struct ath11k_vif *arvif,
> {
> struct ath11k_peer *peer;
> struct ath11k_sta *arsta;
> - int ret, fbret;
> + int ret, fbret, retries = 3;
>
> lockdep_assert_held(&ar->conf_mutex);
>
> @@ -400,6 +400,8 @@ int ath11k_peer_create(struct ath11k *ar, struct ath11k_vif *arvif,
> spin_unlock_bh(&ar->ab->base_lock);
> mutex_unlock(&ar->ab->tbl_mtx_lock);
>
> +retry:
> +
> ret = ath11k_wmi_send_peer_create_cmd(ar, param);
> if (ret) {
> ath11k_warn(ar->ab,
> @@ -427,6 +429,18 @@ int ath11k_peer_create(struct ath11k *ar, struct ath11k_vif *arvif,
> goto cleanup;
> }
>
> + if (!peer->peer_id) {
> + if (retries--) {
> + spin_unlock_bh(&ar->ab->base_lock);
> + mutex_unlock(&ar->ab->tbl_mtx_lock);
> + ath11k_peer_delete(ar, param->vdev_id, param->peer_addr);
> + goto retry;
> + } else {
> + ath11k_warn(ar->ab, "Null peer workaround failed for peer %pM, adding anyway",
> + param->peer_addr);
> + }
> + }
> +
> ret = ath11k_peer_rhash_add(ar->ab, peer);
> if (ret) {
> spin_unlock_bh(&ar->ab->base_lock);
> diff --git a/drivers/net/wireless/ath/ath11k/peer.h b/drivers/net/wireless/ath/ath11k/peer.h
> index 3ad2f3355b14..6325c4d157c7 100644
> --- a/drivers/net/wireless/ath/ath11k/peer.h
> +++ b/drivers/net/wireless/ath/ath11k/peer.h
> @@ -47,7 +47,7 @@ struct ath11k_peer *ath11k_peer_find_by_addr(struct ath11k_base *ab,
> const u8 *addr);
> struct ath11k_peer *ath11k_peer_find_by_id(struct ath11k_base *ab, int peer_id);
> void ath11k_peer_cleanup(struct ath11k *ar, u32 vdev_id);
> -int ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, u8 *addr);
> +int ath11k_peer_delete(struct ath11k *ar, u32 vdev_id, const u8 *addr);
> int ath11k_peer_create(struct ath11k *ar, struct ath11k_vif *arvif,
> struct ieee80211_sta *sta, struct peer_create_params *param);
> int ath11k_wait_for_peer_delete_done(struct ath11k *ar, u32 vdev_id,
> --8<---------------cut here---------------end--------------->8---
>
> This patch detects the error condition at the point where a peer map
> request reply is received from the firmware. If the firmware maps with
> peer_id=0, we request that the firmware unmap that peer and map again,
> hoping it selects a peer_id!=0. We attempt this up to three times, at
> which point we give up and let the peer be mapped with an ID of 0.
>
> This patch addresses the root cause, but I think it's more invasive. I'd
> appreciate some comments as to which approach upstream would prefer. If
> the preference is for the above, I'll send out a v2.
for chips like QCA2066 and WCN6855 etc 0 is a valid value, however this is not for chips
like QCN9074 etc.
so a possible fix would be to add hardware ops based on chips: for QCN9074 we keep the
existing validation on 0 in the ops, while for QCA2066 the ops is a null func. Or even
simper we can remove the validation for all chips.
>
> Regards,
^ permalink raw reply
* Re: [PATCH v2] wifi: ath11k: apply existing PM quirk to ThinkPad P14s Gen 5 AMD
From: Baochen Qiang @ 2026-04-14 6:43 UTC (permalink / raw)
To: Kyle Farnung
Cc: Jeff Johnson, Baochen Qiang, Jeff Johnson, linux-wireless, ath11k,
linux-kernel, stable
In-Reply-To: <CAOPSVF0VHR4BQsmfWFeFnANsQYBw-x7fHxH2JFNO=oWjgeS66Q@mail.gmail.com>
On 4/1/2026 11:48 AM, Kyle Farnung wrote:
> On Tue, Mar 31, 2026 at 7:08 PM Baochen Qiang
> <baochen.qiang@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 3/31/2026 2:32 PM, Kyle Farnung via B4 Relay wrote:
>>> From: Kyle Farnung <kfarnung@gmail.com>
>>>
>>> Some ThinkPad P14s Gen 5 AMD systems experience suspend/resume
>>> reliability issues similar to those reported in [1]. These platforms
>>
>> how similar it is? can you describe the issue in details?
>
> The issue is that intermittently after suspend my WiFi adapter connects
> successfully for a few minutes and then drops. It will then keep trying to
> reconnect in a loop but never succeed. A reboot will fix it, but eventually
> I found that reloading the module also resolves the issue
> (modprobe -r ath11k_pci && modprobe ath11k_pci). Based on some searching, I
> did try adding "ath11k_pci.disable_idle_ps=1" to my kernel arguments. At
> first it looked like maybe it worked, but then I hit the same problem
> again. At that point I decided to try building a custom module with the
> ATH11K_PM_WOW override and so far I'm two days and 10 suspends in without
> issue.
>
> Looking through kernel logs, the issue appears to have started with kernel
> version 6.17.4. It looks like my Fedora install jumped from 6.16.10 to
> 6.17.4 on October 22, 2025 and I started seeing the issue two days later.
>
> Here are the logs from the most recent occurrence (filtered for brevity):
>
> Mar 29 15:26:24 kjfp14sg5 kernel: PM: suspend exit
> Mar 29 15:26:24 kjfp14sg5 kernel: ath11k_pci 0000:02:00.0: chip_id
> 0x12 chip_family 0xb board_id 0xff soc_id 0x400c1211
> Mar 29 15:26:24 kjfp14sg5 kernel: ath11k_pci 0000:02:00.0: fw_version
> 0x11088c35 fw_build_timestamp 2024-04-17 08:34 fw_build_id
> WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
> Mar 29 15:26:30 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=US
> Mar 29 15:26:30 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=US
> Mar 29 15:26:30 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=US
> Mar 29 15:26:35 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-CONNECTED - Connection to 68:d7:9a:2a:94:f8 completed [id=0
> id_str=]
> Mar 29 15:26:49 kjfp14sg5 wpa_supplicant[2373]: wlp2s0: CTRL-EVENT-BEACON-LOSS
this is the reason to your disconnection
> Mar 29 15:26:55 kjfp14sg5 kernel: ath11k_pci 0000:02:00.0: failed to
> flush transmit queue, data pkts pending 9
> Mar 29 15:26:55 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-DISCONNECTED bssid=68:d7:9a:2a:94:f8 reason=4
> locally_generated=1
> Mar 29 15:27:00 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-DISCONNECTED bssid=80:2a:a8:98:26:3e reason=6
> Mar 29 15:27:05 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-DISCONNECTED bssid=74:ac:b9:df:54:36 reason=6
> Mar 29 15:27:09 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-DISCONNECTED bssid=68:d7:9a:2a:94:f8 reason=2
> Mar 29 15:27:09 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="Batman" auth_failures=1
> duration=10 reason=CONN_FAILED
and the bssid is disabled so association to this AP won't happen in a period.
Anyway, although it works, using the PM quirk seems not the right fix. As you mentioned it
seems like a regression starting to show in 6.17.4, can you do regression test to locate
the issue commit?
>
>>
>>> were not previously included in the ath11k PM quirk table.
>>>
>>> Add DMI matches for product IDs 21ME and 21MF to apply the existing
>>> ATH11K_PM_WOW override, improving suspend/resume behavior on these
>>> systems.
>>>
>>> Tested on a ThinkPad P14s Gen 5 AMD (21ME) running 6.19.9.
>>>
>>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196
>>> [2] https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-p-series-laptops/thinkpad-p14s-gen-5-type-21me-21mf/
>>>
>>> Fixes: ce8669a27016 ("wifi: ath11k: determine PM policy based on machine model")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Kyle Farnung <kfarnung@gmail.com>
>>> ---
>>> Changes in v2:
>>> - Fix missing mailing list recipients (linux-wireless, ath11k, linux-kernel)
>>> - Link to v1: https://lore.kernel.org/r/20260330-p14s-pm-quirk-v1-1-cf2fa39cc2d5@gmail.com
>>> ---
>>> 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 3f6f4db5b7ee1aba79fd7526e5d59d068e0f4a2e..21d366224e75904feeae6cb9c93d9ef692d127fe 100644
>>> --- a/drivers/net/wireless/ath/ath11k/core.c
>>> +++ b/drivers/net/wireless/ath/ath11k/core.c
>>> @@ -1041,6 +1041,20 @@ static const struct dmi_system_id ath11k_pm_quirk_table[] = {
>>> DMI_MATCH(DMI_PRODUCT_NAME, "21D5"),
>>> },
>>> },
>>> + {
>>> + .driver_data = (void *)ATH11K_PM_WOW,
>>> + .matches = { /* P14s G5 AMD #1 */
>>> + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
>>> + DMI_MATCH(DMI_PRODUCT_NAME, "21ME"),
>>> + },
>>> + },
>>> + {
>>> + .driver_data = (void *)ATH11K_PM_WOW,
>>> + .matches = { /* P14s G5 AMD #2 */
>>> + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
>>> + DMI_MATCH(DMI_PRODUCT_NAME, "21MF"),
>>> + },
>>> + },
>>> {}
>>> };
>>>
>>>
>>> ---
>>> base-commit: dbd94b9831bc52a1efb7ff3de841ffc3457428ce
>>> change-id: 20260330-p14s-pm-quirk-0a51ba19235f
>>>
>>> Best regards,
>>
^ permalink raw reply
* RE: [PATCH 2/2] wifi: rtw89: phy: make RF calibration timeouts non-fatal on USB
From: Ping-Ke Shih @ 2026-04-14 6:39 UTC (permalink / raw)
To: Louis Kotze, linux-wireless@vger.kernel.org
Cc: rtl8821cerfe2@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <20260410080017.82946-3-loukot@gmail.com>
Louis Kotze <loukot@gmail.com> wrote:
> On USB adapters, RF calibration timeouts can still occasionally occur
> despite the increased timeout values, particularly under system load
> or USB bus contention. However, the radio typically continues to
> operate correctly despite an incomplete calibration — the timeout
> does not indicate a hardware failure.
>
> Make calibration timeouts and bad state returns non-fatal on USB by
> logging at debug level and continuing, rather than
If calibration timeouts, the performance might be bad. How about just
to enlarge timeout time in 1/2 patch?
> returning
> -ETIMEDOUT/-EFAULT which can cascade into a connection failure or
> disconnect.
It seems like we don't actually handle the return code for now.
Could you point out the path you encountered?
>
> PCIe error handling is unchanged — timeouts remain fatal on PCIe
> where they indicate a real problem.
>
> Signed-off-by: Louis Kotze <loukot@gmail.com>
> ---
> drivers/net/wireless/realtek/rtw89/phy.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtw89/phy.c b/drivers/net/wireless/realtek/rtw89/phy.c
> index 4d809df8b..a06bea88e 100644
> --- a/drivers/net/wireless/realtek/rtw89/phy.c
> +++ b/drivers/net/wireless/realtek/rtw89/phy.c
> @@ -3972,9 +3972,21 @@ int rtw89_phy_rfk_report_wait(struct rtw89_dev *rtwdev, const char *rfk_name,
> time_left = wait_for_completion_timeout(&wait->completion,
> msecs_to_jiffies(ms));
> if (time_left == 0) {
> + if (rtwdev->hci.type == RTW89_HCI_TYPE_USB) {
> + rtw89_debug(rtwdev, RTW89_DBG_RFK,
> + "RF %s timeout (non-fatal on USB)\n",
> + rfk_name);
> + goto out;
> + }
> rtw89_warn(rtwdev, "failed to wait RF %s\n", rfk_name);
> return -ETIMEDOUT;
> } else if (wait->state != RTW89_RFK_STATE_OK) {
> + if (rtwdev->hci.type == RTW89_HCI_TYPE_USB) {
> + rtw89_debug(rtwdev, RTW89_DBG_RFK,
> + "RF %s state %d (non-fatal on USB)\n",
> + rfk_name, wait->state);
> + goto out;
> + }
> rtw89_warn(rtwdev, "failed to do RF %s result from state %d\n",
> rfk_name, wait->state);
> return -EFAULT;
> --
> 2.53.0
^ permalink raw reply
* RE: [PATCH 1/2] wifi: rtw89: phy: increase RF calibration timeouts for USB transport
From: Ping-Ke Shih @ 2026-04-14 6:32 UTC (permalink / raw)
To: Louis Kotze, linux-wireless@vger.kernel.org
Cc: rtl8821cerfe2@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <20260410080017.82946-2-loukot@gmail.com>
Louis Kotze <loukot@gmail.com> wrote:
> USB transport adds significant latency to H2C/C2H round-trips used
> by RF calibration. The existing timeout values were designed for PCIe
> and are too tight for USB, causing "failed to wait RF DACK",
> "failed to wait RF TSSI" and similar errors on USB adapters.
>
> Apply a 4x timeout multiplier when the device uses USB transport.
> The multiplier is applied in rtw89_phy_rfk_report_wait() so all
> calibrations benefit without changing any call sites or PCIe
> timeout values.
>
> The 4x multiplier was chosen based on measured data from two
> independent testers (RTL8922AU, 6GHz MLO and 2.4/5GHz):
>
> Calibration PCIe timeout Max measured (USB) 4x timeout
> PRE_NTFY 5ms 1ms 20ms
> DACK 58ms 72ms 232ms
> RX_DCK 128ms 374ms 512ms
> TSSI normal 20ms 24ms 80ms
> TSSI scan 6ms 14ms 24ms
> TXGAPK 54ms 18ms 216ms
> IQK 84ms 53ms 336ms
> DPK 34ms 30ms 136ms
>
> Tested with RTL8922AU on 6GHz MLO (5GHz + 6GHz simultaneous):
> 25 connect/disconnect cycles with zero failures.
>
> Signed-off-by: Louis Kotze <loukot@gmail.com>
Looks good to me. But please change comment style.
> ---
> drivers/net/wireless/realtek/rtw89/phy.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtw89/phy.c b/drivers/net/wireless/realtek/rtw89/phy.c
> index e70d0e283..4d809df8b 100644
> --- a/drivers/net/wireless/realtek/rtw89/phy.c
> +++ b/drivers/net/wireless/realtek/rtw89/phy.c
> @@ -3956,6 +3956,13 @@ int rtw89_phy_rfk_report_wait(struct rtw89_dev *rtwdev, const char *rfk_name,
> struct rtw89_rfk_wait_info *wait = &rtwdev->rfk_wait;
> unsigned long time_left;
>
> + /* USB transport adds latency to H2C/C2H round-trips, so RF
> + * calibrations take longer than on PCIe. Apply a 4x multiplier
> + * to avoid spurious timeouts.
> + */
For now, we don't apply networking specific comment style. Keep first line '/*'.
> + if (rtwdev->hci.type == RTW89_HCI_TYPE_USB)
> + ms *= 4;
> +
> /* Since we can't receive C2H event during SER, use a fixed delay. */
> if (test_bit(RTW89_FLAG_SER_HANDLING, rtwdev->flags)) {
> fsleep(1000 * ms / 2);
> --
> 2.53.0
^ permalink raw reply
* [PATCH ath-next] wifi: ath12k: Fix invalid IRQ requests during AHB probe
From: Aaradhana Sahu @ 2026-04-14 6:28 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, Aaradhana Sahu
ath12k_ahb_config_ext_irq() iterates over ATH12K_EXT_IRQ_NUM_MAX (16)
entries while checking TX ring masks, but the tcl_to_wbm_rbm_map array
contains only DP_TCL_NUM_RING_MAX (4) valid elements.
When the iterator (j) is greater than or equal to DP_TCL_NUM_RING_MAX,
it accesses tcl_to_wbm_rbm_map[j] out of bounds. This results in
reading uninitialized memory for wbm_ring_num, causing the driver to
evaluate incorrect BIT() conditions and request IRQs for rings that do
not have an assigned interrupt line or device tree entry.
This leads to request_irq() failures with -ENXIO or -EINVAL during
ath12k AHB probe.
Fix this by splitting the loop into two separate loops: one iterating
over DP_TCL_NUM_RING_MAX for TX ring, and another iterating over
ATH12K_EXT_IRQ_NUM_MAX for remaining IRQ entries.
Also add a bounds check for num_irq.
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Fixes: 6cee30f0da75 ("wifi: ath12k: add AHB driver support for IPQ5332")
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/ahb.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/ahb.c b/drivers/net/wireless/ath/ath12k/ahb.c
index 2dcf0a52e4c1..30733a244454 100644
--- a/drivers/net/wireless/ath/ath12k/ahb.c
+++ b/drivers/net/wireless/ath/ath12k/ahb.c
@@ -583,31 +583,36 @@ static int ath12k_ahb_config_ext_irq(struct ath12k_base *ab)
netif_napi_add(irq_grp->napi_ndev, &irq_grp->napi,
ath12k_ahb_ext_grp_napi_poll);
- for (j = 0; j < ATH12K_EXT_IRQ_NUM_MAX; j++) {
- /* For TX ring, ensure that the ring mask and the
- * tcl_to_wbm_rbm_map point to the same ring number.
- */
+ for (j = 0; j < DP_TCL_NUM_RING_MAX; j++) {
if (ring_mask->tx[i] &
- BIT(ab->hal.tcl_to_wbm_rbm_map[j].wbm_ring_num)) {
+ BIT(ab->hal.tcl_to_wbm_rbm_map[j].wbm_ring_num) &&
+ num_irq < ATH12K_EXT_IRQ_NUM_MAX) {
irq_grp->irqs[num_irq++] =
wbm2host_tx_completions_ring1 - j;
}
+ }
- if (ring_mask->rx[i] & BIT(j)) {
+ for (j = 0; j < ATH12K_EXT_IRQ_NUM_MAX; j++) {
+ if (ring_mask->rx[i] & BIT(j) &&
+ num_irq < ATH12K_EXT_IRQ_NUM_MAX) {
irq_grp->irqs[num_irq++] =
reo2host_destination_ring1 - j;
}
- if (ring_mask->rx_err[i] & BIT(j))
+ if (ring_mask->rx_err[i] & BIT(j) &&
+ num_irq < ATH12K_EXT_IRQ_NUM_MAX)
irq_grp->irqs[num_irq++] = reo2host_exception;
- if (ring_mask->rx_wbm_rel[i] & BIT(j))
+ if (ring_mask->rx_wbm_rel[i] & BIT(j) &&
+ num_irq < ATH12K_EXT_IRQ_NUM_MAX)
irq_grp->irqs[num_irq++] = wbm2host_rx_release;
- if (ring_mask->reo_status[i] & BIT(j))
+ if (ring_mask->reo_status[i] & BIT(j) &&
+ num_irq < ATH12K_EXT_IRQ_NUM_MAX)
irq_grp->irqs[num_irq++] = reo2host_status;
- if (ring_mask->rx_mon_dest[i] & BIT(j))
+ if (ring_mask->rx_mon_dest[i] & BIT(j) &&
+ num_irq < ATH12K_EXT_IRQ_NUM_MAX)
irq_grp->irqs[num_irq++] =
rxdma2host_monitor_destination_mac1;
}
base-commit: e6630ad4c58f89ba72e64fca5989ecf1e06319c9
--
2.34.1
^ permalink raw reply related
* [PATCH rtw-next 3/3] wifi: rtlwifi: validate action frame size before using in _rtl_pci_tx_isr()
From: Ping-Ke Shih @ 2026-04-14 6:22 UTC (permalink / raw)
To: linux-wireless; +Cc: Jes.Sorensen
In-Reply-To: <20260414062229.21047-1-pkshih@realtek.com>
Since TX action frames might be malformed, validate the size before using.
Tested on RTL8723BE.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 9cc0a871ea3c..73018a0498b4 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -505,9 +505,10 @@ static void _rtl_pci_tx_isr(struct ieee80211_hw *hw, int prio)
}
}
if (ieee80211_is_action(fc)) {
- struct ieee80211_mgmt *action_frame =
- (struct ieee80211_mgmt *)skb->data;
- if (action_frame->u.action.action_code ==
+ struct ieee80211_mgmt *action_frame = (void *)skb->data;
+
+ if (skb->len >= IEEE80211_MIN_ACTION_SIZE(action_code) &&
+ action_frame->u.action.action_code ==
WLAN_HT_ACTION_SMPS) {
dev_kfree_skb(skb);
goto tx_status_ok;
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 2/3] wifi: rtlwifi: validate action frame size in rtl_action_proc()
From: Ping-Ke Shih @ 2026-04-14 6:22 UTC (permalink / raw)
To: linux-wireless; +Cc: Jes.Sorensen
In-Reply-To: <20260414062229.21047-1-pkshih@realtek.com>
Since action frames might be malformed from RX or injected TX, validate
the size before using.
More, use struct ieee80211_mgmt to access fields of action frames instead
of counting barely.
Tested with ping on RTL8723BE. The add BA request action frames of TX/RX
can be handled properly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtlwifi/base.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c b/drivers/net/wireless/realtek/rtlwifi/base.c
index aad377864e73..9e98c01bb90e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -1369,18 +1369,19 @@ bool rtl_action_proc(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
struct ieee80211_hdr *hdr = rtl_get_hdr(skb);
struct rtl_priv *rtlpriv = rtl_priv(hw);
+ struct ieee80211_mgmt *mgmt;
__le16 fc = rtl_get_fc(skb);
- u8 *act = (u8 *)(((u8 *)skb->data + MAC80211_3ADDR_LEN));
- u8 category;
if (!ieee80211_is_action(fc))
return true;
- category = *act;
- act++;
- switch (category) {
+ mgmt = (void *)skb->data;
+ if (skb->len < IEEE80211_MIN_ACTION_SIZE(action_code))
+ return true;
+
+ switch (mgmt->u.action.category) {
case ACT_CAT_BA:
- switch (*act) {
+ switch (mgmt->u.action.action_code) {
case ACT_ADDBAREQ:
if (mac->act_scanning)
return false;
@@ -1394,9 +1395,11 @@ bool rtl_action_proc(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
struct ieee80211_sta *sta = NULL;
struct rtl_sta_info *sta_entry = NULL;
struct rtl_tid_data *tid_data;
- struct ieee80211_mgmt *mgmt = (void *)skb->data;
u16 capab = 0, tid = 0;
+ if (skb->len < IEEE80211_MIN_ACTION_SIZE(addba_req))
+ return true;
+
rcu_read_lock();
sta = rtl_find_sta(hw, hdr->addr3);
if (sta == NULL) {
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 1/3] wifi: rtl8xxxu: validate action frame size before using in rtl8xxxu_dump_action()
From: Ping-Ke Shih @ 2026-04-14 6:22 UTC (permalink / raw)
To: linux-wireless; +Cc: Jes.Sorensen
In-Reply-To: <20260414062229.21047-1-pkshih@realtek.com>
The rtl8xxxu_dump_action() is to print action frames when turning on
debug mask. Validate the skb->len size to prevent potential broken in
monitor mode injection.
Compile tested only.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtl8xxxu/core.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c b/drivers/net/wireless/realtek/rtl8xxxu/core.c
index f20fade0c099..508137e4a87a 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
@@ -5126,7 +5126,7 @@ static void rtl8xxxu_tx_complete(struct urb *urb)
}
static void rtl8xxxu_dump_action(struct device *dev,
- struct ieee80211_hdr *hdr)
+ struct ieee80211_hdr *hdr, unsigned int skb_len)
{
struct ieee80211_mgmt *mgmt = (struct ieee80211_mgmt *)hdr;
u16 cap, timeout;
@@ -5134,8 +5134,14 @@ static void rtl8xxxu_dump_action(struct device *dev,
if (!(rtl8xxxu_debug & RTL8XXXU_DEBUG_ACTION))
return;
+ if (skb_len < IEEE80211_MIN_ACTION_SIZE(action_code))
+ return;
+
switch (mgmt->u.action.action_code) {
case WLAN_ACTION_ADDBA_RESP:
+ if (skb_len < IEEE80211_MIN_ACTION_SIZE(addba_resp))
+ break;
+
cap = le16_to_cpu(mgmt->u.action.addba_resp.capab);
timeout = le16_to_cpu(mgmt->u.action.addba_resp.timeout);
dev_info(dev, "WLAN_ACTION_ADDBA_RESP: "
@@ -5148,6 +5154,9 @@ static void rtl8xxxu_dump_action(struct device *dev,
le16_to_cpu(mgmt->u.action.addba_resp.status));
break;
case WLAN_ACTION_ADDBA_REQ:
+ if (skb_len < IEEE80211_MIN_ACTION_SIZE(addba_req))
+ break;
+
cap = le16_to_cpu(mgmt->u.action.addba_req.capab);
timeout = le16_to_cpu(mgmt->u.action.addba_req.timeout);
dev_info(dev, "WLAN_ACTION_ADDBA_REQ: "
@@ -5437,7 +5446,7 @@ static void rtl8xxxu_tx(struct ieee80211_hw *hw,
}
if (ieee80211_is_action(hdr->frame_control))
- rtl8xxxu_dump_action(dev, hdr);
+ rtl8xxxu_dump_action(dev, hdr, skb->len);
tx_info->rate_driver_data[0] = hw;
--
2.25.1
^ permalink raw reply related
* [PATCH rtw-next 0/3] wifi: rtl8xxxu/rtlwifi: validate action frame size
From: Ping-Ke Shih @ 2026-04-14 6:22 UTC (permalink / raw)
To: linux-wireless; +Cc: Jes.Sorensen
As mentioned by Johannes [1], some where of rtl8xxxu and rtlwifi check
fields of action frame without checking size. Refine the code to check
size by IEEE80211_MIN_ACTION_SIZE() before using.
[1] https://lore.kernel.org/linux-wireless/d4e7f2ec4a7def5820eb41e84ed0815e159cf39b.camel@sipsolutions.net/
Ping-Ke Shih (3):
wifi: rtl8xxxu: validate action frame size before using in
rtl8xxxu_dump_action()
wifi: rtlwifi: validate action frame size in rtl_action_proc()
wifi: rtlwifi: validate action frame size before using in
_rtl_pci_tx_isr()
drivers/net/wireless/realtek/rtl8xxxu/core.c | 13 +++++++++++--
drivers/net/wireless/realtek/rtlwifi/base.c | 17 ++++++++++-------
drivers/net/wireless/realtek/rtlwifi/pci.c | 7 ++++---
3 files changed, 25 insertions(+), 12 deletions(-)
base-commit: fa489a77e3267e05df95db96ba98e141ec07cbd9
--
2.25.1
^ permalink raw reply
* Re: [BUG] mt7921e: Intermittent connection failure
From: silverducks @ 2026-04-14 6:22 UTC (permalink / raw)
To: Sean Wang
Cc: linux-wireless, nbd, lorenzo, ryder.lee, shayne.chen, sean.wang,
matthias.bgg, angelogioacchino.delregno,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <651b9626-0c2c-4993-829a-3259141109dc@altlinux.org>
[-- Attachment #1: Type: text/plain, Size: 454 bytes --]
Greetings!
Update:
New version of the script is less consistent at reproducing the bug.
I've also noticed that on patched kernel it triggers timeout way
more often than older script. I've rolled back to the older one,
which relies on the NM autoconnect feature, though retained cleanup
changes.
I'm guessing direct nmcli command is often preventing NM from doing
whatever it is usually doing that triggers the error.
Script and reruns with it attached.
[-- Attachment #2: attachments.tar.gz --]
[-- Type: application/gzip, Size: 158890 bytes --]
^ permalink raw reply
* [PATCH] Skip ieee80211_verify_sta_ht_mcs_support check in non-strict mode
From: Rio Liu @ 2026-04-14 5:02 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: linux-wireless@vger.kernel.org, johannes@sipsolutions.net,
benjamin.berg@intel.com
In-Reply-To: <7h5kwW8K-FIgMb5P9VQ1BwuECi1JtpQP3RNBytb3F0k2g6DtBAnz65o1smDvWOr2ag9Kla-YpMSGyN1NsU7yYslLU-K9NCyTAxjyx-PEEF8=@r26.me>
Some AP advertise 3 or 4 spatial stream MCS indexes in their basic
HT-MCS set. On cards with lower (2x2) spatial streams, the check would
fail, and we'd be stuck with no HT when it in fact work fine with
2-stream rate. This change makes it so the check is only performed in
strict mode.
Signed-off-by: Rio Liu <rio@r26.me>
---
My previous mail is showing up as empty on LKML for some reason.
Apologies for that, trying again.
There has been some reports that WIFI speed is capped on some routers:
Link: https://linuxcommunity.io/t/intel-ax210-speeds-capped-at-20-mbps-on-multiple-distros/6708/28
Link: https://bbs.archlinux.org/viewtopic.php?id=312952
Link: https://bbs.archlinux.org/viewtopic.php?id=313033
Link: https://www.reddit.com/r/Rogers/comments/1s89j9f/xb8_5ghz_dfs_channel_broadcasting_at_54_mbps/
Link: https://www.reddit.com/r/Comcast_Xfinity/comments/1s7fc3f/recent_firmware_update_to_wifi_gateway_breaking/
Link: https://www.reddit.com/r/Comcast_Xfinity/comments/1sg9r6z/slow_internet_for_linux_computers/
Apparently some APs advertises higher MIMO streams than the device
supports. In that case, HT-MCS check would fail and we fall back to
20MHz channel. A patch exists here that bypasses the check completely:
https://github.com/WoodyWoodster/mac80211-mcs-patch, and have been
reported to get 80MHz channel back.
This patch adds a check on STRICT flag before verifying HT MCS set from
the AP, similar to how it is done in ieee80211_verify_sta_vht_mcs_support.
---
net/mac80211/mlme.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 810bea1aacc5..0e33733ac634 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -419,6 +419,15 @@ ieee80211_verify_sta_ht_mcs_support(struct ieee80211_sub_if_data *sdata,
memcpy(&sta_ht_cap, &sband->ht_cap, sizeof(sta_ht_cap));
ieee80211_apply_htcap_overrides(sdata, &sta_ht_cap);
+ /*
+ * Some AP advertise 3 or 4 spatial stream MCS indexes in their basic HT-MCS
+ * set. On cards with lower (2x2) spatial streams, the check would fail, and
+ * we'd be stuck with no HT when it in fact work fine with 2-stream rate. So
+ * check it only in strict mode.
+ */
+ if (!ieee80211_hw_check(&sdata->local->hw, STRICT))
+ return true;
+
/*
* P802.11REVme/D7.0 - 6.5.4.2.4
* ...
--
base-commit: d65b175cfac64ee65506eea7fa573d291a9694ca
^ permalink raw reply related
* [PATCH] Skip ieee80211_verify_sta_ht_mcs_support check in non-strict mode
From: Rio Liu @ 2026-04-14 4:39 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: linux-wireless@vger.kernel.org, johannes@sipsolutions.net,
benjamin.berg@intel.com
Empty Message
^ permalink raw reply
* Re: [PATCH] wifi: rtw88: Add NULL check for chip->edcca_th
From: Panagiotis Petrakopoulos @ 2026-04-14 4:33 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless
In-Reply-To: <aa92a81841ec4d1da48916153e07f31d@realtek.com>
On Tue, Apr 14, 2026 at 5:03 AM Ping-Ke Shih <pkshih@realtek.com> wrote:
> > diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
> > index 48207052e3f8..c4819ef6d54d 100644
> > --- a/drivers/net/wireless/realtek/rtw88/fw.c
> > +++ b/drivers/net/wireless/realtek/rtw88/fw.c
> > @@ -284,6 +284,9 @@ static void rtw_fw_adaptivity_result(struct rtw_dev *rtwdev, u8 *payload,
> > result->density, result->igi, result->l2h_th_init, result->l2h,
> > result->h2l, result->option);
> >
> > + if (!edcca_th)
> > + return;> >
> As Bitterblue analysis, this might be a garbage, so I'd return at the entry
> of this function.
>
> > rtw_dbg(rtwdev, RTW_DBG_ADAPTIVITY, "Reg Setting: L2H %x H2L %x\n",
> > rtw_read32_mask(rtwdev, edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
> > edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask),
> > diff --git a/drivers/net/wireless/realtek/rtw88/phy.c b/drivers/net/wireless/realtek/rtw88/phy.c
> > index e2ac5c6fd500..c10eb28e54ad 100644
> > --- a/drivers/net/wireless/realtek/rtw88/phy.c
> > +++ b/drivers/net/wireless/realtek/rtw88/phy.c
> > @@ -161,6 +161,9 @@ void rtw_phy_set_edcca_th(struct rtw_dev *rtwdev, u8 l2h, u8 h2l)
> > {
> > const struct rtw_hw_reg_offset *edcca_th = rtwdev->chip->edcca_th;
> >
> > + if (!edcca_th)
> > + return;
> > +
>
> The callers of rtw_phy_set_edcca_th() are RTL8822B and RTL8822C, which both
> define rtwdev->chip->edcca_th. How can edcca_th be NULL?
>
> > rtw_write32_mask(rtwdev,
> > edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
> > edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask,
> > --
> > 2.53.0
>
Hello! Thanks for the swift review. It looks like the right call to
move the early return to the entry of the function given that the
values are corrupted. You're also right about rtw_phy_set_edcca_th. I
missed the callers. Upon checking, it's just the chips you mentioned.
I'll drop that for the v2
^ permalink raw reply
* RE: [PATCH] rtw88: add TX power limit support to 114 and 130 channels
From: Ping-Ke Shih @ 2026-04-14 3:57 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: Kalle Valo, Yan-Hsuan Chuang, linux-wireless@vger.kernel.org,
kernel-dev@igalia.com
In-Reply-To: <adzry4z-LLhfor4e@quatroqueijos.cascardo.eti.br>
Thadeu Lima de Souza Cascardo <cascardo@igalia.com> wrote:
> On Mon, Apr 13, 2026 at 05:56:17AM +0000, Ping-Ke Shih wrote:
> > Thadeu Lima de Souza Cascardo <cascardo@igalia.com> wrote:
> > > On Fri, Apr 10, 2026 at 03:56:11AM +0000, Ping-Ke Shih wrote:
> > > > Thadeu Lima de Souza Cascardo <cascardo@igalia.com> wrote:
> > > > > Though 114 and 130 are not usual channels, they are found in the wild with
> > > > > setups using 5350MHz as the center frequency of a 80MHz setup.
> > > >
> > > > What did the AP setup? channel 114 160MHz?
> > > > I wonder why rtw88 can select a not usual channel 114 80MHz.
> > > >
> > > > Please share your environment setup.
> > > >
> > >
> > > This is a Mikrotik that uses channel 130 at 80MHz.
> >
> > I'm surprised that an AP can work on this not usual channel/bandwidth.
> > Can you change the setting to usual channel/bandwidth? We'd avoid using
> > this unsupported channel/bandwidth by [1].
> >
>
> It seems to be "well-known" that some APs do it and it has caused other
> issues in other drivers. But it works just fine with a lot of other
> drivers. So, I would rather make rtw88 work with that setting, even if it
> falls back to 40MHz, for example.
>
> Let me check what happens when using the proposed patch and I will report
> back to you.
>
> > >
> > > > >
> > > > > rtw88 supports that, but issues a WARNING because it cannot find the TX
> > > > > power limit for those channels.
> > > >
> > > > Actually, rtw88 hardware can't support that, so we are working on patch
> > > > to avoid selecting unusual channels. Can it work properly with
> > > > the AP after this patch?
> > > >
> > >
> > > It does work just fine even without the patch. The only issue is the
> > > WARNING that is triggered.
> > >
> >
> > As internal discussion, hardware doesn't work on channel 130 80M,
> > which means connection might be well, but it can't yield expected performance.
> > More, the power limit is not really verified on ch130 80M, so we wonder
> > that the signal might not in expectation.
> >
>
> The rationale behing my patch was exactly to try to set the power limit to
> the lesser one of the adjacent channels.
The hardware setting of channel 130 80M is unknown, since we have never
verified that, so I can't say use the lesser one is always correct.
(Personally I'd make this choice if I have no more information from internal
hardware experts.)
> I am not sure that the expected
> performance was not achieved. How would you suggest that I verify?
I think you can check if RX rate is 80MHz or not. If it really works
properly on 80MHz, you can yield TX/RX UDP throughput about 0.7 *
PHY rates.
Ping-Ke
^ permalink raw reply
* RE: [PATCH v2 0/3] wifi: iwlwifi: mld: fix UAF and soft lockup on firmware error
From: Korenblit, Miriam Rachel @ 2026-04-14 3:51 UTC (permalink / raw)
To: Cole Leavitt, linux-wireless@vger.kernel.org
Cc: greearb@candelatech.com, johannes@sipsolutions.net
In-Reply-To: <20260405054145.1064152-1-cole@unwrap.rs>
> -----Original Message-----
> From: Cole Leavitt <cole@unwrap.rs>
> Sent: Sunday, April 5, 2026 8:42 AM
> To: linux-wireless@vger.kernel.org
> Cc: greearb@candelatech.com; Korenblit, Miriam Rachel
> <miriam.rachel.korenblit@intel.com>; johannes@sipsolutions.net;
> cole@unwrap.rs
> Subject: [PATCH v2 0/3] wifi: iwlwifi: mld: fix UAF and soft lockup on firmware
> error
>
> Three fixes for the iwlmld sub-driver addressing use-after-free, TSO segmentation
> explosion, and soft lockups during firmware error recovery on Intel BE200 (WiFi7).
>
> 1/3 closes the NAPI race window where stale RX data from dying firmware
> reaches the TX completion handlers, causing corrupt SSN values to trigger skb
> use-after-free in iwl_trans_reclaim().
> Ben Greear confirmed the WARN_ONCE fires on his test systems.
>
> 2/3 fixes the TSO segmentation explosion when AMSDU is disabled for a TID. The
> TLC notification sets max_tid_amsdu_len to the sentinel value 1, which slips past
> the existing zero check and produces num_subframes=0, causing
> skb_gso_segment() to create
> 32000+ tiny segments. Revised per Miriam Korenblit's feedback to
> check for the sentinel value directly and add a WARN_ON_ONCE guard after the
> division as defense-in-depth.
>
> 3/3 adds STATUS_FW_ERROR checks in the TX pull path to stop feeding frames to
> dead firmware. Revised per Johannes Berg's feedback to use status bit checks
> instead of stop_queues/wake_queues, which doesn't interact well with TXQ-
> based APIs.
Was the soft lockup happening after (as a consequence?) of the bug that you fixed in 2/3?
I am wondering why we didn't see it in mvm driver. I don't think we have such a guard there
>
> Changes since v1:
> - 1/3: Added Tested-by from Ben Greear
> - 2/3: Check max_tid_amsdu_len == 1 (sentinel) instead of
> guarding !num_subframes after division; added WARN_ON_ONCE
> defense-in-depth (Suggested-by: Miriam Korenblit)
> - 3/3: Replaced ieee80211_stop_queues()/wake_queues() with
> STATUS_FW_ERROR checks in TX pull path (per Johannes Berg)
>
> Cole Leavitt (3):
> wifi: iwlwifi: prevent NAPI processing after firmware error
> wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is
> disabled
> wifi: iwlwifi: mld: skip TX when firmware is dead
>
> .../net/wireless/intel/iwlwifi/mld/mac80211.c | 4 +
> drivers/net/wireless/intel/iwlwifi/mld/tx.c | 210 +++++------
> .../wireless/intel/iwlwifi/pcie/gen1_2/rx.c | 337 +++++++++---------
> 3 files changed, 284 insertions(+), 267 deletions(-)
>
>
> base-commit: 3aae9383f42f687221c011d7ee87529398e826b3
> --
> 2.52.0
^ permalink raw reply
* RE: [PATCH] wifi: rtw88: Add NULL check for chip->edcca_th
From: Ping-Ke Shih @ 2026-04-14 2:10 UTC (permalink / raw)
To: LB F, Panagiotis Petrakopoulos; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CALdGYqRLsPs8+kyAYphmKxfN9qF=1aGgn0O1LaASmjkDSUup_A@mail.gmail.com>
Hi Oleksandr,
LB F <goainwo@gmail.com> wrote:
> Ping-Ke, could you please take a look at this patch when you have a
> chance? If you approve the approach, I'll be happy to test it and
> provide a Tested-by.
I remember Bitterblue is still making a test patch, and this patch is one
to avoid garbage RX. If we can validate size or other clues at earlier of
RX data path, this malformed packet might not go into this function.
This reminds me, the patch getting merged to checking VHT rate seems to
be another clue of malformed packets. Maybe, we should just drop the
packets instead, which the content might be just a garbage.
Ping-Ke
^ permalink raw reply
* RE: [PATCH] wifi: rtw88: Add NULL check for chip->edcca_th
From: Ping-Ke Shih @ 2026-04-14 2:03 UTC (permalink / raw)
To: Panagiotis Petrakopoulos
Cc: linux-wireless@vger.kernel.org, goainwo@gmail.com,
Bitterblue Smith
In-Reply-To: <20260413100249.28618-1-npetrakopoulos2003@gmail.com>
+ Bitterblue
Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com> wrote:
> It was recently reported that rtw_fw_adaptivity_result
> in fw.c dereferences rtwdev->chip->edcca_th without
> a null check. The issue appears to be that devices
> with the 8821CE chip don't define edcca_th in their
> chip info. As a result, when rtw_fw_adaptivity_result
> tries to dereference it, the kernel triggers an oops.
>
> Add a NULL check for edcca_th before dereferencing
> it in rtw_fw_adaptivity_result() in fw.c and
> rtw_phy_set_edcca_th() in phy.c.
>
> Tested on a 8822CE chip which defines edcca_th, so
> this issue is not present on it, but it still uses
> this driver and I can verify there are no regressions.
>
> Reported-by: Oleksandr Havrylov <goainwo@gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286
> Link:
> https://lore.kernel.org/linux-wireless/CALdGYqQriS7mP0vj_rm_xvisfzFVh0hbpy+---48r6bodZO7tg@mail.gm
> ail.com/
> Signed-off-by: Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com>
> ---
> drivers/net/wireless/realtek/rtw88/fw.c | 3 +++
> drivers/net/wireless/realtek/rtw88/phy.c | 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
> index 48207052e3f8..c4819ef6d54d 100644
> --- a/drivers/net/wireless/realtek/rtw88/fw.c
> +++ b/drivers/net/wireless/realtek/rtw88/fw.c
> @@ -284,6 +284,9 @@ static void rtw_fw_adaptivity_result(struct rtw_dev *rtwdev, u8 *payload,
> result->density, result->igi, result->l2h_th_init, result->l2h,
> result->h2l, result->option);
>
> + if (!edcca_th)
> + return;
> +
As Bitterblue analysis, this might be a garbage, so I'd return at the entry
of this function.
> rtw_dbg(rtwdev, RTW_DBG_ADAPTIVITY, "Reg Setting: L2H %x H2L %x\n",
> rtw_read32_mask(rtwdev, edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
> edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask),
> diff --git a/drivers/net/wireless/realtek/rtw88/phy.c b/drivers/net/wireless/realtek/rtw88/phy.c
> index e2ac5c6fd500..c10eb28e54ad 100644
> --- a/drivers/net/wireless/realtek/rtw88/phy.c
> +++ b/drivers/net/wireless/realtek/rtw88/phy.c
> @@ -161,6 +161,9 @@ void rtw_phy_set_edcca_th(struct rtw_dev *rtwdev, u8 l2h, u8 h2l)
> {
> const struct rtw_hw_reg_offset *edcca_th = rtwdev->chip->edcca_th;
>
> + if (!edcca_th)
> + return;
> +
The callers of rtw_phy_set_edcca_th() are RTL8822B and RTL8822C, which both
define rtwdev->chip->edcca_th. How can edcca_th be NULL?
> rtw_write32_mask(rtwdev,
> edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
> edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask,
> --
> 2.53.0
^ 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