* Re: [PATCH 2/2] wifi: ath12k: skip unknown direct buffer ring module IDs
From: Jeff Johnson @ 2026-05-11 19:02 UTC (permalink / raw)
To: Nazar Mokrynskyi, ath12k; +Cc: linux-wireless
In-Reply-To: <20260505172415.566328-3-nazar@mokrynskyi.com>
On 5/5/2026 10:24 AM, Nazar Mokrynskyi wrote:
> The firmware may advertise direct buffer ring capabilities for module
> IDs beyond what the driver currently knows about (WMI_DIRECT_BUF_MAX).
> This happens with newer firmware versions that support additional ring
> types not yet implemented in the driver.
What "newer firmware version" are you using that has this issue?
Can you share the "Skipping unknown direct buf ring module id" logs from your
modified driver?
>
> The current code treats an unknown module_id as a fatal error, returning
> -EINVAL and tearing down the entire driver initialization. This is
> incorrect: the driver only needs to set up rings for types it uses
> (SPECTRAL=0, CFR=1) and can safely ignore capability advertisements for
> unknown types.
>
> Change the unknown module_id handling to skip the entry with a debug
> message rather than failing, allowing initialization to proceed.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
> ---
> drivers/net/wireless/ath/ath12k/wmi.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
> index 484fdd3b1..0e776a8d8 100644
> --- a/drivers/net/wireless/ath/ath12k/wmi.c
> +++ b/drivers/net/wireless/ath/ath12k/wmi.c
> @@ -4814,10 +4814,10 @@ static int ath12k_wmi_dma_ring_caps(struct ath12k_base *ab,
> dir_buff_caps = ab->db_caps;
> for (i = 0; i < dma_caps_parse->n_dma_ring_caps; i++) {
> if (le32_to_cpu(dma_caps[i].module_id) >= WMI_DIRECT_BUF_MAX) {
> - ath12k_warn(ab, "Invalid module id %d\n",
> - le32_to_cpu(dma_caps[i].module_id));
> - ret = -EINVAL;
> - goto free_dir_buff;
> + ath12k_dbg(ab, ATH12K_DBG_WMI,
> + "Skipping unknown direct buf ring module id %d\n",
> + le32_to_cpu(dma_caps[i].module_id));
> + continue;
by continuing you don't populate the dir_buff_caps[i] information below,
leaving that record with zeroed data from the initial allocation. Does other
code correctly handle that?
would it be better to have a separate count of the number of dir_buff_caps
records that are actually filled, and then update
dma_caps_parse->n_dma_ring_caps to match once the parsing has completed?
> }
>
> dir_buff_caps[i].id = le32_to_cpu(dma_caps[i].module_id);
> @@ -4829,10 +4829,6 @@ static int ath12k_wmi_dma_ring_caps(struct ath12k_base *ab,
> }
>
> return 0;
> -
> -free_dir_buff:
> - ath12k_wmi_free_dbring_caps(ab);
> - return ret;
> }
>
> static void
^ permalink raw reply
* Re: [PATCH v3 0/3] Add str_alloc_free() helper
From: Kees Cook @ 2026-05-11 19:31 UTC (permalink / raw)
To: Johannes Berg
Cc: Jiazi Li, Andy Shevchenko, Ping-Ke Shih, Julia Lawall,
Nicolas Palix, linux-hardening, linux-wireless
In-Reply-To: <fe81137b849e349bd9b0529c7e0e4be6b4099a5b.camel@sipsolutions.net>
On Thu, May 07, 2026 at 01:10:03PM +0200, Johannes Berg wrote:
> On Thu, 2026-05-07 at 19:03 +0800, Jiazi Li wrote:
> > Currently finds 4 locations:
> > ./drivers/net/wireless/realtek/rtw89/fw.c:2557:7-12: opportunity for str_alloc_free(valid)
> > ./drivers/net/wireless/realtek/rtw89/fw.c:2693:7-12: opportunity for str_alloc_free(valid)
> > ./drivers/android/tests/binder_alloc_kunit.c:196:6-21: opportunity for str_alloc_free(alloc -> pages [ i ])
> > ./mm/slub.c:1634:3-8: opportunity for str_alloc_free(alloc)
>
> It's what, three characters shorter for four users each? Is there really
> much point?
>
> Reading just the name also is really confusing - yes it lines up with
> str_assert_deassert, but "alloc_free" really doesn't seem very obvious -
> why would you alloc and free a string in one function call?
Yeah, there seems to only be 1 source file instance of this? I don't
think this needs the entire helper infrastructure.
--
Kees Cook
^ permalink raw reply
* Re: [PATCH 2/3] [v5 net-next] p54spi: convert to devicetree
From: Arnd Bergmann @ 2026-05-11 19:45 UTC (permalink / raw)
To: Simon Horman, Arnd Bergmann
Cc: Netdev, Aaro Koskinen, Andreas Kemnade, Bartosz Golaszewski,
Benoît Cousson, David S . Miller, Dmitry Torokhov,
Eric Dumazet, Felipe Balbi, Jakub Kicinski, Johannes Berg,
Kevin Hilman, krzk+dt, Linus Walleij, Paolo Abeni, Rob Herring,
Roger Quadros, Tony Lindgren, linux-wireless, devicetree,
linux-kernel, linux-arm-kernel, open list:GPIO SUBSYSTEM,
Linux-OMAP, Krzysztof Kozlowski
In-Reply-To: <20260511161243.49098-3-horms@kernel.org>
On Mon, May 11, 2026, at 18:12, Simon Horman wrote:
>
> Simon says: As a pre-existing issue I don't think we need to be concerned
> about this in the scope of this patch-set. But it may
> be a potential for follow-up.
>
> This problem wasn't introduced by this patch, but I noticed a pre-existing
> issue in the context here. Does the p54spi_spi_read() function perform an SPI
> transfer using a stack-allocated buffer?
>
> Looking at p54spi_spi_read(), the addr variable is allocated on the stack and
> passed as a transfer buffer to spi_sync(). The SPI framework maps transfer
> buffers for DMA. Passing a stack-allocated buffer is illegal, particularly with
> CONFIG_VMAP_STACK enabled, because stack memory resides in vmalloc space and
> cannot be safely DMA-mapped.
>
> Could this cause memory corruption or a kernel panic during the transfer?
I already commented on this earlier: This is indeed a theoretical
bug, but it works in practice because DMA-capable SPI controllers
tend to all use MMIO for short transfers instead of DMA.
SPI is very fragile this way, and I do have some patches to improve
that overall, but it seems out of scope for this one driver.
>> -
>> - gpio_direction_output(p54spi_gpio_power, 0);
>> - gpio_direction_input(p54spi_gpio_irq);
>> -
>> - ret = request_irq(gpio_to_irq(p54spi_gpio_irq),
>> - p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi",
>> - priv->spi);
>> + ret = request_irq(spi->irq, p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi", priv->spi);
>
> Simon says: This one seems more concerning in the context of this patch-set.
>
> Is there missing validation for spi->irq before calling request_irq()?
>
> If the device tree node lacks an interrupts property, the SPI core may set
> spi->irq to 0 or a negative error code.
>
> Passing this directly to request_irq() without validation can successfully
> hijack a core system interrupt like the system timer on some architectures,
> leading to system instability or deadlocks.
>
> Should there be a check like if (spi->irq <= 0) to fail the probe gracefully?
I also commented on this: request_irq() already fails gracefully
with -EINVAL when presented with an invalid IRQ. IRQ 0 is guaranteed
to be invalid on any target that uses devicetree.
Arnd
^ permalink raw reply
* Re: [PATCH rtw-next v2 1/1] wifi: rtw89: usb: Support switching to USB 3 mode
From: Devin Wittmayer @ 2026-05-11 20:03 UTC (permalink / raw)
To: rtl8821cerfe2, linux-wireless
Cc: pkshih, johannes, linux-kernel, Devin Wittmayer
In-Reply-To: <639b2f23-bff3-400f-b5ef-e7d0c39196bc@gmail.com>
On Mon, 2026-05-11 at 21:14 +0300, Bitterblue Smith wrote:
> Are you quite sure you tested this?
Yes. Full test matrix is in the v2 cover letter (PATCH 0/1) of
this series:
- DWA-X1850 A1 / B1 (RTL8852AU)
- BrosTrend AX1L / AX4L (RTL8852BU)
- BrosTrend AX8L / EDUP AXE5400 (RTL8852CU)
Six adapters, x86_64 Tiger Lake xHCI + aarch64 BCM2712 / RP1 hosts.
60 plug-cycles + 30+ throughput cells captured 2026-04-11 to
2026-05-07. USB enumeration verified at SuperSpeed (5000 Mbps) on
every patched cell.
Per-cell raw evidence for the May 2026 expanded matrix (40 iperf3
JSON files per cell, byte-counter deltas, pre/post link state,
pre/post USB enumeration speeds, per-iteration timestamps) at:
https://github.com/Lucid-Duck/rtw89-usb3-gap/tree/main/evidence/may-2026-laptop
Per-adapter summaries:
https://github.com/Lucid-Duck/rtw89-usb3-gap/tree/main/adapters
If the Tested-by trailer should be annotated with the specific chip
list, I will add that when, and if, a v3 is needed.
Devin
^ permalink raw reply
* Re: [PATCH 2/2] wifi: ath12k: skip unknown direct buffer ring module IDs
From: Nazar Mokrynskyi @ 2026-05-11 20:10 UTC (permalink / raw)
To: Jeff Johnson, ath12k; +Cc: linux-wireless
In-Reply-To: <89f30996-3210-403b-8c9a-52cf6d5fcb51@oss.qualcomm.com>
11.05.26 22:02, Jeff Johnson:
> On 5/5/2026 10:24 AM, Nazar Mokrynskyi wrote:
>> The firmware may advertise direct buffer ring capabilities for module
>> IDs beyond what the driver currently knows about (WMI_DIRECT_BUF_MAX).
>> This happens with newer firmware versions that support additional ring
>> types not yet implemented in the driver.
> What "newer firmware version" are you using that has this issue?
>
> Can you share the "Skipping unknown direct buf ring module id" logs from your
> modified driver?
ID is the same as in the original warning:
[ 10.611560] ath12k_pci 0000:01:00.0: Invalid module id 2
[ 10.616467] ath12k_pci 0000:01:00.0: failed to parse tlv -22
The firmware according to system logs (all this info is provided in [PATCH 0/2] email):
[ 7.688137] ath12k_pci 0000:01:00.0: fw_version 0x160484db fw_build_timestamp 2025-12-09 20:09 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
This is running on OpenWRT 25.12, which uses 6.12.74 kernel with modules backported from 6.18.7 kernel:
[ 0.000000] Linux version 6.12.74 (builder@buildhost) (x86_64-openwrt-linux-musl-gcc (OpenWrt GCC 14.3.0 r32802-f505120278) 14.3.0, GNU ld (GNU Binutils) 2.44) #0 SMP Wed Mar 25 20:09:53 2026
[ 6.997293] Loading modules backported from Linux version v6.18.7-0-g5dfbc5357
[ 6.999210] Backport generated by backports.git c8a37ce
>> The current code treats an unknown module_id as a fatal error, returning
>> -EINVAL and tearing down the entire driver initialization. This is
>> incorrect: the driver only needs to set up rings for types it uses
>> (SPECTRAL=0, CFR=1) and can safely ignore capability advertisements for
>> unknown types.
>>
>> Change the unknown module_id handling to skip the entry with a debug
>> message rather than failing, allowing initialization to proceed.
>>
>> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>>
>> Signed-off-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
>> ---
>> drivers/net/wireless/ath/ath12k/wmi.c | 12 ++++--------
>> 1 file changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
>> index 484fdd3b1..0e776a8d8 100644
>> --- a/drivers/net/wireless/ath/ath12k/wmi.c
>> +++ b/drivers/net/wireless/ath/ath12k/wmi.c
>> @@ -4814,10 +4814,10 @@ static int ath12k_wmi_dma_ring_caps(struct ath12k_base *ab,
>> dir_buff_caps = ab->db_caps;
>> for (i = 0; i < dma_caps_parse->n_dma_ring_caps; i++) {
>> if (le32_to_cpu(dma_caps[i].module_id) >= WMI_DIRECT_BUF_MAX) {
>> - ath12k_warn(ab, "Invalid module id %d\n",
>> - le32_to_cpu(dma_caps[i].module_id));
>> - ret = -EINVAL;
>> - goto free_dir_buff;
>> + ath12k_dbg(ab, ATH12K_DBG_WMI,
>> + "Skipping unknown direct buf ring module id %d\n",
>> + le32_to_cpu(dma_caps[i].module_id));
>> + continue;
> by continuing you don't populate the dir_buff_caps[i] information below,
> leaving that record with zeroed data from the initial allocation. Does other
> code correctly handle that?
>
> would it be better to have a separate count of the number of dir_buff_caps
> records that are actually filled, and then update
> dma_caps_parse->n_dma_ring_caps to match once the parsing has completed?
I'm very far from kernel development, let alone ath12k driver specifically.
The patch is provided to better showcase the problems I had.
If there is a better way to address it, I'd really appreciate if someone more knowledgeable could take over, I just hope this is helpful.
With these changes QCN9274 runs an access point with over 3 weeks uptime as of right now.
That is not necessary the proof of anything, but it does seem to work in practice so far.
>> }
>>
>> dir_buff_caps[i].id = le32_to_cpu(dma_caps[i].module_id);
>> @@ -4829,10 +4829,6 @@ static int ath12k_wmi_dma_ring_caps(struct ath12k_base *ab,
>> }
>>
>> return 0;
>> -
>> -free_dir_buff:
>> - ath12k_wmi_free_dbring_caps(ab);
>> - return ret;
>> }
>>
>> static void
^ permalink raw reply
* [PATCH AUTOSEL 7.0-5.15] wifi: nl80211: re-check wiphy netns in nl80211_prepare_wdev_dump() continuation
From: Sasha Levin @ 2026-05-11 22:19 UTC (permalink / raw)
To: patches, stable
Cc: Maoyi Xie, Johannes Berg, Sasha Levin, johannes, davem, edumazet,
kuba, pabeni, linux-wireless, netdev, linux-kernel
In-Reply-To: <20260511221931.2370053-1-sashal@kernel.org>
From: Maoyi Xie <maoyi.xie@ntu.edu.sg>
[ Upstream commit 79240f3f6d766b342b57c32397d643e1cfa26b81 ]
NL80211_CMD_GET_SCAN is implemented as a multi-call dumpit. The first
invocation of nl80211_prepare_wdev_dump() validates the requested wdev
against the caller's netns via __cfg80211_wdev_from_attrs(). Subsequent
invocations look up the same wiphy by its global index and do not check
that the wiphy is still in the caller's netns.
Add the same filter to the continuation path. If the wiphy's netns no
longer matches the caller's, return -ENODEV and the netlink dump
machinery terminates the walk cleanly.
Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Link: https://patch.msgid.link/20260506064854.2207105-3-maoyixie.tju@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase Walkthrough
**Phase 1: Commit Message Forensics**
- Step 1.1 Record: Subsystem `wifi: nl80211`; action verb `re-check`;
intent is to revalidate the wiphy net namespace during
`nl80211_prepare_wdev_dump()` continuation.
- Step 1.2 Record: Tags are `Signed-off-by: Maoyi Xie`, `Link: https://p
atch.msgid.link/20260506064854.2207105-3-maoyixie.tju@gmail.com`,
`Signed-off-by: Johannes Berg`. No `Fixes`, `Reported-by`, `Tested-
by`, `Reviewed-by`, `Acked-by`, or `Cc: stable`.
- Step 1.3 Record: The committed message says first dump invocation
validates via `__cfg80211_wdev_from_attrs()`, but later invocations
recover the wiphy by global index and lacked a netns check. The v3
mailing-list patch further states the failure mode: BSS scan data can
continue being copied from a wiphy after it moved to another netns.
- Step 1.4 Record: This is a hidden security/correctness fix, not a
cleanup. It fixes a namespace isolation race in a multi-call netlink
dump.
**Phase 2: Diff Analysis**
- Step 2.1 Record: One file changed, `net/wireless/nl80211.c`; commit
stat is 12 insertions. One function changed:
`nl80211_prepare_wdev_dump()`. Scope is single-file surgical.
- Step 2.2 Record: Before, continuation path did
`wiphy_idx_to_wiphy(cb->args[0] - 1)`, accepted the wiphy, then
searched `wdev_list`. After, it returns `-ENODEV` if
`!net_eq(wiphy_net(wiphy), sock_net(cb->skb->sk))`.
- Step 2.3 Record: Bug category is race / namespace isolation /
information disclosure. A wiphy can move netns between dumpit calls
via `NL80211_CMD_SET_WIPHY_NETNS`.
- Step 2.4 Record: Fix quality is high: one predicate and clean error
return before taking `wiphy.mtx`. Regression risk is low; it only
rejects a continuation whose object no longer belongs to the caller’s
netns.
**Phase 3: Git History**
- Step 3.1 Record: Current checkout is shallow; `git blame` attributed
the region to a shallow boundary, so that blame is not reliable.
Pickaxe history found the continuation-by-global-wiphy-index pattern
in old history, including `c319d50bfcf67` (`nl80211: fix another
nl80211_fam.attrbuf race`), contained by `v3.11-rc6`. Netns support
for cfg80211/nl80211 was introduced by `463d018323851`, contained by
`v2.6.32-rc1`.
- Step 3.2 Record: No `Fixes:` tag, so no tagged introducer to follow.
- Step 3.3 Record: Fetched wireless history shows the candidate
immediately follows companion commit `15994bb0cbb8f` (`wifi: nl80211:
require CAP_NET_ADMIN over the target netns in SET_WIPHY_NETNS`). No
intermediate commit between them.
- Step 3.4 Record: Author has only these two fetched wireless commits.
Committer is Johannes Berg, the nl80211/cfg80211 maintainer.
- Step 3.5 Record: No compile dependency on the companion commit, but
logical/security context is stronger if `15994bb0cbb8f` is backported
too.
**Phase 4: Mailing List / External Research**
- Step 4.1 Record: `b4 dig -c 79240f3f6d766...` found the v3 patch at
the provided `patch.msgid.link` URL. `b4 dig -a` found v1 and v3; `b4
am` showed v1, v2, v3. v3 cover says no code changes since v2 and that
Johannes review caused comment/trailer cleanup.
- Step 4.2 Record: `b4 dig -w` shows Johannes Berg, `linux-wireless`,
and `linux-kernel` were included.
- Step 4.3 Record: No syzbot/bugzilla report. The series cover and patch
body provide the bug explanation and patch 1 includes a mac80211_hwsim
reproducer for the related `SET_WIPHY_NETNS` privilege path.
- Step 4.4 Record: This is patch 2/2 in a series. Patch 1 hardens
target-netns capability checks; patch 2 fixes dump continuation
filtering.
- Step 4.5 Record: Lore WebFetch was blocked by Anubis; WebSearch did
not find stable-specific discussion.
**Phase 5: Code Semantic Analysis**
- Step 5.1 Record: Modified function is `nl80211_prepare_wdev_dump()`.
- Step 5.2 Record: Exact callers are `nl80211_dump_station()`,
`nl80211_dump_mpath()`, `nl80211_dump_mpp()`, `nl80211_dump_scan()`,
and `nl80211_dump_survey()`.
- Step 5.3 Record: Key callees are `__cfg80211_wdev_from_attrs()`,
`wiphy_idx_to_wiphy()`, `wiphy_net()`, `sock_net()`, `net_eq()`,
`wiphy_to_rdev()`, and list walk over `wiphy.wdev_list`.
- Step 5.4 Record: `NL80211_CMD_GET_SCAN` maps to `nl80211_dump_scan()`
and has no admin flag in the ops entry; `NL80211_CMD_SET_WIPHY_NETNS`
maps to `nl80211_wiphy_netns()` with `GENL_UNS_ADMIN_PERM`.
- Step 5.5 Record: Similar dump paths `nl80211_dump_wiphy()` and
`nl80211_dump_interface()` already filter by `net_eq(wiphy_net(...),
sock_net(skb->sk))` each iteration.
**Phase 6: Stable Tree Analysis**
- Step 6.1 Record: The affected continuation code exists in checked tags
`v6.19`, `v6.18`, `v6.12`, `v6.6`, `v6.1`, `v5.15`, `v5.10`, `v5.4`,
`v4.19`, and `v4.14`.
- Step 6.2 Record: Modern stable trees have the same helper shape. Older
trees such as `v5.4` and `v4.14` have different function
signatures/locking, so they may need small backport adjustment.
- Step 6.3 Record: Searches in checked stable tags did not find this
candidate or the companion commit already present.
**Phase 7: Subsystem Context**
- Step 7.1 Record: Subsystem is wireless cfg80211/nl80211, an important
networking control-plane subsystem.
- Step 7.2 Record: `net/wireless/nl80211.c` is actively maintained;
fetched wireless history shows this series was taken through Johannes
Berg’s wireless tree.
**Phase 8: Impact / Risk**
- Step 8.1 Record: Affected users are systems using wireless devices
with nl80211 netns movement support, including delegated/container
wireless setups and mac80211_hwsim.
- Step 8.2 Record: Trigger requires a multi-call dump and a wiphy netns
move between invocations. The related series verifies an unprivileged
userns path when the caller has a delegated `WIPHY_FLAG_NETNS_OK`
wiphy.
- Step 8.3 Record: Failure mode is namespace isolation breach / cross-
netns scan-result exposure, not a crash. Severity: HIGH due
security/isolation impact.
- Step 8.4 Record: Benefit is high for isolation correctness; risk is
very low because the patch adds one local validation and returns an
existing error code.
**Phase 9: Final Synthesis**
- Step 9.1 Record: Evidence for backporting: real namespace isolation
bug, old code present across stable trees, small surgical fix,
maintainer-applied, aligns with existing dump filtering. Evidence
against: companion patch should also be considered, and older trees
may require minor backport edits. Unresolved: no independent `Tested-
by`; stable-specific lore discussion could not be fetched.
- Step 9.2 Record: Stable rules: obviously correct yes; fixes real bug
yes; important issue yes due namespace isolation/security; small and
contained yes; no new API/feature yes; applies cleanly or with minor
adjustment depending on tree.
- Step 9.3 Record: No exception category applies.
- Step 9.4 Record: Backport is warranted, preferably together with
`15994bb0cbb8f` for the complete netns hardening series.
## Verification
- Phase 1: Parsed `git show 79240f3f6d766...` and b4 v3 patch text;
verified tags and commit body.
- Phase 2: Verified diff is one hunk in `nl80211_prepare_wdev_dump()`
with 12 insertions.
- Phase 3: Ran `git blame`, pickaxe history, `git show` for
`c319d50bfcf67`, `463d018323851`, companion `15994bb0cbb8f`, and
fetched wireless history.
- Phase 4: Ran `b4 dig`, `b4 dig -a`, `b4 dig -w`, `b4 am` for v1/v2/v3,
saved/read mbox; WebFetch to lore was blocked by Anubis.
- Phase 5: Verified callers and relevant ops entries in
`net/wireless/nl80211.c`.
- Phase 6: Used `git grep` across stable tags to confirm affected code
exists and checked stable logs for absence of the candidate.
- Phase 8: Severity is based on verified patch text plus code paths; no
build or runtime test was run.
**YES**
net/wireless/nl80211.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b94231c8441c4..ce3121b1c3319 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1146,6 +1146,18 @@ static int nl80211_prepare_wdev_dump(struct netlink_callback *cb,
rtnl_unlock();
return -ENODEV;
}
+
+ /*
+ * The first invocation validated the wdev's netns against
+ * the caller via __cfg80211_wdev_from_attrs(). The wiphy
+ * may have moved netns between dumpit invocations (via
+ * NL80211_CMD_SET_WIPHY_NETNS), so re-check here.
+ */
+ if (!net_eq(wiphy_net(wiphy), sock_net(cb->skb->sk))) {
+ rtnl_unlock();
+ return -ENODEV;
+ }
+
*rdev = wiphy_to_rdev(wiphy);
*wdev = NULL;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.10] wifi: libertas: fix integer underflow in process_cmdrequest()
From: Sasha Levin @ 2026-05-11 22:19 UTC (permalink / raw)
To: patches, stable
Cc: Amir Mohammad Jahangirzad, Johannes Berg, Sasha Levin, kvalo,
libertas-dev, linux-wireless, linux-kernel
In-Reply-To: <20260511221931.2370053-1-sashal@kernel.org>
From: Amir Mohammad Jahangirzad <a.jahangirzad@gmail.com>
[ Upstream commit 3994b4afd521d60e47e012fe2ed7b606aaec370b ]
The existing validation only checks if recvlength exceeds
LBS_CMD_BUFFER_SIZE, but doesn't check the lower bound. When a
USB device sends a response shorter than MESSAGE_HEADER_LEN, the
subtraction (recvlength - MESSAGE_HEADER_LEN) wraps to a huge
value, causing memcpy to corrupt the heap.
Add the same lower bound check that libertas_tf already has.
Signed-off-by: Amir Mohammad Jahangirzad <a.jahangirzad@gmail.com>
Link: https://patch.msgid.link/20260418004247.368944-1-a.jahangirzad@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase Walkthrough
### Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem is `wifi: libertas`; action verb is `fix`;
claimed intent is to prevent integer underflow in
`process_cmdrequest()`.
Step 1.2 Record: Tags present are `Signed-off-by: Amir Mohammad
Jahangirzad`, `Link: https://patch.msgid.link/20260418004247.368944-1-
a.jahangirzad@gmail.com`, and `Signed-off-by: Johannes Berg`. No
`Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by`, or
`Cc: stable` tag was present in the supplied commit message or original
posted patch.
Step 1.3 Record: The commit body describes a concrete memory corruption
bug: `recvlength` is only checked against the upper bound, then
`recvlength - MESSAGE_HEADER_LEN` is stored in `priv->resp_len[i]` and
used as the `memcpy()` length. If a USB device supplies fewer than 4
bytes, the subtraction becomes negative and is converted to a huge
unsigned copy length. Symptom/failure mode: heap/driver memory
corruption from `memcpy()`. Version information: none in the message.
Root cause: missing lower-bound validation.
Step 1.4 Record: This is not hidden; it is explicitly a memory-safety
fix. It matches the same already-present guard in `libertas_tf`.
### Phase 2: Diff Analysis
Step 2.1 Record: One file changed:
`drivers/net/wireless/marvell/libertas/if_usb.c`, 3 insertions and 2
deletions. Modified function: `process_cmdrequest()`. Scope: single-file
surgical fix.
Step 2.2 Record: Before, `process_cmdrequest()` rejected only
`recvlength > LBS_CMD_BUFFER_SIZE`; lengths `1..3` passed and produced
`recvlength - MESSAGE_HEADER_LEN`. After, it rejects `recvlength <
MESSAGE_HEADER_LEN` as well as overlarge responses. This affects the USB
command-response receive path.
Step 2.3 Record: Bug category is memory safety, specifically integer
underflow leading to oversized `memcpy()`. Verified details:
`MESSAGE_HEADER_LEN` is 4, `resp_len` is `u32`, `resp_buf` is `u8
resp_buf[2][LBS_UPLD_SIZE]`, and `LBS_UPLD_SIZE` is 2312. A negative
subtraction assigned to `u32` becomes a huge length, far beyond the
destination buffer.
Step 2.4 Record: Fix quality is high: minimal bounds check, no API
change, no new behavior except rejecting malformed command responses.
Regression risk is very low; valid command responses must already
include the 4-byte command type/header.
### Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the upper-bound check came from
`ddac452680a516` in the v2.6.25-rc1 era, and the `resp_len = recvlength
- MESSAGE_HEADER_LEN` plus `memcpy()` flow came from `7919b89c8276` in
the v2.6.26-rc1 era. This code is old and widely present.
Step 3.2 Record: No `Fixes:` tag is present in the candidate, so there
is no specific tagged introducing commit to follow. Blame nevertheless
identifies the relevant old code.
Step 3.3 Record: Recent file history includes unrelated cleanup/fix
commits such as `3968e81ba644` changing skb free placement and
`d66676e6ca96` fixing a warning in `usb_tx_block()`. I found no
prerequisite commit needed for this bounds check.
Step 3.4 Record: `git log --author='Amir Mohammad Jahangirzad'` found no
prior local commits in this Marvell wireless subtree. The final signoff
is from Johannes Berg; `MAINTAINERS` lists Johannes Berg as wireless
maintainer, while the Libertas driver itself is marked orphaned under
`linux-wireless` and `libertas-dev`.
Step 3.5 Record: Dependencies found: none. The patch uses existing local
constants and mirrors the already-existing `libertas_tf` check.
### Phase 4: Mailing List And External Research
Step 4.1 Record: No commit hash was available in local history, so `b4
dig -c` could not be used successfully; `b4 dig -c
20260418004247.368944-1-a.jahangirzad@gmail.com` failed because it
expects a commit. Fallback `b4 mbox` and the lore mirror found the
original patch at `https://yhbt.net/lore/lkml/20260418004247.368944-1-
a.jahangirzad@gmail.com/T/`. The thread has one message and no replies.
`b4 mbox -c` found no newer revision in the thread.
Step 4.2 Record: Original recipients included Johannes Berg, Kees Cook,
Ingo Molnar, Johan Hovold, `linux-wireless`, `libertas-dev`, and `linux-
kernel`. No reviewer replies, NAKs, or explicit stable nominations were
present in the fetched thread.
Step 4.3 Record: No `Reported-by` or bug-report link was present. I
found no separate public bug report for this exact issue. The message
itself provides the failure mechanism.
Step 4.4 Record: Related precedent exists: commit `3348ef6a6a126` fixed
the identical underflow in `libertas_tf: process_cmdrequest()`, with
message “If recvlength is less than MESSAGE_HEADER_LEN (4) we would end
up corrupting memory.” That analogous fix was later carried in stable
review postings for 4.19 and 3.16.
Step 4.5 Record: Web searches found the exact candidate posting and
stable history for the analogous `libertas_tf` fix, but no exact stable
discussion for this new `libertas` patch.
### Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `process_cmdrequest()`.
Step 5.2 Record: Caller is `if_usb_receive()`, reached as the receive
URB completion callback installed by `usb_fill_bulk_urb()` through
`if_usb_submit_rx_urb()`.
Step 5.3 Record: Key callees are `memcpy()`, `dev_kfree_skb_irq()`, and
`lbs_notify_command_response()`. The command response is later consumed
by the main thread through `lbs_process_command_response()`.
Step 5.4 Record: Reachability is verified through USB receive
completion: a Libertas USB device response with type `CMD_TYPE_REQUEST`
reaches `process_cmdrequest()`. The triggering input is device-
controlled USB receive data, so this is reachable with affected hardware
or a malicious/faulty USB device.
Step 5.5 Record: Similar pattern found in `libertas_tf`; that sibling
driver already has the exact lower-bound check. `if_sdio` and `if_spi`
use different response formats and do not subtract `MESSAGE_HEADER_LEN`
in the same way.
### Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: Representative tags `v3.16`, `v4.14`, `v4.19`, `v5.4`,
`v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, and newer `v6.13` through
`v6.17` all contain the buggy `process_cmdrequest()` pattern without the
lower-bound check. The bug dates back to at least the v2.6.26-rc1 era.
Step 6.2 Record: Expected backport difficulty is low for modern stable
trees: the same context is present in representative stable tags, and
`git apply --check` succeeds against the current tree. Very old trees
before the Marvell directory move may need path/context adjustment, as
verified by older tags using `drivers/net/wireless/libertas/if_usb.c`.
Step 6.3 Record: No exact related fix for `libertas` was found in local
history. The sibling `libertas_tf` fix exists and was stable-backported.
### Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is wireless driver code under
`drivers/net/wireless/marvell/libertas`. Criticality: driver-specific,
but memory corruption in a kernel USB receive path is high severity for
affected systems.
Step 7.2 Record: Subsystem activity is low-to-moderate; recent history
shows occasional fixes and cleanups. `MAINTAINERS` marks Marvell
Libertas as orphaned, with `linux-wireless` and `libertas-dev` lists.
### Phase 8: Impact And Risk Assessment
Step 8.1 Record: Affected population is config- and hardware-specific:
systems with `CONFIG_LIBERTAS_USB` and Marvell Libertas 8388 USB
devices, or systems exposed to a malicious USB device matching the
driver IDs.
Step 8.2 Record: Trigger condition is a USB command response shorter
than `MESSAGE_HEADER_LEN` but with `CMD_TYPE_REQUEST` dispatch. This is
device-controlled. I did not verify an unprivileged software-only
trigger; physical or device-level control is the verified trigger model.
Step 8.3 Record: Failure mode is heap/driver memory corruption from
oversized `memcpy()`. Severity: HIGH to CRITICAL, because kernel memory
corruption can crash the system and can have security implications.
Step 8.4 Record: Benefit is high for affected systems: prevents kernel
memory corruption from malformed USB responses. Risk is very low: 3-line
effective validation change in one driver function, with precedent in
sibling driver.
### Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: real memory corruption bug;
old code present across many stable release tags; tiny surgical fix; no
new API or feature; exact validation already used by `libertas_tf`;
analogous `libertas_tf` fix was stable-backported. Evidence against:
driver-specific and no external bug report or tested-by tag. Unresolved:
exact final upstream commit hash was not present in local history, so
`b4 dig -c <commit_hash>` could not be completed.
Step 9.2 Record:
1. Obviously correct and tested? Obviously correct by code inspection;
no explicit `Tested-by`.
2. Fixes a real bug? Yes, verified underflow into oversized `memcpy()`.
3. Important issue? Yes, kernel memory corruption.
4. Small and contained? Yes, one function in one file.
5. No new features/APIs? Yes.
6. Can apply to stable trees? Yes for modern representative tags with
likely clean/minor context; old pre-directory-move trees may need
path adjustment.
Step 9.3 Record: No exception category such as device ID, quirk, DT,
build, or docs applies. This is a direct memory-safety bug fix.
Step 9.4 Record: Stable backport decision is YES. The fix prevents
kernel memory corruption in an old, stable-present USB driver path with
extremely low regression risk.
## Verification
- Phase 1: Parsed supplied tags and fetched original patch thread with
`b4 mbox`; confirmed no `Fixes`, `Reported-by`, `Tested-by`,
`Reviewed-by`, `Acked-by`, or stable tag.
- Phase 2: Read `drivers/net/wireless/marvell/libertas/if_usb.c`,
`dev.h`, and `defs.h`; confirmed `MESSAGE_HEADER_LEN`, `resp_len`,
`resp_buf`, and `memcpy()` behavior.
- Phase 3: Ran `git blame` on `process_cmdrequest()`; identified old
introducing history around `ddac452680a516` and `7919b89c8276`.
- Phase 3: Ran `git describe --contains`; confirmed relevant code dates
to v2.6.25/v2.6.26-era history.
- Phase 4: `b4 dig` with the message-id failed because no local commit
hash was available; recorded as unresolved.
- Phase 4: `b4 mbox` fetched the patch thread; `b4 mbox -c` found one
message and no newer revision.
- Phase 4: Fetched lore mirror and stable archive pages; confirmed
analogous `libertas_tf` fix and stable review postings.
- Phase 5: Traced callers from `if_usb_receive()` through
`usb_fill_bulk_urb()` and `if_usb_submit_rx_urb()`.
- Phase 6: Checked release tags from `v3.16` through representative
active v6 tags; confirmed the buggy code exists broadly.
- Phase 6: Ran `git apply --check` against the current tree; patch
applies cleanly there.
- Phase 7: Checked `MAINTAINERS`; confirmed Libertas is orphaned under
wireless lists and Johannes Berg is listed for wireless maintenance.
- Phase 8: Verified trigger is USB device-controlled receive data; no
unprivileged software-only trigger was verified.
**YES**
drivers/net/wireless/marvell/libertas/if_usb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c b/drivers/net/wireless/marvell/libertas/if_usb.c
index 8a6bf1365cfab..42d3fd32ece28 100644
--- a/drivers/net/wireless/marvell/libertas/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas/if_usb.c
@@ -625,9 +625,10 @@ static inline void process_cmdrequest(int recvlength, uint8_t *recvbuff,
unsigned long flags;
u8 i;
- if (recvlength > LBS_CMD_BUFFER_SIZE) {
+ if (recvlength < MESSAGE_HEADER_LEN ||
+ recvlength > LBS_CMD_BUFFER_SIZE) {
lbs_deb_usbd(&cardp->udev->dev,
- "The receive buffer is too large\n");
+ "The receive buffer is invalid: %d\n", recvlength);
kfree_skb(skb);
return;
}
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.10] wifi: nl80211: require CAP_NET_ADMIN over the target netns in SET_WIPHY_NETNS
From: Sasha Levin @ 2026-05-11 22:19 UTC (permalink / raw)
To: patches, stable
Cc: Maoyi Xie, Johannes Berg, Sasha Levin, johannes, davem, edumazet,
kuba, pabeni, linux-wireless, netdev, linux-kernel
In-Reply-To: <20260511221931.2370053-1-sashal@kernel.org>
From: Maoyi Xie <maoyi.xie@ntu.edu.sg>
[ Upstream commit 15994bb0cbb8fc4879da7552ddd08c1896261c39 ]
NL80211_CMD_SET_WIPHY_NETNS dispatches with GENL_UNS_ADMIN_PERM, which
verifies that the caller has CAP_NET_ADMIN for the source netns. It
doesn't verify that the caller has CAP_NET_ADMIN over the target netns
selected by NL80211_ATTR_NETNS_FD or NL80211_ATTR_PID.
This diverges from the convention enforced in
net/core/rtnetlink.c::rtnl_get_net_ns_capable():
/* For now, the caller is required to have CAP_NET_ADMIN in
* the user namespace owning the target net ns.
*/
if (!sk_ns_capable(sk, net->user_ns, CAP_NET_ADMIN))
return ERR_PTR(-EACCES);
A user with CAP_NET_ADMIN in their own user namespace can therefore
push a wiphy into an arbitrary netns (including init_net) over which
they have no privilege.
Mirror the rtnetlink convention by requiring CAP_NET_ADMIN in the
target netns before calling cfg80211_switch_netns().
Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Link: https://patch.msgid.link/20260506064854.2207105-2-maoyixie.tju@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record: `wifi: nl80211` subsystem; action verb `require`; intent is to
require `CAP_NET_ADMIN` over the target network namespace before
`NL80211_CMD_SET_WIPHY_NETNS` moves a wiphy.
Record: Tags in the provided commit message:
`Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>`, `Link: https://patch.
msgid.link/20260506064854.2207105-2-maoyixie.tju@gmail.com`, `Signed-
off-by: Johannes Berg <johannes.berg@intel.com>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, or `Cc: stable` tag was
present in the provided message.
Record: The described bug is an authorization gap. `GENL_UNS_ADMIN_PERM`
verifies `CAP_NET_ADMIN` for the netlink socket/source netns, but
`NL80211_ATTR_NETNS_FD` / `NL80211_ATTR_PID` selects a target netns that
was not separately checked. The b4-fetched cover letter includes a
concrete reproducer with `mac80211_hwsim`: a caller privileged only in
its own user namespace can move a delegated wiphy back into `init_net`.
Record: This is not a hidden cleanup fix; it is an explicit
security/permission bug fix.
### Phase 2: Diff Analysis
Record: One file changed, `net/wireless/nl80211.c`, with 13 insertions
in `nl80211_wiphy_netns()`. Scope is a single-function surgical fix.
Record: Before: after resolving the target netns and checking
`IS_ERR(net)`, the function directly called `cfg80211_switch_netns()` if
the wiphy was not already in that netns. After: it first checks
`ns_capable(net->user_ns, CAP_NET_ADMIN)`, drops the netns reference
with `put_net(net)`, and returns `-EPERM` on failure.
Record: Bug category is security authorization / logic correctness. The
missing check allowed a source-netns-capable caller to affect a
different target netns without privilege there.
Record: Fix quality is high: small, localized, follows the verified
rtnetlink convention in `rtnl_get_net_ns_capable()`, and preserves
reference cleanup. Regression risk is low and limited to denying
previously accepted unauthorized cross-netns moves.
### Phase 3: Git History Investigation
Record: `git blame` on the current stable checkout blamed the function
body to a repository snapshot-style commit, so it was not useful for
introduction history. `git log v2.6.29..v2.6.32 -S...` found the
command/function introduced by `463d018323851` (`cfg80211: make aware of
net namespaces`), first contained in `v2.6.32-rc1`.
Record: No `Fixes:` tag is present, so there was no tagged commit to
follow.
Record: Recent local `net/wireless/nl80211.c` history showed unrelated
wireless fixes/conversions and no existing equivalent target-netns
capability fix.
Record: No local prior `Maoyi Xie` commits were found under
`net/wireless`. `MAINTAINERS` verifies Johannes Berg as maintainer for
`802.11 (including CFG80211/NL80211)`, and the patch was addressed to
Johannes on linux-wireless.
Record: No code dependency was found for this patch. It is patch 1/2 in
the submitted series; patch 2 is related namespace hardening, but patch
1 is standalone for the direct permission bypass.
### Phase 4: Mailing List And External Research
Record: No commit hash was provided and the exact subject was not found
in local `master`, `wireless-next`, `net-next`, or `fixes-next`, so `b4
dig -c <commit>` was not applicable. I used the provided message-id with
`b4 am`/`b4 mbox`.
Record: `b4 am` found `[PATCH v3 0/2] wifi: nl80211: tighten netns
handling in SET_WIPHY_NETNS and dump continuation`, including this patch
as `v3 1/2`. `b4 am -c` did not report a newer revision. Attempts to
fetch v1/v2 directly with `b4 -v 1/-v 2` did not find those revisions,
but the v3 cover records that patch 1 was unchanged since v1.
Record: The full mbox contained three messages: cover, patch 1, patch 2.
It did not contain reviewer reply messages, but the cover records
Johannes review feedback about trailers/comment wording and says no code
changes since v2.
Record: Original recipients were Johannes Berg, `linux-
wireless@vger.kernel.org`, and `linux-kernel@vger.kernel.org`. No stable
nomination or NAK was found in the fetched mbox. Lore WebFetch searches
were blocked by Anubis, so stable-list discussion could not be
independently verified through WebFetch.
### Phase 5: Code Semantic Analysis
Record: Modified function: `nl80211_wiphy_netns()`.
Record: Caller surface: the only direct reference is the generic-netlink
op for `NL80211_CMD_SET_WIPHY_NETNS`; `genl_family_rcv_msg()` checks
`GENL_UNS_ADMIN_PERM` against `net->user_ns`, then
`genl_family_rcv_msg_doit()` calls `ops->doit()`, reaching
`nl80211_wiphy_netns()` from userspace netlink.
Record: Key callees: `get_net_ns_by_pid()`, `get_net_ns_by_fd()`, new
`ns_capable(net->user_ns, CAP_NET_ADMIN)`, `cfg80211_switch_netns()`,
and `put_net()`. `cfg80211_switch_netns()` moves associated wireless
netdevs with `dev_change_net_namespace()` and updates `wiphy_net_set()`.
Record: Reachability is verified by the op table and by the b4 cover’s
PoC. A userspace caller can trigger the path by sending
`NL80211_CMD_SET_WIPHY_NETNS` with target PID or netns fd.
Record: Similar convention verified in `rtnl_get_net_ns_capable()`,
which checks target `net->user_ns` before using another netns.
### Phase 6: Stable Tree Analysis
Record: The vulnerable handler/op shape exists in `v5.4`, `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and current `7.0.y`, with no
`ns_capable(net->user_ns, CAP_NET_ADMIN)` check in the handler.
Record: `v3.18` has `NL80211_CMD_SET_WIPHY_NETNS`, but uses
`GENL_ADMIN_PERM`, so the unprivileged-user-namespace aspect is not the
same there. For active modern stable trees, the issue is present.
Record: `git apply --check` of the fetched v3 mbox succeeds on the
current `7.0.y` checkout. Older stable trees have line offsets and minor
surrounding differences, but the same local hunk context exists at least
in `v5.4`; expected backport difficulty is clean or minor-context-only.
Record: No related local fix already present was found by subject/grep
searches.
### Phase 7: Subsystem Context
Record: Subsystem is cfg80211/nl80211 wireless configuration.
Criticality is IMPORTANT: it is not core-mm/VFS, but it is a userspace-
facing network configuration and permission boundary.
Record: The wireless subsystem is active in local history, with recent
cfg80211/nl80211-adjacent fixes.
### Phase 8: Impact And Risk
Record: Affected users are systems with cfg80211/nl80211, network
namespaces/user namespaces, and a `WIPHY_FLAG_NETNS_OK` wiphy. Verified
examples include `mac80211` and drivers setting the flag such as
`brcmfmac`, `mwifiex`, and `qtnfmac`.
Record: Trigger requires the caller to hold a movable wiphy in its own
netns and pass a target netns fd or pid. The b4 cover verifies this is
reachable from an unprivileged user namespace after legitimate admin
delegation using `mac80211_hwsim`.
Record: Failure mode is a security/namespace isolation violation:
unauthorized movement of a wiphy into a netns, including `init_net`,
where the caller lacks privilege. Severity is HIGH because it bypasses
kernel namespace permission boundaries.
Record: Benefit is high for stable users because it closes a concrete
privilege boundary bug. Risk is low: 13 lines, one function, no new API,
no data structure change, and only unauthorized operations change
behavior.
### Phase 9: Final Synthesis
Record: Evidence for backporting: real security/authorization bug,
concrete PoC in the submitted cover, reachable userspace netlink
command, vulnerable code present across modern stable trees, small
contained fix, and it mirrors an existing rtnetlink convention.
Record: Evidence against backporting: no `Fixes:`/stable tag, no fetched
reviewer reply carrying an explicit stable nomination, and the exact
applied commit hash was not present in local searched branches. These do
not outweigh the verified technical issue.
Record: Unresolved: I could not verify the final applied commit object
or run `b4 dig -c` because no commit hash was provided and local branch
searches did not find the subject. WebFetch to lore/stable was blocked
by Anubis. I did not run the runtime PoC or a kernel build.
Stable rules checklist:
1. Obviously correct and tested: yes by inspection; PoC result described
in b4 cover, though not locally rerun.
2. Fixes a real bug affecting users: yes, verified missing target-netns
authorization.
3. Important issue: yes, security/namespace permission bypass.
4. Small and contained: yes, one function, 13 added lines.
5. No new features or APIs: yes.
6. Can apply to stable: yes for current `7.0.y`; older active stable
trees likely clean/minor context based on matching code.
Exception category: none. This is not a device ID/quirk/build/doc fix;
it is a security permission fix.
## Verification
- [Phase 1] Parsed provided subject/tags and b4-fetched patch/cover;
found no `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, or
stable tag.
- [Phase 2] Compared provided diff and b4 mbox patch; confirmed 13 lines
added to `nl80211_wiphy_netns()`.
- [Phase 3] `git blame -L` was not useful due snapshot-style history;
`git log v2.6.29..v2.6.32 -S...` found `463d018323851`, first
contained in `v2.6.32-rc1`.
- [Phase 3] `git log --author='Maoyi Xie' -- net/wireless` found no
local prior commits.
- [Phase 3] `MAINTAINERS` confirms Johannes Berg maintains `802.11
(including CFG80211/NL80211)`.
- [Phase 4] `b4 am` found v3 2-patch series and the supplied patch
message-id.
- [Phase 4] `b4 am -c` found no newer revision.
- [Phase 4] `b4 mbox` saved the full 3-message thread; no stable
nomination or NAK was present there.
- [Phase 5] `rg` confirmed `nl80211_wiphy_netns()` is reached via the
`NL80211_CMD_SET_WIPHY_NETNS` generic-netlink op.
- [Phase 5] Read `genetlink.c`; confirmed `GENL_UNS_ADMIN_PERM` checks
`net->user_ns` before calling `ops->doit()`.
- [Phase 5] Read `cfg80211_switch_netns()`; confirmed it moves wireless
netdevs and changes the wiphy netns.
- [Phase 6] Checked `v5.4`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
`v6.19`, and current `7.0.y`; all have the handler/op without the
target `ns_capable()` check.
- [Phase 6] `git apply --check` of the b4 mbox succeeded on current
`7.0.y`.
- [Phase 8] `rg WIPHY_FLAG_NETNS_OK` verified affected mac80211 and
several wireless drivers expose movable wiphys.
- UNVERIFIED: exact final commit SHA and final applied-object metadata,
because the subject was not found in local searched branches.
- UNVERIFIED: stable-list discussion via WebFetch, because lore WebFetch
returned Anubis anti-bot pages.
- UNVERIFIED: local runtime PoC/build; not performed.
This should be backported to stable kernel trees that contain the
`GENL_UNS_ADMIN_PERM` version of `NL80211_CMD_SET_WIPHY_NETNS`,
especially active v5.4+ stable/LTS trees.
**YES**
net/wireless/nl80211.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ce3121b1c3319..13c2943ad3e4b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -13568,6 +13568,19 @@ static int nl80211_wiphy_netns(struct sk_buff *skb, struct genl_info *info)
if (IS_ERR(net))
return PTR_ERR(net);
+ /*
+ * The caller already has CAP_NET_ADMIN over the source netns
+ * (enforced by GENL_UNS_ADMIN_PERM on the genl op). Mirror the
+ * convention used by net/core/rtnetlink.c::rtnl_get_net_ns_capable()
+ * and require CAP_NET_ADMIN over the target netns as well, so that
+ * a caller that is privileged in their own user namespace cannot
+ * push a wiphy into a netns where they have no privilege.
+ */
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ put_net(net);
+ return -EPERM;
+ }
+
err = 0;
/* check if anything to do */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 1/3] Fix overread in PREQ frame processing
From: Masashi Honma @ 2026-05-11 22:25 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <725b56f42b5fec58196e4055bccb74236145986b.camel@sipsolutions.net>
> Oh sure, as far as I'm concerned there's no urgency, I just didn't want
> to keep asking you to make changes too much.
No problem. The code is getting better and better, so your reviews are very
welcome.
> Oh OK :) Maybe we need that as a kind of Reported-by? Hmm.
> Or you could send a separate bug report email, say there Claude found
> it, and then do a Closes: link :-p
Ha ha, no problem. I am happy to tag Claude because I wouldn't have even been
able to find this issue if I hadn't used an LLM.
2026年5月11日(月) 18:01 Johannes Berg <johannes@sipsolutions.net>:
>
> On Mon, 2026-05-11 at 17:58 +0900, Masashi Honma wrote:
> > > This isn't really right since u32_field_get() exists only within
> > > mesh_hwmp.c ... it's probably better to modernise all this while at it:
> >
> > Ah, yes. Both the build and tests passed, so I overlooked it.
>
> Yes, it would, but it's basically not self-contained. More of a code
> hygiene issue I guess than a real problem right now.
>
> > > and restructure the code accordingly?
> > > Anyway, I dunno. Maybe we should just go with your original patch for
> > > now. Maybe I'm also asking more of you than others because you have an
> > > LLM to help ;-)
> >
> > If it is not urgent, I would like to proceed with the requested restructuring.
>
> Oh sure, as far as I'm concerned there's no urgency, I just didn't want
> to keep asking you to make changes too much.
>
> > Actually, I only used the LLM to find potential vulnerabilities, and I wrote
> > the code myself :)
>
> Oh OK :) Maybe we need that as a kind of Reported-by? Hmm.
>
> Or you could send a separate bug report email, say there Claude found
> it, and then do a Closes: link :-p
>
> johannes
^ permalink raw reply
* Re: [PATCH rtw-next v2 1/1] wifi: rtw89: usb: Support switching to USB 3 mode
From: Bitterblue Smith @ 2026-05-11 22:27 UTC (permalink / raw)
To: Devin Wittmayer, linux-wireless; +Cc: pkshih, johannes, linux-kernel
In-Reply-To: <20260511200339.33682-1-lucid_duck@justthetip.ca>
On 11/05/2026 23:03, Devin Wittmayer wrote:
> On Mon, 2026-05-11 at 21:14 +0300, Bitterblue Smith wrote:
>> Are you quite sure you tested this?
>
> Yes. Full test matrix is in the v2 cover letter (PATCH 0/1) of
> this series:
>
Good, good. So how did you avoid the crash?
> - DWA-X1850 A1 / B1 (RTL8852AU)
> - BrosTrend AX1L / AX4L (RTL8852BU)
> - BrosTrend AX8L / EDUP AXE5400 (RTL8852CU)
>
> Six adapters, x86_64 Tiger Lake xHCI + aarch64 BCM2712 / RP1 hosts.
> 60 plug-cycles + 30+ throughput cells captured 2026-04-11 to
> 2026-05-07. USB enumeration verified at SuperSpeed (5000 Mbps) on
> every patched cell.
>
> Per-cell raw evidence for the May 2026 expanded matrix (40 iperf3
> JSON files per cell, byte-counter deltas, pre/post link state,
> pre/post USB enumeration speeds, per-iteration timestamps) at:
>
> https://github.com/Lucid-Duck/rtw89-usb3-gap/tree/main/evidence/may-2026-laptop
>
> Per-adapter summaries:
>
> https://github.com/Lucid-Duck/rtw89-usb3-gap/tree/main/adapters
>
> If the Tested-by trailer should be annotated with the specific chip
> list, I will add that when, and if, a v3 is needed.
>
> Devin
^ permalink raw reply
* Re: [PATCH rtw-next v2 1/1] wifi: rtw89: usb: Support switching to USB 3 mode
From: Devin Wittmayer @ 2026-05-12 0:35 UTC (permalink / raw)
To: rtl8821cerfe2, linux-wireless
Cc: pkshih, johannes, linux-kernel, Devin Wittmayer
In-Reply-To: <2bc415d6-f0ae-42ab-8ffa-19cfb1df5954@gmail.com>
On Tue, 2026-05-12 at 01:27 +0300, Bitterblue Smith wrote:
> Good, good. So how did you avoid the crash?
If you mean the crash at
https://github.com/Lucid-Duck/rtw89-usb3-gap/tree/main/evidence/crash-2026-04-11
-- that was BE-gen DACK calibration and is unrelated to this
USB 2-to-3 switch-mode patch. Four AX-gen adapters concurrent on
one xHCI host complete switch-mode and RF calibration without
DACK errors.
Devin
^ permalink raw reply
* RE: [PATCH rtw-next v2] wifi: rtl8xxxu: Detect the maximum supported channel width
From: Ping-Ke Shih @ 2026-05-12 0:44 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Jes Sorensen, Bitterblue Smith, linux-wireless@vger.kernel.org,
art1310@proton.me, Linux kernel regressions list
In-Reply-To: <41693ffc-926c-4e67-9a48-b6e1b1d150bd@leemhuis.info>
Thorsten Leemhuis <linux@leemhuis.info> wrote:
> On 5/6/26 09:57, Ping-Ke Shih wrote:
> > Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >
> >> Some devices malfunction when connected to a network with 40 MHz channel
> >> width, because they don't support that.
> >>
> >> RTL8188FU, RTL8192FU, and RTL8710BU (RTL8188GU) have a way to signal
> >> this (and some other capabilities) to the driver. Get this information
> >> from the hardware and advertise 40 MHz support only when the hardware
> >> can handle it. We assume the other chips can always handle it.
> >>
> >> RTL8710BU needs a different way to retrieve this information, which will
> >> be implemented some other time.
> >>
> >> Fixes: dbf9b7bb0edf ("wifi: rtl8xxxu: Enable 40 MHz width by default")
> >> Cc: stable@vger.kernel.org
> >> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221394
> >> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> >> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
>
> Thx for fixing this!
>
> > 1 patch(es) applied to rtw-next branch of rtw.git, thanks.
> > ef771eabc79d wifi: rtl8xxxu: Detect the maximum supported channel width
> > https://github.com/pkshih/rtw.git
>
> rtw-next sounds like it aims for the next merge window; and it seems the
> fix hasn't even hit -next yet. This is slightly unfortunate, as this
> afaics is a fix for a recent regression -- so it ideally should head
> towards mainline by now[1], as Linus' the rule of thumb is to "generally
> fix regressions "within a week", preferably before the next rc"[1].
>
> Or am I missing something? That might very well be the case, so do not
> hesitate to tell me!
As this patch applied to public rtw tree, and people who encountered the
problem in bugzilla can work again. To prevent breaking the public tree,
I'd keep it as was.
I will be carefully to handle this kind of patches later.
Ping-Ke
^ permalink raw reply
* RE: [PATCH rtw-next v2 1/1] wifi: rtw89: usb: Support switching to USB 3 mode
From: Ping-Ke Shih @ 2026-05-12 1:25 UTC (permalink / raw)
To: Devin Wittmayer, johannes@sipsolutions.net,
linux-wireless@vger.kernel.org
Cc: rtl8821cerfe2@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <20260511180351.26471-1-lucid_duck@justthetip.ca>
Devin Wittmayer <lucid_duck@justthetip.ca> wrote:
>
> On Mon, 2026-05-11 at 19:26 +0200, Johannes Berg wrote:
> > > +static bool rtw89_switch_usb_mode = true;
> > > +module_param_named(switch_usb_mode, rtw89_switch_usb_mode, bool, 0644);
> > > +MODULE_PARM_DESC(switch_usb_mode,
> > > + "Set to N to disable switching to USB 3 mode to avoid potential interference in the 2.4
> GHz band (default: Y)");
> >
> > We shouldn't really add new module parameters.
This module parameter follows the pattern Bitterblue established for
> rtw88: same user-facing name (switch_usb_mode), same description, same
> default. Commit 315c23a64e99 "wifi: rtw88: usb: Support USB 3 with
> RTL8822CU/RTL8822BU" (2024-07-10) added it to rtw88/usb.c and it
> remains in-tree.
I took the patch of rtw88 because we switch USB mode at probe stage, but
USB 3 mode has interference on 2.4GHz band (as the comment says). If a user
insist on 2.4GHz with a good performance, this is an option to keep USB 2
mode.
>
> Three v3 paths I see:
>
> 1. Drop the param. Users hitting USB3 2.4 GHz harmonic interference
> would need to use a USB 2 port instead.
> 2. Move the escape hatch behind a sysfs or nl80211 control. New UABI
> surface; open to design suggestions on that.
> 3. Keep it for rtw89/rtw88 symmetry on the same USB3 / 2.4 GHz
> harmonic interference issue.
An additional option might be to not support 2.4GHz channels when switching
to USB 3. But I'm not really sure if it is acceptable to USB users.
Ping-Ke
^ permalink raw reply
* RE: [PATCH rtw-next v2 1/1] wifi: rtw89: usb: Support switching to USB 3 mode
From: Ping-Ke Shih @ 2026-05-12 1:35 UTC (permalink / raw)
To: Devin Wittmayer, linux-wireless@vger.kernel.org
Cc: rtl8821cerfe2@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <20260511160811.17647-2-lucid_duck@justthetip.ca>
Devin Wittmayer <lucid_duck@justthetip.ca> wrote:
> From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
[...]
> @@ -1027,6 +1032,35 @@ static void rtw89_usb_intf_deinit(struct rtw89_dev *rtwdev,
> usb_set_intfdata(intf, NULL);
> }
>
> +static int rtw89_usb_switch_mode(struct rtw89_dev *rtwdev)
> +{
> + struct rtw89_usb *rtwusb = rtw89_usb_priv(rtwdev);
> +
> + if (!rtw89_switch_usb_mode)
> + return 0;
> +
> + /* No known USB 3 devices with this chip. */
> + if (rtwdev->chip->chip_id == RTL8851B)
> + return 0;
As commit message, only RTL8832BU and RTL8832CU were tested, and WiFi 7
was not neither. I'd give positive list instead.
> +
> + if (rtwusb->udev->speed == USB_SPEED_SUPER)
> + return 0;
> +
> + rtw89_debug(rtwdev, RTW89_DBG_HCI, "%s: pad_ctrl2: %#x %#x\n",
> + __func__,
> + rtw89_read8(rtwdev, R_AX_PAD_CTRL2 + 1),
> + rtw89_read8(rtwdev, R_AX_PAD_CTRL2 + 2));
> +
> + /* Already tried to switch but it's a USB 2 port. */
> + if (rtw89_read8(rtwdev, R_AX_PAD_CTRL2 + 1) == USB_SWITCH_DELAY)
> + return 0;
> +
> + rtw89_write8(rtwdev, R_AX_PAD_CTRL2 + 1, USB_SWITCH_DELAY);
> + rtw89_write8(rtwdev, R_AX_PAD_CTRL2 + 2, U2SWITCHU3);
> +
> + return 1;
> +}
> +
> int rtw89_usb_probe(struct usb_interface *intf,
> const struct usb_device_id *id)
> {
^ permalink raw reply
* [PATCH 0/2] staging: rtl8723bs: fix two remote frame-handling bugs
From: Shayaun Nejad @ 2026-05-12 1:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-staging, linux-wireless, linux-kernel, stable,
Shayaun Nejad
Fix two rtl8723bs receive-side bugs reachable while handling remote
802.11 management frames.
The first patch fixes a use-after-free in validate_80211w_mgmt(),
where decryptor() can release the receive frame and return NULL before
the caller reuses cached pointers into that frame.
The second patch bounds the combined SUPP_RATES and EXT_SUPP_RATES IE
lengths copied from beacon/probe response data into the 16-byte
support_rate[] stack buffer in rtw_check_beacon_data().
Both issues were found by Kuzushi + deep-audit (Sonnet 4.6) and
manually verified against mainline.
Shayaun Nejad (2):
staging: rtl8723bs: fix use-after-free in validate_80211w_mgmt after
decryptor()
staging: rtl8723bs: bound SUPP_RATES IE length in
rtw_check_beacon_data
drivers/staging/rtl8723bs/core/rtw_ap.c | 6 +++++-
drivers/staging/rtl8723bs/core/rtw_recv.c | 9 +++++++--
2 files changed, 12 insertions(+), 3 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/2] staging: rtl8723bs: fix use-after-free in validate_80211w_mgmt after decryptor()
From: Shayaun Nejad @ 2026-05-12 1:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-staging, linux-wireless, linux-kernel, stable,
Shayaun Nejad
In-Reply-To: <cover.1778550157.git.snejad123@gmail.com>
decryptor() can release precv_frame and return NULL when protected
management frame decryption fails.
validate_80211w_mgmt() still uses ptr and pattrib saved from that frame
for two memcpy() calls before checking the returned frame pointer.
Check the returned frame before any further access, then refresh ptr and
pattrib from the returned frame.
Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Cc: stable@vger.kernel.org
Signed-off-by: Shayaun Nejad <snejad123@gmail.com>
---
drivers/staging/rtl8723bs/core/rtw_recv.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c b/drivers/staging/rtl8723bs/core/rtw_recv.c
index f78194d508..0e1d248d8f 100644
--- a/drivers/staging/rtl8723bs/core/rtw_recv.c
+++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
@@ -1433,6 +1433,13 @@ static signed int validate_80211w_mgmt(struct adapter *adapter, union recv_frame
if (!mgmt_DATA)
goto validate_80211w_fail;
precv_frame = decryptor(adapter, precv_frame);
+ if (!precv_frame) {
+ kfree(mgmt_DATA);
+ goto validate_80211w_fail;
+ }
+
+ pattrib = &precv_frame->u.hdr.attrib;
+ ptr = precv_frame->u.hdr.rx_data;
/* save actual management data frame body */
memcpy(mgmt_DATA, ptr + pattrib->hdrlen + pattrib->iv_len, data_len);
/* overwrite the iv field */
@@ -1440,8 +1447,6 @@ static signed int validate_80211w_mgmt(struct adapter *adapter, union recv_frame
/* remove the iv and icv length */
pattrib->pkt_len = pattrib->pkt_len - pattrib->iv_len - pattrib->icv_len;
kfree(mgmt_DATA);
- if (!precv_frame)
- goto validate_80211w_fail;
} else if (is_multicast_ether_addr(GetAddr1Ptr(ptr)) &&
(subtype == WIFI_DEAUTH || subtype == WIFI_DISASSOC)) {
signed int BIP_ret = _SUCCESS;
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] staging: rtl8723bs: bound SUPP_RATES IE length in rtw_check_beacon_data
From: Shayaun Nejad @ 2026-05-12 1:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-staging, linux-wireless, linux-kernel, stable,
Shayaun Nejad
In-Reply-To: <cover.1778550157.git.snejad123@gmail.com>
rtw_check_beacon_data() copies SUPP_RATES and EXT_SUPP_RATES IE
payloads into a 16-byte support_rate[] buffer.
The IE lengths are used directly, so oversized rate IEs can overflow the
stack buffer.
Clamp the supported rates copy and the combined extended supported rates
copy to NDIS_802_11_LENGTH_RATES_EX.
Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Cc: stable@vger.kernel.org
Signed-off-by: Shayaun Nejad <snejad123@gmail.com>
---
drivers/staging/rtl8723bs/core/rtw_ap.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c b/drivers/staging/rtl8723bs/core/rtw_ap.c
index 4b40124110..363ecb02b5 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ap.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
@@ -873,6 +873,7 @@ int rtw_check_beacon_data(struct adapter *padapter, u8 *pbuf, int len)
&ie_len,
(pbss_network->ie_length - _BEACON_IE_OFFSET_));
if (p) {
+ ie_len = min_t(uint, ie_len, NDIS_802_11_LENGTH_RATES_EX);
memcpy(support_rate, p + 2, ie_len);
support_rate_num = ie_len;
}
@@ -882,8 +883,11 @@ int rtw_check_beacon_data(struct adapter *padapter, u8 *pbuf, int len)
WLAN_EID_EXT_SUPP_RATES,
&ie_len,
pbss_network->ie_length - _BEACON_IE_OFFSET_);
- if (p)
+ if (p && support_rate_num < NDIS_802_11_LENGTH_RATES_EX) {
+ ie_len = min_t(uint, ie_len,
+ NDIS_802_11_LENGTH_RATES_EX - support_rate_num);
memcpy(support_rate + support_rate_num, p + 2, ie_len);
+ }
network_type = rtw_check_network_type(support_rate, channel);
--
2.43.0
^ permalink raw reply related
* [PATCH ath-current] wifi: ath12k: fix memory leak in ath12k_wifi7_dp_rx_h_verify_tkip_mic()
From: Miaoqing Pan @ 2026-05-12 2:11 UTC (permalink / raw)
To: jjohnson; +Cc: ath12k, linux-wireless, linux-kernel, Miaoqing Pan
In ath12k_wifi7_dp_rx_h_verify_tkip_mic(), the call to
ath12k_dp_rx_check_nwifi_hdr_len_valid() may return false when the
NWIFI header length is invalid, causing the function to abort early with
-EINVAL.
When this happens, the error propagates to
ath12k_wifi7_dp_rx_h_defrag(), which clears first_frag by setting it
to NULL. As a result, the corresponding MSDU is no longer referenced
by the defragmentation path and is never freed.
This leads to a memory leak for the affected MSDU on this error path.
Proper cleanup is required to ensure the MSDU is released when header
validation fails during TKIP MIC verification.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: 9a0dddfb30f1 ("wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi")
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c b/drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c
index 945680b3ebdf..a5e290edaa89 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c
@@ -1028,8 +1028,10 @@ static int ath12k_wifi7_dp_rx_h_verify_tkip_mic(struct ath12k_pdev_dp *dp_pdev,
skb_pull(msdu, hal_rx_desc_sz);
if (unlikely(!ath12k_dp_rx_check_nwifi_hdr_len_valid(dp, msdu,
- rx_info)))
+ rx_info))) {
+ dev_kfree_skb_any(msdu);
return -EINVAL;
+ }
ath12k_dp_rx_h_ppdu(dp_pdev, rx_info);
ath12k_dp_rx_h_undecap(dp_pdev, msdu, HAL_ENCRYPT_TYPE_TKIP_MIC, true,
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next 0/2] wifi: ath11k: dp rx sanity checks for invalid length in error paths
From: Miaoqing Pan @ 2026-05-12 2:23 UTC (permalink / raw)
To: jjohnson; +Cc: ath11k, linux-wireless, linux-kernel, Miaoqing Pan
This patch series adds two defensive sanity checks in ath11k DP RX
handling to prevent invalid memory access when hardware/descriptor
contents are unexpected, especially in WBM error scenarios.
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
---
Miaoqing Pan (2):
wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi
wifi: ath11k: add MSDU length validation for TKIP MIC error
drivers/net/wireless/ath/ath11k/dp_rx.c | 59 +++++++++++++++++++++++--
1 file changed, 56 insertions(+), 3 deletions(-)
base-commit: 7b25796f571fc09a7aa6fe7efb23edccd326917d
--
2.34.1
^ permalink raw reply
* [PATCH ath-next 1/2] wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi
From: Miaoqing Pan @ 2026-05-12 2:23 UTC (permalink / raw)
To: jjohnson; +Cc: ath11k, linux-wireless, linux-kernel, Miaoqing Pan
In-Reply-To: <20260512022351.2033155-1-miaoqing.pan@oss.qualcomm.com>
In certain cases, hardware might provide packets with a
length greater than the maximum native Wi-Fi header length.
This can lead to accessing and modifying fields in the header
within the ath11k_dp_rx_h_undecap_nwifi() function for the
DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and
potentially result in invalid data access and memory corruption.
Kernel stack is corrupted in: ath11k_dp_rx_h_undecap+0x6b0/0x6b0 [ath11k]
Call trace:
ath11k_dp_rx_h_mpdu+0x0/0x2e8 [ath11k]
ath11k_dp_rx_h_mpdu+0x1e0/0x2e8 [ath11k]
ath11k_dp_rx_wbm_err+0x1e0/0x450 [ath11k]
ath11k_dp_rx_process_wbm_err+0x2fc/0x460 [ath11k]
ath11k_dp_service_srng+0x2e0/0x348 [ath11k]
Add a sanity check before processing the SKB to prevent invalid
data access in the undecap native Wi-Fi function for the
DP_RX_DECAP_TYPE_NATIVE_WIFI decap type.
This adapted from the discussion/patch of the ath12k driver [1].
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
Link: https://lore.kernel.org/linux-wireless/20250211090302.4105141-1-tamizh.raja@oss.qualcomm.com/ # [1]
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath11k/dp_rx.c | 50 +++++++++++++++++++++++--
1 file changed, 47 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
index fe79109adc70..fbe2061a544d 100644
--- a/drivers/net/wireless/ath/ath11k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
@@ -2502,6 +2502,29 @@ static void ath11k_dp_rx_deliver_msdu(struct ath11k *ar, struct napi_struct *nap
ieee80211_rx_napi(ar->hw, pubsta, msdu, napi);
}
+static bool ath11k_dp_rx_check_nwifi_hdr_len_valid(struct ath11k_base *ab,
+ struct hal_rx_desc *rx_desc,
+ struct sk_buff *msdu)
+{
+ struct ieee80211_hdr *hdr;
+ u8 decap_type;
+ u32 hdr_len;
+
+ decap_type = ath11k_dp_rx_h_msdu_start_decap_type(ab, rx_desc);
+ if (decap_type != DP_RX_DECAP_TYPE_NATIVE_WIFI)
+ return true;
+
+ hdr = (struct ieee80211_hdr *)msdu->data;
+ hdr_len = ieee80211_hdrlen(hdr->frame_control);
+
+ if ((likely(hdr_len <= DP_MAX_NWIFI_HDR_LEN)))
+ return true;
+
+ ab->soc_stats.invalid_rbm++;
+ WARN_ON_ONCE(1);
+ return false;
+}
+
static int ath11k_dp_rx_process_msdu(struct ath11k *ar,
struct sk_buff *msdu,
struct sk_buff_head *msdu_list,
@@ -2572,6 +2595,11 @@ static int ath11k_dp_rx_process_msdu(struct ath11k *ar,
}
}
+ if (unlikely(!ath11k_dp_rx_check_nwifi_hdr_len_valid(ab, rx_desc, msdu))) {
+ ret = -EINVAL;
+ goto free_out;
+ }
+
ath11k_dp_rx_h_ppdu(ar, rx_desc, rx_status);
ath11k_dp_rx_h_mpdu(ar, msdu, rx_desc, rx_status);
@@ -3261,6 +3289,12 @@ static int ath11k_dp_rx_h_verify_tkip_mic(struct ath11k *ar, struct ath11k_peer
RX_FLAG_IV_STRIPPED | RX_FLAG_DECRYPTED;
skb_pull(msdu, hal_rx_desc_sz);
+ if (unlikely(!ath11k_dp_rx_check_nwifi_hdr_len_valid(ar->ab, rx_desc,
+ msdu))) {
+ dev_kfree_skb_any(msdu);
+ return -EINVAL;
+ }
+
ath11k_dp_rx_h_ppdu(ar, rx_desc, rxs);
ath11k_dp_rx_h_undecap(ar, msdu, rx_desc,
HAL_ENCRYPT_TYPE_TKIP_MIC, rxs, true);
@@ -3953,6 +3987,10 @@ static int ath11k_dp_rx_h_null_q_desc(struct ath11k *ar, struct sk_buff *msdu,
skb_put(msdu, hal_rx_desc_sz + l3pad_bytes + msdu_len);
skb_pull(msdu, hal_rx_desc_sz + l3pad_bytes);
}
+
+ if (unlikely(!ath11k_dp_rx_check_nwifi_hdr_len_valid(ar->ab, desc, msdu)))
+ return -EINVAL;
+
ath11k_dp_rx_h_ppdu(ar, desc, status);
ath11k_dp_rx_h_mpdu(ar, msdu, desc, status);
@@ -3997,7 +4035,7 @@ static bool ath11k_dp_rx_h_reo_err(struct ath11k *ar, struct sk_buff *msdu,
return drop;
}
-static void ath11k_dp_rx_h_tkip_mic_err(struct ath11k *ar, struct sk_buff *msdu,
+static bool ath11k_dp_rx_h_tkip_mic_err(struct ath11k *ar, struct sk_buff *msdu,
struct ieee80211_rx_status *status)
{
u16 msdu_len;
@@ -4005,6 +4043,7 @@ static void ath11k_dp_rx_h_tkip_mic_err(struct ath11k *ar, struct sk_buff *msdu,
u8 l3pad_bytes;
struct ath11k_skb_rxcb *rxcb = ATH11K_SKB_RXCB(msdu);
u32 hal_rx_desc_sz = ar->ab->hw_params.hal_desc_sz;
+ struct ath11k_base *ab = ar->ab;
rxcb->is_first_msdu = ath11k_dp_rx_h_msdu_end_first_msdu(ar->ab, desc);
rxcb->is_last_msdu = ath11k_dp_rx_h_msdu_end_last_msdu(ar->ab, desc);
@@ -4014,6 +4053,9 @@ static void ath11k_dp_rx_h_tkip_mic_err(struct ath11k *ar, struct sk_buff *msdu,
skb_put(msdu, hal_rx_desc_sz + l3pad_bytes + msdu_len);
skb_pull(msdu, hal_rx_desc_sz + l3pad_bytes);
+ if (unlikely(!ath11k_dp_rx_check_nwifi_hdr_len_valid(ab, desc, msdu)))
+ return true;
+
ath11k_dp_rx_h_ppdu(ar, desc, status);
status->flag |= (RX_FLAG_MMIC_STRIPPED | RX_FLAG_MMIC_ERROR |
@@ -4021,19 +4063,21 @@ static void ath11k_dp_rx_h_tkip_mic_err(struct ath11k *ar, struct sk_buff *msdu,
ath11k_dp_rx_h_undecap(ar, msdu, desc,
HAL_ENCRYPT_TYPE_TKIP_MIC, status, false);
+
+ return false;
}
static bool ath11k_dp_rx_h_rxdma_err(struct ath11k *ar, struct sk_buff *msdu,
struct ieee80211_rx_status *status)
{
struct ath11k_skb_rxcb *rxcb = ATH11K_SKB_RXCB(msdu);
- bool drop = false;
+ bool drop;
ar->ab->soc_stats.rxdma_error[rxcb->err_code]++;
switch (rxcb->err_code) {
case HAL_REO_ENTR_RING_RXDMA_ECODE_TKIP_MIC_ERR:
- ath11k_dp_rx_h_tkip_mic_err(ar, msdu, status);
+ drop = ath11k_dp_rx_h_tkip_mic_err(ar, msdu, status);
break;
default:
/* TODO: Review other rxdma error code to check if anything is
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next 2/2] wifi: ath11k: add MSDU length validation for TKIP MIC error
From: Miaoqing Pan @ 2026-05-12 2:23 UTC (permalink / raw)
To: jjohnson; +Cc: ath11k, linux-wireless, linux-kernel, Miaoqing Pan
In-Reply-To: <20260512022351.2033155-1-miaoqing.pan@oss.qualcomm.com>
In the WBM error path, while processing TKIP MIC errors, MSDU length
is fetched from the hal_rx_desc's msdu_end. This MSDU length is
directly passed to skb_put() without validation. In stress test
scenarios, the WBM error ring may receive invalid descriptors, which
could lead to an invalid MSDU length.
To fix this, add a check to drop the skb when the calculated MSDU
length is greater than the skb size.
This is adapted from the discussion/patch of the ath12k driver [1].
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
Link: https://lore.kernel.org/linux-wireless/20250416021903.3178962-1-nithyanantham.paramasivam@oss.qualcomm.com/ # [1]
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath11k/dp_rx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
index fbe2061a544d..9c31bb7efcc8 100644
--- a/drivers/net/wireless/ath/ath11k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
@@ -4050,6 +4050,15 @@ static bool ath11k_dp_rx_h_tkip_mic_err(struct ath11k *ar, struct sk_buff *msdu,
l3pad_bytes = ath11k_dp_rx_h_msdu_end_l3pad(ar->ab, desc);
msdu_len = ath11k_dp_rx_h_msdu_start_msdu_len(ar->ab, desc);
+
+ if (unlikely(hal_rx_desc_sz + l3pad_bytes + msdu_len > DP_RX_BUFFER_SIZE)) {
+ ath11k_dbg(ab, ATH11K_DBG_DATA,
+ "invalid msdu len in tkip mic err %u\n", msdu_len);
+ ath11k_dbg_dump(ab, ATH11K_DBG_DATA, NULL, "", desc,
+ sizeof(*desc));
+ return true;
+ }
+
skb_put(msdu, hal_rx_desc_sz + l3pad_bytes + msdu_len);
skb_pull(msdu, hal_rx_desc_sz + l3pad_bytes);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH rtw-next v2 1/1] wifi: rtw89: usb: Support switching to USB 3 mode
From: Devin Wittmayer @ 2026-05-12 2:54 UTC (permalink / raw)
To: pkshih, linux-wireless
Cc: rtl8821cerfe2, johannes, linux-kernel, Devin Wittmayer
In-Reply-To: <e3ae58133549411e9eeb88c7c6ffbfaa@realtek.com>
On Tue, 2026-05-12 at 01:35 +0000, Ping-Ke Shih wrote:
> As commit message, only RTL8832BU and RTL8832CU were tested, and WiFi 7
> was not neither. I'd give positive list instead.
Agreed. Tested chip set for this patch:
Bitterblue's bench (per the commit body):
RTL8852B: RTL8832BU
RTL8852C: RTL8832CU
My side (per the v2 cover letter matrix):
RTL8852A: D-Link DWA-X1850 A1 (8852AU)
RTL8852A: D-Link DWA-X1850 B1 (8852AU)
RTL8852B: BrosTrend AX1L (8832BU)
RTL8852B: BrosTrend AX4L (8832BU)
RTL8852C: BrosTrend AX8L (8832CU)
RTL8852C: EDUP AXE5400 (8832CU)
v3 will gate on RTL8852A / RTL8852B / RTL8852C. RTL8851B stays out
because no RTL8851B variant has USB 3 hardware (per the in-patch
comment), so there is nothing to switch to.
WiFi 7 in rtw89 appears to be exclusively BE-generation as far as
I am aware (RTL8922A, RTL8922D). v2's AX-gen code (R_AX_PAD_CTRL2
writes) would not execute for BE-gen chips, so no WiFi 7 chip
appears testable for this patch by construction.
Devin
^ permalink raw reply
* Re: [PATCH] wifi: ath11k: fix use after free in ath11k_dp_rx_msdu_coalesce.
From: Baochen Qiang @ 2026-05-12 2:55 UTC (permalink / raw)
To: Jeff Johnson, Willmar Knikker, jjohnson; +Cc: linux-wireless, ath11k
In-Reply-To: <7d3c5eae-233a-4c31-b64e-70f0afe74da6@oss.qualcomm.com>
On 5/5/2026 11:08 PM, Jeff Johnson wrote:
> On 5/5/2026 7:30 AM, Willmar Knikker wrote:
>> In ath11k_dp_rx_msdu_coalesce the loop uses ->is_continuation after
>> the dev_kfree_skb_any. This can cause a use after free kfence.
>>
>> Move the use after the dev_kfree_skb_any after use of ->is_continuation
>> inline with the while in the while loop above this one.
>>
>> Signed-off-by: Willmar Knikker <willmar@met-dubbel-l.nl>
>> ---
>> drivers/net/wireless/ath/ath11k/dp_rx.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
>> index fe79109adc70..02bd9787d6b4 100644
>> --- a/drivers/net/wireless/ath/ath11k/dp_rx.c
>> +++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
>> @@ -1825,11 +1825,12 @@ static int ath11k_dp_rx_msdu_coalesce(struct ath11k *ar,
>> skb_pull(skb, hal_rx_desc_sz);
>> skb_copy_from_linear_data(skb, skb_put(first, buf_len),
>> buf_len);
>> - dev_kfree_skb_any(skb);
>> -
>> rem_len -= buf_len;
>> - if (!rxcb->is_continuation)
>> + if (!rxcb->is_continuation) {
>> + dev_kfree_skb_any(skb);
>> break;
>> + }
>> + dev_kfree_skb_any(skb);
>
> rather than repeating code imo it would be "better" to cache the flag before
> freeing and then test the cached flag.
>
> however as you note this proposed logic matches the logic already present in
> the "Free up all buffers of the MSDU" portion of the function, so from that
> perspective the proposal is consistent with that logic.
>
> let's see if anyone else has an opinion...
I also prefer a cached flag as it is much cleaner.
>
> /jeff
>
^ permalink raw reply
* Re: [PATCH v2] wifi: ath11k: fix use after free in ath11k_dp_rx_msdu_coalesce.
From: Baochen Qiang @ 2026-05-12 3:05 UTC (permalink / raw)
To: Willmar Knikker, jjohnson; +Cc: linux-wireless, ath11k
In-Reply-To: <20260505171709.547274-1-willmar@met-dubbel-l.nl>
On 5/6/2026 1:17 AM, Willmar Knikker wrote:
> In ath11k_dp_rx_msdu_coalesce the loop uses ->is_continuation after
> the dev_kfree_skb_any. This can cause a use after free kfence.
>
> Use flag for caching is_continuation for use after the
> dev_kfree_skb_any.
>
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Signed-off-by: Willmar Knikker <willmar@met-dubbel-l.nl>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: ath12k WCN7850: Q6 Hexagon fault at WLAON region 0x1792000 ~2s post-AUTHORIZE on X1E80100
From: Baochen Qiang @ 2026-05-12 3:38 UTC (permalink / raw)
To: Marcus Glocker, ath12k, linux-wireless
Cc: jjohnson, kvalo, manivannan.sadhasivam, Mark Kettenis
In-Reply-To: <g7dkeq3uwg7eby57zcuu5eysf4tqomh5civlvkpnlziipn6xis@45eevyzgfmaq>
On 5/5/2026 5:08 AM, Marcus Glocker wrote:
> Hi,
>
> We're porting ath12k to OpenBSD as the qwz(4) driver, targeting Samsung
> Galaxy Book4 Edge (X1E80100 SoC, WCN7850 hw2.0). Scan, auth, 4-way
> handshake all complete; ~2 seconds after WPA2 AUTHORIZE the WCN7850
> firmware crashes deterministically with:
>
> dlpager_main.c:147 Non Page Fault Exception cause code 0x 23
> at Address: 0x 1792000
>
> Cause code 0x23 isn't a valid arm64 exception -- the fault is on the
> WCN7850's on-die Hexagon Q6 DSP, with QURT's generic exception handler
> (which happens to live in dlpager_main.c) printing it. So this is not
> a host CPU fault.
>
> Per the RDDM segment table (at the start of the dump), VA 0x01792000
> is the start of the chip's WLAON_DUMP region (size 0x820). The Q6 is
> trying to read its own always-on hardware state region and the chip
> refuses the access.
>
> (Samsung, Asus, Honor) with multiple FW builds. Currently testing
> with WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
> (fw 0x110cffff, 2025-06-25) -- the exact blob a Linux ath12k user
> runs successfully on the identical Samsung hardware. Same board-2.bin,
> same compiled DTB (upstream hamoa.dtsi based).
>
> We've field-compared qwz against ath12k and ruled out (byte-level or
> wire-level):
>
> * QMI host_cap, m3_info, wlan_cfg, wlan_ini, bdf_download (all
> fields including ce_config, svc_to_ce_map, shadow_reg_v3,
> feature_list, m3 paddr/size, nm_modem)
> * MHI bringup ordering (BHI -> wait SBL EE -> wait M0 -> BHIE)
> * BHI/BHIE DMA coherency
> * ASPM disable before MHI start
> * WLAON_WARM_SW_ENTRY zeroing + QFPROM_PWR_CTRL VDD4BLOW clear
> * static_window_map=false + window-bank register init
> * Per-chunk vs monolithic respond_mem allocation
> * WMI_PEER_MIMO_PS_STATE = WMI_PEER_SMPS_PS_NONE (added matching
> ath12k_setup_peer_smps; doesn't help)
> * FW image variation (c5 and c7 both fail identically)
>
> Specifically NOT involved (we have evidence either way):
>
> * Gunyah -- X1E80100 is reportedly run in EL2 without Gunyah by
> users where ath12k works; so Gunyah isn't programming WLAON
> access for the Q6.
> * SMMU / pcie_smmu -- pcie_smmu is status="reserved" upstream,
> pcie4 has no iommus property; PCIe DMA bypasses SMMU.
> * SCM/PAS -- ath12k's PCIe path makes no qcom_scm_* calls.
>
> Question: what subsystem inside the WCN7850 firmware touches the
> WLAON region at 0x01792000 around 2 seconds after the host sends
> WMI_PEER_AUTHORIZE? And what host-side configuration (WMI command,
> HTT message, MHI state, etc.) primes that path so the access
> succeeds on Linux?
>
> Even a pointer at the right Linux code path or the right FW-side
> component would unblock us. We have full RDDM dumps and dmesg
> captures available; happy to share off-list or as attachments.
please help collect ath12k successful dmesg log and qwz failed dmesg log for compare.
Please enable verbose ath12k log when loading ath12k driver:
If you are using the latest upstream ath12k:
sudo modprobe ath12k debug_mask=0xffffffff
sudo modprobe ath12k_wifi7
If you are using an old ath12k:
sudo modprobe ath12k debug_mask=0xffffffff
>
> Thanks,
> Marcus
>
^ 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