* [PATCH v2 2/3] wifi: cfg80211: validate assoc response length before status and IE access
From: Zhao Li @ 2026-07-07 2:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel
In-Reply-To: <20260707025336.22557-1-enderaoelyther@gmail.com>
cfg80211_rx_assoc_resp() initialises the status and response-IE fields
of cfg80211_connect_resp_params from the management frame before
proving that the frame is long enough for those offsets. S1G and
regular association responses also have different IE offsets, but the
S1G path only patched resp_ie after the unsafe initialiser had already
run.
Defer resp_ie, resp_ie_len, and status to after the link-iteration
loop. Use a bool to remember whether the frame is S1G, then validate
the appropriate minimum length and set all three fields in a single
if/else block. Funnel short-frame and SME-reject cleanup through a
shared free_bss label for the abandon paths.
Assisted-by: Codex:gpt-5.5
Assisted-by: Claude:claude-opus-4.8
Signed-off-by: Zhao Li <enderaoelyther@gmail.com>
---
v2: No change.
net/wireless/mlme.c | 56 ++++++++++++++++++++++++++++-----------------
1 file changed, 35 insertions(+), 21 deletions(-)
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index a0f7b08bfcc9c..097b66f758ba2 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -32,14 +32,10 @@ void cfg80211_rx_assoc_resp(struct net_device *dev,
.timeout_reason = NL80211_TIMEOUT_UNSPECIFIED,
.req_ie = data->req_ies,
.req_ie_len = data->req_ies_len,
- .resp_ie = mgmt->u.assoc_resp.variable,
- .resp_ie_len = data->len -
- offsetof(struct ieee80211_mgmt,
- u.assoc_resp.variable),
- .status = le16_to_cpu(mgmt->u.assoc_resp.status_code),
.ap_mld_addr = data->ap_mld_addr,
};
unsigned int link_id;
+ bool is_s1g = false;
for (link_id = 0; link_id < ARRAY_SIZE(data->links); link_id++) {
cr.links[link_id].status = data->links[link_id].status;
@@ -60,16 +56,32 @@ void cfg80211_rx_assoc_resp(struct net_device *dev,
if (cr.links[link_id].bss->channel->band == NL80211_BAND_S1GHZ) {
WARN_ON(link_id);
- cr.resp_ie = (u8 *)&mgmt->u.s1g_assoc_resp.variable;
- cr.resp_ie_len = data->len -
- offsetof(struct ieee80211_mgmt,
- u.s1g_assoc_resp.variable);
+ is_s1g = true;
}
if (cr.ap_mld_addr)
cr.valid_links |= BIT(link_id);
}
+ if (is_s1g) {
+ if (data->len < offsetof(struct ieee80211_mgmt,
+ u.s1g_assoc_resp.variable))
+ goto free_bss;
+ cr.resp_ie = (u8 *)&mgmt->u.s1g_assoc_resp.variable;
+ cr.resp_ie_len = data->len -
+ offsetof(struct ieee80211_mgmt,
+ u.s1g_assoc_resp.variable);
+ } else {
+ if (data->len < offsetof(struct ieee80211_mgmt,
+ u.assoc_resp.variable))
+ goto free_bss;
+ cr.resp_ie = mgmt->u.assoc_resp.variable;
+ cr.resp_ie_len = data->len -
+ offsetof(struct ieee80211_mgmt,
+ u.assoc_resp.variable);
+ }
+ cr.status = le16_to_cpu(mgmt->u.assoc_resp.status_code);
+
trace_cfg80211_send_rx_assoc(dev, data);
/*
@@ -78,22 +90,24 @@ void cfg80211_rx_assoc_resp(struct net_device *dev,
* and got a reject -- we only try again with an assoc
* frame instead of reassoc.
*/
- if (cfg80211_sme_rx_assoc_resp(wdev, cr.status)) {
- for (link_id = 0; link_id < ARRAY_SIZE(data->links); link_id++) {
- struct cfg80211_bss *bss = data->links[link_id].bss;
-
- if (!bss)
- continue;
-
- cfg80211_unhold_bss(bss_from_pub(bss));
- cfg80211_put_bss(wiphy, bss);
- }
- return;
- }
+ if (cfg80211_sme_rx_assoc_resp(wdev, cr.status))
+ goto free_bss;
nl80211_send_rx_assoc(rdev, dev, data);
/* update current_bss etc., consumes the bss reference */
__cfg80211_connect_result(dev, &cr, cr.status == WLAN_STATUS_SUCCESS);
+ return;
+
+free_bss:
+ for (link_id = 0; link_id < ARRAY_SIZE(data->links); link_id++) {
+ struct cfg80211_bss *bss = data->links[link_id].bss;
+
+ if (!bss)
+ continue;
+
+ cfg80211_unhold_bss(bss_from_pub(bss));
+ cfg80211_put_bss(wiphy, bss);
+ }
}
EXPORT_SYMBOL(cfg80211_rx_assoc_resp);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH v2 1/3] wifi: cfg80211: validate rx/tx MLME callback frame lengths before access
From: Zhao Li @ 2026-07-07 2:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel
In-Reply-To: <488ed9862d5196b8f5ecf23f037fa6725fbe9a52.camel@sipsolutions.net>
cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() call tracepoints
before rejecting frames shorter than the frame-control field. After
that, they only require len >= 2 before dispatching into subtype
handlers that assume their fixed fields are present.
The frames that trip this are not shorter than 2 bytes; they are short
relative to their subtype. mwifiex is a concrete in-tree example on the
length side: mwifiex_process_mgmt_packet() only requires a 4-address
ieee80211_hdr plus the 2-byte firmware length prefix before handing the
frame to cfg80211_rx_mlme_mgmt(). After stripping the length prefix and
removing addr4, pkt_len can be exactly 24: a bare 3-address management
header with no reason-code body. The existing WARN_ON(len < 2) does not
fire on such a frame, and cfg80211_process_deauth() then reads
u.deauth.reason_code as a two-byte access starting at offset 24,
immediately past the 24-byte buffer.
Add a frame-control length gate, then validate each subtype's minimum
frame size in an if/else-if chain that mirrors the dispatch logic. Trace
only after the frame is known to be well-formed.
Side effects of this change:
- The WARN_ON(len < 2) is dropped. It only guarded the frame_control
read, never the subtype fixed fields, and it does not fire on the
frames that actually trigger the out-of-bounds read (which are >= 2).
The len >= 2 check is kept as the guard before dereferencing
frame_control, but without the warning: these are exported callbacks
and a malformed frame from a driver should be dropped silently rather
than backtraced.
- cfg80211_tx_mlme_mgmt() previously routed every non-deauth subtype
through disassociation handling; it now silently ignores unrecognised
subtypes.
Assisted-by: Codex:gpt-5.5
Assisted-by: Claude:claude-opus-4.8
Signed-off-by: Zhao Li <enderaoelyther@gmail.com>
---
v2: Rewrite the commit message. Drop the inaccurate claim that these
callbacks "legitimately receive short frames" (< 2) from drivers;
no in-tree caller passes len < 2. Document the concrete mwifiex
header-only deauth/disassoc path that reaches the callback below the
subtype minimum, and clarify why the WARN is dropped while the
len >= 2 guard is kept. Per Johannes' review. No code change.
net/wireless/mlme.c | 45 +++++++++++++++++++++++++++++++++++++--------
1 file changed, 37 insertions(+), 8 deletions(-)
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index bd72317c4964e..a0f7b08bfcc9c 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -150,19 +150,35 @@ void cfg80211_rx_mlme_mgmt(struct net_device *dev, const u8 *buf, size_t len)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct ieee80211_mgmt *mgmt = (void *)buf;
+ __le16 fc;
lockdep_assert_wiphy(wdev->wiphy);
- trace_cfg80211_rx_mlme_mgmt(dev, buf, len);
+ if (len < sizeof(fc))
+ return;
+
+ fc = mgmt->frame_control;
- if (WARN_ON(len < 2))
+ if (ieee80211_is_auth(fc)) {
+ if (len < offsetofend(struct ieee80211_mgmt, u.auth.status_code))
+ return;
+ } else if (ieee80211_is_deauth(fc)) {
+ if (len < offsetofend(struct ieee80211_mgmt, u.deauth.reason_code))
+ return;
+ } else if (ieee80211_is_disassoc(fc)) {
+ if (len < offsetofend(struct ieee80211_mgmt, u.disassoc.reason_code))
+ return;
+ } else {
return;
+ }
+
+ trace_cfg80211_rx_mlme_mgmt(dev, buf, len);
- if (ieee80211_is_auth(mgmt->frame_control))
+ if (ieee80211_is_auth(fc))
cfg80211_process_auth(wdev, buf, len);
- else if (ieee80211_is_deauth(mgmt->frame_control))
+ else if (ieee80211_is_deauth(fc))
cfg80211_process_deauth(wdev, buf, len, false);
- else if (ieee80211_is_disassoc(mgmt->frame_control))
+ else
cfg80211_process_disassoc(wdev, buf, len, false);
}
EXPORT_SYMBOL(cfg80211_rx_mlme_mgmt);
@@ -215,15 +231,28 @@ void cfg80211_tx_mlme_mgmt(struct net_device *dev, const u8 *buf, size_t len,
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct ieee80211_mgmt *mgmt = (void *)buf;
+ __le16 fc;
lockdep_assert_wiphy(wdev->wiphy);
- trace_cfg80211_tx_mlme_mgmt(dev, buf, len, reconnect);
+ if (len < sizeof(fc))
+ return;
- if (WARN_ON(len < 2))
+ fc = mgmt->frame_control;
+
+ if (ieee80211_is_deauth(fc)) {
+ if (len < offsetofend(struct ieee80211_mgmt, u.deauth.reason_code))
+ return;
+ } else if (ieee80211_is_disassoc(fc)) {
+ if (len < offsetofend(struct ieee80211_mgmt, u.disassoc.reason_code))
+ return;
+ } else {
return;
+ }
+
+ trace_cfg80211_tx_mlme_mgmt(dev, buf, len, reconnect);
- if (ieee80211_is_deauth(mgmt->frame_control))
+ if (ieee80211_is_deauth(fc))
cfg80211_process_deauth(wdev, buf, len, reconnect);
else
cfg80211_process_disassoc(wdev, buf, len, reconnect);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH 1/3] wifi: cfg80211: validate rx/tx MLME callback frame lengths before access
From: Zhao Li @ 2026-07-07 2:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel
In-Reply-To: <488ed9862d5196b8f5ecf23f037fa6725fbe9a52.camel@sipsolutions.net>
On Mon, 2026-07-06 at 18:37 +0800, Johannes Berg wrote:
> > Side effects of this change:
> > - The WARN_ON(len < 2) is replaced by a silent early return, since
> > these cfg80211 callbacks can legitimately receive short frames from
> > drivers.
>
> Can they? How?
You're right, that wording is wrong; no in-tree caller passes len < 2.
mac80211 gates every path well above that (ieee80211_rx_mgmt_auth() at
len < 24 + 6, ieee80211_rx_mgmt_deauth()/disassoc() at len < 24 + 2), and
the locally built deauth/disassoc frames are always full size.
The frames that do reach these callbacks undersized are short relative
to their subtype, not shorter than 2 bytes. mwifiex accepts a 4-address
ieee80211_hdr plus the 2-byte firmware length prefix. After it strips
the prefix and removes addr4, pkt_len can be exactly 24: a bare
3-address management header with no reason-code body.
WARN_ON(len < 2) does not fire on that, and cfg80211_process_deauth()
then reads u.deauth.reason_code as a two-byte access starting at offset
24, immediately past the 24-byte buffer.
So the len >= 2 check only guards the frame_control read; the per-subtype
offsetofend() checks are the actual fix. I'll drop the WARN rather than
keep it, because these are exported callbacks and a malformed frame from
a driver should be dropped silently instead of backtraced.
v2 rewrites the commit message to describe the mwifiex path instead of
the inaccurate "legitimately receive short frames" claim; no code change.
Thanks,
Zhao Li
^ permalink raw reply
* [wireless:for-next] BUILD SUCCESS 4a360c6e18dfa9d70006c7247a6a8cc8dfe0d60f
From: kernel test robot @ 2026-07-07 1:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git for-next
branch HEAD: 4a360c6e18dfa9d70006c7247a6a8cc8dfe0d60f wifi: mac80211: validate deauth frame length before reason access
elapsed time: 800m
configs tested: 148
configs skipped: 20
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig gcc-16.1.0
arc randconfig-001-20260707 gcc-14.3.0
arc randconfig-002-20260707 gcc-12.5.0
arm allnoconfig clang-17
arm allyesconfig gcc-16.1.0
arm pxa168_defconfig clang-23
arm randconfig-001-20260707 gcc-8.5.0
arm randconfig-002-20260707 clang-17
arm randconfig-003-20260707 clang-17
arm randconfig-004-20260707 clang-23
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 randconfig-001-20260707 clang-23
arm64 randconfig-002-20260707 clang-18
arm64 randconfig-003-20260707 clang-23
arm64 randconfig-004-20260707 clang-17
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky randconfig-001-20260707 gcc-16.1.0
csky randconfig-002-20260707 gcc-16.1.0
hexagon allmodconfig clang-23
hexagon allnoconfig clang-23
hexagon randconfig-001-20260707 clang-23
hexagon randconfig-002-20260707 clang-18
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-004-20260707 gcc-14
i386 randconfig-001 clang-22
i386 randconfig-001-20260707 gcc-13
i386 randconfig-002 gcc-14
i386 randconfig-002-20260707 clang-22
i386 randconfig-003 gcc-14
i386 randconfig-003-20260707 clang-22
i386 randconfig-004 clang-22
i386 randconfig-004-20260707 gcc-14
i386 randconfig-005 gcc-14
i386 randconfig-005-20260707 clang-22
i386 randconfig-006 gcc-14
i386 randconfig-006-20260707 clang-22
i386 randconfig-007 gcc-14
i386 randconfig-007-20260707 clang-22
i386 randconfig-012-20260707 gcc-14
loongarch allmodconfig clang-19
loongarch allnoconfig clang-20
loongarch defconfig clang-23
loongarch randconfig-001-20260707 clang-18
loongarch randconfig-002-20260707 clang-19
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig gcc-16.1.0
m68k defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig gcc-16.1.0
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20260707 gcc-11.5.0
nios2 randconfig-002-20260707 gcc-11.5.0
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig gcc-16.1.0
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260707 gcc-15.2.0
parisc randconfig-002-20260707 gcc-9.5.0
parisc64 defconfig gcc-16.1.0
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig gcc-16.1.0
powerpc randconfig-001-20260707 clang-23
powerpc randconfig-002-20260707 gcc-14.3.0
powerpc64 randconfig-001-20260707 gcc-8.5.0
powerpc64 randconfig-002-20260707 clang-22
riscv allmodconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig clang-23
riscv nommu_k210_sdcard_defconfig gcc-16.1.0
riscv randconfig-001 gcc-13.4.0
riscv randconfig-001-20260707 gcc-14.3.0
riscv randconfig-002 clang-17
riscv randconfig-002-20260707 gcc-8.5.0
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig clang-18
s390 randconfig-001 gcc-15.2.0
s390 randconfig-001-20260707 clang-21
s390 randconfig-002 clang-18
s390 randconfig-002-20260707 gcc-13.4.0
sh allmodconfig gcc-16.1.0
sh allnoconfig gcc-16.1.0
sh allyesconfig gcc-16.1.0
sh defconfig gcc-16.1.0
sh randconfig-001 gcc-14.3.0
sh randconfig-001-20260707 gcc-16.1.0
sh randconfig-002 gcc-9.5.0
sh randconfig-002-20260707 gcc-16.1.0
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001 gcc-16.1.0
sparc randconfig-001-20260707 gcc-13.4.0
sparc randconfig-002 gcc-11.5.0
sparc randconfig-002-20260707 gcc-15.2.0
sparc64 allmodconfig clang-20
sparc64 defconfig clang-23
sparc64 randconfig-001 gcc-12.5.0
sparc64 randconfig-001-20260707 gcc-8.5.0
sparc64 randconfig-002 clang-20
sparc64 randconfig-002-20260707 clang-23
um allmodconfig clang-17
um allnoconfig clang-17
um allyesconfig gcc-14
um defconfig clang-23
um i386_defconfig gcc-14
um randconfig-001 clang-23
um randconfig-001-20260707 clang-18
um randconfig-002 clang-23
um randconfig-002-20260707 clang-23
um x86_64_defconfig clang-23
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-22
x86_64 defconfig gcc-14
x86_64 randconfig-011-20260707 clang-22
x86_64 randconfig-012-20260707 gcc-14
x86_64 randconfig-013-20260707 clang-22
x86_64 randconfig-014-20260707 gcc-14
x86_64 randconfig-015-20260707 gcc-14
x86_64 randconfig-016-20260707 clang-22
x86_64 randconfig-076-20260707 gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig gcc-16.1.0
xtensa randconfig-001 gcc-8.5.0
xtensa randconfig-001-20260707 gcc-8.5.0
xtensa randconfig-002 gcc-13.4.0
xtensa randconfig-002-20260707 gcc-11.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [REGRESSION] mt7925e: fails to read EEPROM MAC on 7.2-rc2, falls back to random MAC (worked on 7.1-rc7 and 7.0.x)
From: B X @ 2026-07-07 0:16 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: linux-wireless, nbd, lorenzo, ryder.lee, shayne.chen, sean.wang,
regressions, Rosen Penev
In-Reply-To: <870f1c80-5027-4503-b6c4-6df80eea7df3@leemhuis.info>
Confirmed -- the patch fixes it.
I applied 20260630210215.400379-1-rosenp@gmail.com on top of 7.2-rc2 and
booted it on my x86 Strix Halo (MT7925 RZ717, non-OF PCIe card). With the
patch, the "Invalid MAC address, using random address" line is gone and the
adapter comes up with its real EEPROM MAC (ac:f2:3c:35:31:15). Stock 7.2-rc2
without the patch reproduces the random-MAC behaviour on the same hardware.
Tested-by: Brent Paine <bkpaine1@gmail.com>
Brent
On Mon, Jul 6, 2026 at 10:21 AM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
>
>
> On 7/6/26 15:35, B X wrote:
> > B X <brent@msbs.com>
> > 8:12 AM (1 hour ago)
> > to linux-wireless, nbd, lorenzo, ryder.lee, shayne.chen, sean.wang,
> > regressions, Brent
> >
> > Hi,
> >
> > Reporting a regression in the mt7925e driver: on Linux 7.2.0-rc2 the adapter
> > fails to read its stored (EEPROM/efuse) MAC address and substitutes a random
> > one. The same hardware read its real MAC correctly on every earlier kernel,
> > including the immediately-preceding boot one day earlier on 7.0.0-22.
>
> Sounds a lot like it's the problem "wifi: mt76: fix MAC address for non
> OF pcie cards" aims to fix:
> https://lore.kernel.org/all/20260630210215.400379-1-rosenp@gmail.com/
>
> Would be great if you could confirm.
>
> Ciao, Thorsten
>
> > Verified with Claude Code when my ATT fiber kept failing to pin IP on
> > my Halo Strix
> >
> > Hardware
> > --------
> > MediaTek MT7925 (RZ717) Wi-Fi 7 160MHz
> > PCI ID: [14c3:0717], driver mt7925e
> > Platform: AMD "Strix Halo" (Ryzen AI Max) mini-PC
> > linux-firmware: 20260319.git217ca6e4
> >
> > Symptom (kernel 7.2.0-rc2, 2026-07-06)
> > --------------------------------------
> > mt7925e 0000:c3:00.0: enabling device (0000 -> 0002)
> > mt7925e 0000:c3:00.0: ASIC revision: 79250000
> > mt7925e 0000:c3:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
> > mt7925e 0000:c3:00.0: WM Firmware Version: ____000000, Build Time:
> > 20260106153120
> > mt7925e 0000:c3:00.0: Invalid MAC address, using random address
> > 12:1f:34:c6:57:04
> > mt7925e 0000:c3:00.0 wlp195s0: renamed from wlan0
> >
> > The driver then brings the interface up with the random MAC 12:1f:34:c6:57:04.
> >
> > Last known good (kernel 7.0.0-22, 2026-07-05, same machine, no MAC override)
> > ----------------------------------------------------------------------------
> > mt7925e 0000:c3:00.0: ASIC revision: 79250000
> > mt7925e 0000:c3:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
> > mt7925e 0000:c3:00.0: WM Firmware Version: ____000000, Build Time:
> > 20260106153120
> > ...
> > wlp195s0: authenticate with <ap> (local address=ac:f2:3c:35:31:15)
> >
> > i.e. the real MAC ac:f2:3c:35:31:15 was read straight off the adapter. Note
> > the firmware init lines (ASIC revision, HW/SW Version, WM Firmware Version,
> > build times) are byte-identical between the good and bad boots -- only the
> > kernel differs, and only the MAC read fails. This rules out a firmware or
> > bad-NVRAM cause: the same silicon read the MAC correctly ~24h earlier.
> >
> > Regression range
> > ----------------
> > Confirmed good on: 7.0.0, 7.0.0-22, 7.0.0-27, 7.1.0-rc7 (dozens of boots,
> > journal-verified, no "Invalid MAC address" line on any of them).
> > First and only bad boot: 7.2.0-rc2.
> >
> > So the regression landed between 7.1-rc7 and 7.2-rc2. I have not bisected to
> > the exact commit yet, but I can -- the machine builds kernels quickly -- if a
> > bisect would help pin it down.
> >
> > Not reboot-type dependent: on the good kernels (7.0.0-22 / 7.0.0-27) the
> > correct MAC was read reliably across both warm/clean reboots and cold/hard
> > power cycles. The failure does not correlate with reboot type or chip power
> > state -- it correlates only with the kernel version (7.2-rc2).
> >
> > Impact
> > ------
> > The substituted MAC is random per boot, changing the adapter's L2 identity.
> > This breaks router-side DHCP reservations / fixed-IP allocations keyed on MAC:
> > the host stops receiving its pinned address and lands on an arbitrary lease.
> > Any MT7925 user relying on MAC-based address pinning is affected. Current
> > workaround here is forcing the real MAC via NetworkManager cloned-mac-address.
> >
> > #regzbot introduced: v7.1..v7.2-rc2
> >
> >
> >
> > Thanks,
> >
> >
> > Brent Paine, AWS, CCNP
> >
> > git bkpaine1
> > Medium bkpaine1
> >
> >
> > On Mon, Jul 6, 2026 at 8:12 AM B X <brent@msbs.com> wrote:
> >>
> >> Hi,
> >>
> >> Reporting a regression in the mt7925e driver: on Linux 7.2.0-rc2 the adapter
> >> fails to read its stored (EEPROM/efuse) MAC address and substitutes a random
> >> one. The same hardware read its real MAC correctly on every earlier kernel,
> >> including the immediately-preceding boot one day earlier on 7.0.0-22.
> >>
> >> Verified with Claude Code when my ATT fiber kept failing to pin IP on my Halo Strix
> >>
> >> Hardware
> >> --------
> >> MediaTek MT7925 (RZ717) Wi-Fi 7 160MHz
> >> PCI ID: [14c3:0717], driver mt7925e
> >> Platform: AMD "Strix Halo" (Ryzen AI Max) mini-PC
> >> linux-firmware: 20260319.git217ca6e4
> >>
> >> Symptom (kernel 7.2.0-rc2, 2026-07-06)
> >> --------------------------------------
> >> mt7925e 0000:c3:00.0: enabling device (0000 -> 0002)
> >> mt7925e 0000:c3:00.0: ASIC revision: 79250000
> >> mt7925e 0000:c3:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
> >> mt7925e 0000:c3:00.0: WM Firmware Version: ____000000, Build Time: 20260106153120
> >> mt7925e 0000:c3:00.0: Invalid MAC address, using random address 12:1f:34:c6:57:04
> >> mt7925e 0000:c3:00.0 wlp195s0: renamed from wlan0
> >>
> >> The driver then brings the interface up with the random MAC 12:1f:34:c6:57:04.
> >>
> >> Last known good (kernel 7.0.0-22, 2026-07-05, same machine, no MAC override)
> >> ----------------------------------------------------------------------------
> >> mt7925e 0000:c3:00.0: ASIC revision: 79250000
> >> mt7925e 0000:c3:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
> >> mt7925e 0000:c3:00.0: WM Firmware Version: ____000000, Build Time: 20260106153120
> >> ...
> >> wlp195s0: authenticate with <ap> (local address=ac:f2:3c:35:31:15)
> >>
> >> i.e. the real MAC ac:f2:3c:35:31:15 was read straight off the adapter. Note
> >> the firmware init lines (ASIC revision, HW/SW Version, WM Firmware Version,
> >> build times) are byte-identical between the good and bad boots -- only the
> >> kernel differs, and only the MAC read fails. This rules out a firmware or
> >> bad-NVRAM cause: the same silicon read the MAC correctly ~24h earlier.
> >>
> >> Regression range
> >> ----------------
> >> Confirmed good on: 7.0.0, 7.0.0-22, 7.0.0-27, 7.1.0-rc7 (dozens of boots,
> >> journal-verified, no "Invalid MAC address" line on any of them).
> >> First and only bad boot: 7.2.0-rc2.
> >>
> >> So the regression landed between 7.1-rc7 and 7.2-rc2. I have not bisected to
> >> the exact commit yet, but I can -- the machine builds kernels quickly -- if a
> >> bisect would help pin it down.
> >>
> >> Not reboot-type dependent: on the good kernels (7.0.0-22 / 7.0.0-27) the
> >> correct MAC was read reliably across both warm/clean reboots and cold/hard
> >> power cycles. The failure does not correlate with reboot type or chip power
> >> state -- it correlates only with the kernel version (7.2-rc2).
> >>
> >> Impact
> >> ------
> >> The substituted MAC is random per boot, changing the adapter's L2 identity.
> >> This breaks router-side DHCP reservations / fixed-IP allocations keyed on MAC:
> >> the host stops receiving its pinned address and lands on an arbitrary lease.
> >> Any MT7925 user relying on MAC-based address pinning is affected. Current
> >> workaround here is forcing the real MAC via NetworkManager cloned-mac-address.
> >>
> >> #regzbot introduced: v7.1..v7.2-rc2
> >>
> >>
> >>
> >> Thanks,
> >>
> >>
> >> Brent Paine, AWS, CCNP
> >>
> >> git bkpaine1
> >> Medium bkpaine1
>
^ permalink raw reply
* [wireless-next:main] BUILD REGRESSION 2bfd9da88b95d89041c91c06acd1c38258edc38b
From: kernel test robot @ 2026-07-07 0:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
branch HEAD: 2bfd9da88b95d89041c91c06acd1c38258edc38b wifi: cfg80211: support MAC address filtering in station dump for link stats
Error/Warning (recently discovered and may have been fixed):
https://lore.kernel.org/oe-kbuild-all/202607070740.1XekJylA-lkp@intel.com
(.text+0x4e00): multiple definition of `is_command_pending'; drivers/net/wireless/marvell/mwifiex/main.o:(.text+0x5880): first defined here
alpha-linux-ld: drivers/net/wireless/nxp/nxpwifi/wmm.o:(.sdata+0x1c): multiple definition of `tos_to_tid_inv'; drivers/net/wireless/marvell/mwifiex/wmm.o:(.sdata+0x1c): first defined here
Unverified Error/Warning (likely false positive, kindly check if interested):
drivers/net/wireless/nxp/nxpwifi/scan.c:2034:1: internal compiler error: in final_scan_insn_1, at final.cc:2823
Error/Warning ids grouped by kconfigs:
recent_errors
|-- alpha-allyesconfig
| |-- multiple-definition-of-is_command_pending-drivers-net-wireless-marvell-mwifiex-main.o:(.text):first-defined-here
| `-- multiple-definition-of-tos_to_tid_inv-drivers-net-wireless-marvell-mwifiex-wmm.o:(.sdata):first-defined-here
`-- csky-allmodconfig
`-- drivers-net-wireless-nxp-nxpwifi-scan.c:internal-compiler-error:in-final_scan_insn_1-at-final.cc
elapsed time: 729m
configs tested: 186
configs skipped: 117
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig gcc-16.1.0
arc randconfig-001-20260707 gcc-14.3.0
arc randconfig-002-20260707 gcc-12.5.0
arm allnoconfig clang-17
arm allyesconfig gcc-16.1.0
arm defconfig clang-23
arm pxa3xx_defconfig clang-17
arm randconfig-001-20260707 gcc-8.5.0
arm randconfig-002-20260707 clang-17
arm randconfig-003-20260707 clang-17
arm randconfig-004-20260707 clang-23
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001 gcc-14.3.0
arm64 randconfig-001-20260707 clang-23
arm64 randconfig-002 gcc-8.5.0
arm64 randconfig-002-20260707 clang-18
arm64 randconfig-003 clang-20
arm64 randconfig-003-20260707 clang-23
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260707 clang-17
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky randconfig-001 gcc-13.4.0
csky randconfig-001-20260707 gcc-16.1.0
csky randconfig-002 gcc-14.3.0
csky randconfig-002-20260707 gcc-16.1.0
hexagon allmodconfig clang-23
hexagon allnoconfig clang-23
hexagon randconfig-001 clang-17
hexagon randconfig-001-20260707 clang-23
hexagon randconfig-002 clang-23
hexagon randconfig-002-20260707 clang-18
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260706 clang-22
i386 buildonly-randconfig-002-20260706 gcc-12
i386 buildonly-randconfig-003-20260706 clang-22
i386 buildonly-randconfig-004-20260706 clang-22
i386 buildonly-randconfig-004-20260707 gcc-14
i386 buildonly-randconfig-005-20260706 clang-22
i386 buildonly-randconfig-006-20260706 gcc-14
i386 defconfig clang-22
i386 randconfig-001-20260707 gcc-13
i386 randconfig-002-20260707 clang-22
i386 randconfig-003-20260707 clang-22
i386 randconfig-004-20260707 gcc-14
i386 randconfig-005-20260707 clang-22
i386 randconfig-006-20260707 clang-22
i386 randconfig-007-20260707 clang-22
i386 randconfig-011-20260707 gcc-14
i386 randconfig-012-20260707 gcc-14
i386 randconfig-013-20260707 clang-22
i386 randconfig-014-20260707 gcc-14
i386 randconfig-015-20260707 gcc-14
i386 randconfig-016-20260707 gcc-14
i386 randconfig-017-20260707 gcc-14
loongarch allmodconfig clang-19
loongarch allnoconfig clang-20
loongarch defconfig clang-23
loongarch randconfig-001 clang-23
loongarch randconfig-001-20260707 clang-18
loongarch randconfig-002 gcc-16.1.0
loongarch randconfig-002-20260707 clang-19
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig gcc-16.1.0
m68k defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig gcc-16.1.0
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260707 gcc-11.5.0
nios2 randconfig-002 gcc-8.5.0
nios2 randconfig-002-20260707 gcc-11.5.0
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig gcc-16.1.0
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260707 gcc-15.2.0
parisc randconfig-002-20260707 gcc-9.5.0
parisc64 defconfig gcc-16.1.0
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig gcc-16.1.0
powerpc randconfig-001-20260707 clang-23
powerpc randconfig-002-20260707 gcc-14.3.0
powerpc64 randconfig-001-20260707 gcc-8.5.0
powerpc64 randconfig-002-20260707 clang-22
riscv allmodconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig clang-23
riscv nommu_k210_sdcard_defconfig gcc-16.1.0
riscv randconfig-001-20260707 gcc-14.3.0
riscv randconfig-002-20260707 gcc-8.5.0
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig clang-18
s390 randconfig-001-20260707 clang-21
s390 randconfig-002-20260707 gcc-13.4.0
sh allmodconfig gcc-16.1.0
sh allnoconfig gcc-16.1.0
sh allyesconfig gcc-16.1.0
sh defconfig gcc-16.1.0
sh randconfig-001-20260707 gcc-16.1.0
sh randconfig-002-20260707 gcc-16.1.0
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260707 gcc-13.4.0
sparc randconfig-002-20260707 gcc-15.2.0
sparc64 allmodconfig clang-20
sparc64 defconfig clang-23
sparc64 randconfig-001-20260707 gcc-8.5.0
sparc64 randconfig-002-20260707 clang-23
um allmodconfig clang-17
um allnoconfig clang-17
um allyesconfig gcc-14
um defconfig clang-23
um i386_defconfig gcc-14
um randconfig-001-20260707 clang-18
um randconfig-002-20260707 clang-23
um x86_64_defconfig clang-23
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 gcc-12
x86_64 buildonly-randconfig-001-20260706 clang-22
x86_64 buildonly-randconfig-002 clang-22
x86_64 buildonly-randconfig-002-20260706 gcc-14
x86_64 buildonly-randconfig-003 gcc-14
x86_64 buildonly-randconfig-003-20260706 gcc-14
x86_64 buildonly-randconfig-004 gcc-14
x86_64 buildonly-randconfig-004-20260706 gcc-14
x86_64 buildonly-randconfig-005 gcc-14
x86_64 buildonly-randconfig-005-20260706 gcc-14
x86_64 buildonly-randconfig-006 clang-22
x86_64 buildonly-randconfig-006-20260706 clang-22
x86_64 defconfig gcc-14
x86_64 randconfig-001-20260706 gcc-14
x86_64 randconfig-001-20260707 clang-22
x86_64 randconfig-002-20260706 clang-22
x86_64 randconfig-002-20260707 gcc-14
x86_64 randconfig-003-20260706 clang-22
x86_64 randconfig-003-20260707 clang-22
x86_64 randconfig-004-20260706 gcc-14
x86_64 randconfig-004-20260707 clang-22
x86_64 randconfig-005-20260706 clang-22
x86_64 randconfig-005-20260707 gcc-14
x86_64 randconfig-006-20260706 gcc-13
x86_64 randconfig-006-20260707 gcc-12
x86_64 randconfig-011-20260706 clang-22
x86_64 randconfig-012-20260706 clang-22
x86_64 randconfig-012-20260707 gcc-14
x86_64 randconfig-013-20260706 gcc-14
x86_64 randconfig-014-20260706 gcc-12
x86_64 randconfig-014-20260707 gcc-14
x86_64 randconfig-015-20260706 gcc-14
x86_64 randconfig-015-20260707 gcc-14
x86_64 randconfig-016-20260706 gcc-12
x86_64 randconfig-071-20260707 clang-22
x86_64 randconfig-072-20260707 clang-22
x86_64 randconfig-073-20260707 clang-22
x86_64 randconfig-074-20260707 clang-22
x86_64 randconfig-075-20260707 clang-22
x86_64 randconfig-076-20260707 gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig gcc-16.1.0
xtensa randconfig-001-20260707 gcc-8.5.0
xtensa randconfig-002-20260707 gcc-11.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCHv2 wireless] wifi: mt76: fix MAC address for non OF pcie cards
From: Rosen Penev @ 2026-07-06 23:28 UTC (permalink / raw)
To: linux-wireless
Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Shayne Chen,
Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Rosen Penev, open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
If seems the check for err is wrong as the proper macaddr gets written
to from the EEPROM itself. Meaning checking err from of_get_mac_address is
wrong as the proper macaddr has been written by this point.
Reported-by: Klara Modin <klarasmodin@gmail.com>
Closes: https://lore.kernel.org/all/ajRmlyx_AEGybykL@soda.int.kasm.eu/
Reported-by: Tobias Klausmann <klausman@schwarzvogel.de>
Closes:
https://lore.kernel.org/linux-wireless/30a90714-02d8-45f2-a7f1-4cfe0627d50b@skade.local/
Fixes: 31ee1582717e ("wifi: mt76: fix of_get_mac_address error handling")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Tested-by: Tobias Klausmann <klausman@schwarzvogel.de>
Tested-by: Klara Modin <klarasmodin@gmail.com>
---
v2: add extra tags and target wireless
drivers/net/wireless/mediatek/mt76/eeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
index b99d7452800f..afdb73661866 100644
--- a/drivers/net/wireless/mediatek/mt76/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
@@ -181,7 +181,7 @@ mt76_eeprom_override(struct mt76_phy *phy)
if (err == -EPROBE_DEFER)
return err;
- if (err) {
+ if (!is_valid_ether_addr(phy->macaddr)) {
eth_random_addr(phy->macaddr);
dev_info(dev->dev,
"Invalid MAC address, using random address %pM\n",
--
2.55.0
^ permalink raw reply related
* [wireless-next:main 2/99] (.text+0x4e00): multiple definition of `is_command_pending'; drivers/net/wireless/marvell/mwifiex/main.o:(.text+0x5880): first defined here
From: kernel test robot @ 2026-07-06 23:21 UTC (permalink / raw)
To: Jeff Chen; +Cc: oe-kbuild-all, Johannes Berg, linux-wireless
tree: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
head: 2bfd9da88b95d89041c91c06acd1c38258edc38b
commit: 4c477f8bfc1a86c54a719cae475f7fa1973eba0f [2/99] wifi: nxp: add nxpwifi driver for IW61x
config: alpha-allyesconfig (https://download.01.org/0day-ci/archive/20260707/202607070740.1XekJylA-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260707/202607070740.1XekJylA-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202607070740.1XekJylA-lkp@intel.com/
All errors (new ones prefixed by >>):
alpha-linux-ld: drivers/net/wireless/nxp/nxpwifi/main.o: in function `is_command_pending':
>> (.text+0x4e00): multiple definition of `is_command_pending'; drivers/net/wireless/marvell/mwifiex/main.o:(.text+0x5880): first defined here
alpha-linux-ld: drivers/net/wireless/nxp/nxpwifi/main.o:(.data+0x0): multiple definition of `driver_version'; drivers/net/wireless/marvell/mwifiex/main.o:(.rodata+0x26a): first defined here
alpha-linux-ld: drivers/net/wireless/nxp/nxpwifi/cfp.o:(.data+0x20): multiple definition of `region_code_index'; drivers/net/wireless/marvell/mwifiex/cfp.o:(.data+0x0): first defined here
>> alpha-linux-ld: drivers/net/wireless/nxp/nxpwifi/wmm.o:(.sdata+0x1c): multiple definition of `tos_to_tid_inv'; drivers/net/wireless/marvell/mwifiex/wmm.o:(.sdata+0x1c): first defined here
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH wireless] wifi: mac80211: ibss: wait for in-flight TX on disconnect
From: Miri Korenblit @ 2026-07-06 19:37 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Pagadala Yesu Anjaneyulu, Johannes Berg
From: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
While leaving an IBSS in ieee80211_ibss_disconnect() mac80211 flushes
stations, turns the carrier off and immediately tells the driver to
leave as well. While there may be synchronize_net() in station flush
and in this code later, packets can still be transmitted due to
cross-CPU race conditions after carrier off is set.
Therefore, it's possible for a race to happen where a TX to the
driver occurs while or after telling it to leave the IBSS. This can
be confusing to drivers, and in the case of iwlwifi leads to an
attempt to use invalid queues.
Move netif_carrier_off() to occur before sta_info_flush() during
IBSS disconnect, and add synchronize_net() if flushing didn't,
so that the synchronize_net() always happens between turning the
carrier off and telling the driver, avoiding this race.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
net/mac80211/ibss.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index d0fd6054f182..472ab8672be5 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -668,7 +668,9 @@ static void ieee80211_ibss_disconnect(struct ieee80211_sub_if_data *sdata)
ifibss->state = IEEE80211_IBSS_MLME_SEARCH;
- sta_info_flush(sdata, -1);
+ netif_carrier_off(sdata->dev);
+ if (!sta_info_flush(sdata, -1))
+ synchronize_net();
spin_lock_bh(&ifibss->incomplete_lock);
while (!list_empty(&ifibss->incomplete_stations)) {
@@ -682,8 +684,6 @@ static void ieee80211_ibss_disconnect(struct ieee80211_sub_if_data *sdata)
}
spin_unlock_bh(&ifibss->incomplete_lock);
- netif_carrier_off(sdata->dev);
-
sdata->vif.cfg.ibss_joined = false;
sdata->vif.cfg.ibss_creator = false;
sdata->vif.bss_conf.enable_beacon = false;
@@ -710,7 +710,6 @@ static void ieee80211_csa_connection_drop_work(struct wiphy *wiphy,
u.ibss.csa_connection_drop_work);
ieee80211_ibss_disconnect(sdata);
- synchronize_rcu();
skb_queue_purge(&sdata->skb_queue);
/* trigger a scan to find another IBSS network to join */
@@ -1797,8 +1796,6 @@ int ieee80211_ibss_leave(struct ieee80211_sub_if_data *sdata)
memset(&ifibss->ht_capa, 0, sizeof(ifibss->ht_capa));
memset(&ifibss->ht_capa_mask, 0, sizeof(ifibss->ht_capa_mask));
- synchronize_rcu();
-
skb_queue_purge(&sdata->skb_queue);
timer_delete_sync(&sdata->u.ibss.timer);
--
2.34.1
^ permalink raw reply related
* [PATCH wireless-next] wifi: mac80211: Route (Re)association req/response to per-STA queue
From: Miri Korenblit @ 2026-07-06 19:29 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Ilan Peer, Johannes Berg
From: Ilan Peer <ilan.peer@intel.com>
An association request or response frame is generally delivered to the
driver without a TX queue object. However, with drivers that do encryption
offload and couple the key with a transmit queue, this means that the
frames are not being encrypted.
Fix this by routing the association frames to the management TXQ.
This will allow the driver to set up the required resources before
transmitting the association frame, e.g., set up keys etc.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
include/linux/ieee80211.h | 11 +++++++++++
net/mac80211/ieee80211_i.h | 4 +---
net/mac80211/tx.c | 7 +++++++
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 084ad45aa2d8..26e674038865 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -556,6 +556,17 @@ static inline bool ieee80211_is_reassoc_resp(__le16 fc)
cpu_to_le16(IEEE80211_FTYPE_MGMT | IEEE80211_STYPE_REASSOC_RESP);
}
+/**
+ * ieee80211_is_assoc - check if (Re)association request/response frame
+ * @fc: frame control bytes in little-endian byteorder
+ * Return: whether or not the frame is an (re)association request or response
+ */
+static inline bool ieee80211_is_assoc(__le16 fc)
+{
+ return ieee80211_is_assoc_req(fc) || ieee80211_is_reassoc_req(fc) ||
+ ieee80211_is_assoc_resp(fc) || ieee80211_is_reassoc_resp(fc);
+}
+
/**
* ieee80211_is_probe_req - check if IEEE80211_FTYPE_MGMT && IEEE80211_STYPE_PROBE_REQ
* @fc: frame control bytes in little-endian byteorder
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 34a9ea8b6f85..d585820245dd 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -2470,9 +2470,7 @@ void __ieee80211_tx_skb_tid_band(struct ieee80211_sub_if_data *sdata,
static inline bool ieee80211_require_encrypted_assoc(__le16 fc,
struct sta_info *sta)
{
- return (sta && sta->sta.epp_peer &&
- (ieee80211_is_assoc_req(fc) || ieee80211_is_reassoc_req(fc) ||
- ieee80211_is_assoc_resp(fc) || ieee80211_is_reassoc_resp(fc)));
+ return sta && sta->sta.epp_peer && ieee80211_is_assoc(fc);
}
/* sta_out needs to be checked for ERR_PTR() before using */
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index c13b209fad47..42cfd76850b8 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1309,10 +1309,17 @@ static struct txq_info *ieee80211_get_txq(struct ieee80211_local *local,
(info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE))
return NULL;
+ /*
+ * While (re)association request/response frames are not considered
+ * bufferable MMPDUs, use the TXQ abstraction for the transmission of
+ * these frames. This is specifically useful for drivers that might
+ * associate other resources with the TXQ, e.g., encryption keys etc.
+ */
if (!(info->flags & IEEE80211_TX_CTL_HW_80211_ENCAP) &&
unlikely(!ieee80211_is_data_present(hdr->frame_control))) {
if ((!ieee80211_is_mgmt(hdr->frame_control) ||
ieee80211_is_bufferable_mmpdu(skb) ||
+ ieee80211_is_assoc(hdr->frame_control) ||
vif->type == NL80211_IFTYPE_STATION ||
vif->type == NL80211_IFTYPE_NAN ||
vif->type == NL80211_IFTYPE_NAN_DATA) &&
--
2.34.1
^ permalink raw reply related
* [PATCH wireless] wifi: mac80211: recalculate rx_nss on IBSS peer capability update
From: Miri Korenblit @ 2026-07-06 19:27 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Shahar Tzarfati, Johannes Berg
From: Shahar Tzarfati <shahar.tzarfati@intel.com>
When IBSS peer capabilities change, rates_updated is set to true in
ieee80211_update_sta_info(), but rx_nss is never recalculated.
For peers with HT/VHT, this leaves rx_nss at 0 instead of the
correct value, causing drivers to use incorrect rate scaling
parameters.
The root cause is that the commit below moved NSS initialisation
out of rate_control_rate_init() into explicit call sites, but
missing the rates_updated path in ieee80211_update_sta_info().
Fix this by calling ieee80211_sta_init_nss_bw_capa() before
rate_control_rate_init() when peer capabilities are updated,
consistent with the other IBSS call sites added by that commit.
Fixes: e5ad38a9b261 ("wifi: mac80211: clean up STA NSS handling")
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
net/mac80211/ibss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index d0fd6054f182..1e5414ee27c0 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -1029,8 +1029,8 @@ static void ieee80211_update_sta_info(struct ieee80211_sub_if_data *sdata,
u32 changed = IEEE80211_RC_SUPP_RATES_CHANGED;
u8 rx_nss = sta->sta.deflink.rx_nss;
- /* Force rx_nss recalculation */
- sta->sta.deflink.rx_nss = 0;
+ ieee80211_sta_init_nss_bw_capa(&sta->deflink,
+ &sdata->deflink.conf->chanreq.oper);
rate_control_rate_init(&sta->deflink);
if (sta->sta.deflink.rx_nss != rx_nss)
changed |= IEEE80211_RC_NSS_CHANGED;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] brcmfmac-cyw: clean up PMKID and cookie code
From: Arend van Spriel @ 2026-07-06 19:06 UTC (permalink / raw)
To: Bogdan Nicolae
Cc: linux-wireless, brcm80211, brcm80211-dev-list.pdl, linux-kernel
In-Reply-To: <CA+ORkNQPL_qdLOSC2Ae0Y7-wihKVRaaO-DUajN-3rpjzyoEtjg@mail.gmail.com>
On Fri, 3 Jul 2026 17:39:51 -0500, Bogdan Nicolae wrote:
> Avoid setting packet_id to cookie, which is always 0. Instead, use an
> increasing atomic counter. Avoids mismatches of completion events later
> in brcmf_notify_mgmt_tx_status, where packet_id != vif->mgmt_tx_id is
> checked.
>
> Also, zero out auth_status on initialization. Otherwise, garbage will
> leak from the stack to the firmware (when bssid is less than 32 bytes
> and/or when params->pmkid is set). Then, pass the params->pmkid to the
> firmware (without it, the firmware caches a garbage PMKID on successful
> authentication and denies a subsequent association request that includes
> the PMKID).
>
> Signed-off-by: Bogdan Nicolae <bogdan.nicolae@acm.org>
The patch failed to apply because it had line-wrapped diff lines. Please
resend. git format-patch and git send-email are your friend (well, can be).
Also, the subject line is missing the "wifi:" prefix. It should read:
wifi: brcmfmac: cyw: clean up PMKID and cookie code
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] wifi: brcmfmac: cyw: fix heap overflow on a short auth frame
From: Arend van Spriel @ 2026-07-06 19:06 UTC (permalink / raw)
To: Maoyi Xie
Cc: linux-wireless, brcm80211, brcm80211-dev-list.pdl, linux-kernel,
Kaixuan Li, stable, Arend van Spriel
In-Reply-To: <20260627131313.3878893-1-maoyixie.tju@gmail.com>
On Sat, 27 Jun 2026 21:13:13 +0800, Maoyi Xie wrote:
> brcmf_notify_auth_frame_rx() takes the frame length from the firmware
> event and copies the frame body with the management header offset
> subtracted:
[...]
> Reject frames shorter than the management header offset before the copy.
>
> Fixes: 66f909308a7c ("wifi: brcmfmac: cyw: support external SAE authentication in station mode")
> Link: https://lore.kernel.org/r/178214417708.2368577.16740907093694208834@maoyixie.com
> Cc: stable@vger.kernel.org
> Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
> ---
> .../broadcom/brcm80211/brcmfmac/cyw/core.c | 6 ++++++
> 1 file changed, 6 insertions(+)
Nit: the Link: tag in the commit message is normally added by the
maintainer at apply time, not by the submitter. Please drop it.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Regards,
Arend
^ permalink raw reply
* Re: [PATCH wireless] wifi: brcmfmac: initialize SDIO data work before cleanup
From: Arend van Spriel @ 2026-07-06 19:06 UTC (permalink / raw)
To: Runyu Xiao
Cc: Kalle Valo, Pieter-Paul Giesberts, Hante Meuleman, Daniel Kim,
Franky Lin, linux-wireless, brcm80211, brcm80211-dev-list.pdl,
linux-kernel, stable, Arend van Spriel
In-Reply-To: <20260619064401.1048976-1-runyu.xiao@seu.edu.cn>
On Fri, 19 Jun 2026 14:44:01 +0800, Runyu Xiao wrote:
> brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before
> allocating the ordered workqueue. If that allocation fails, the function
> jumps to fail and calls brcmf_sdio_remove().
>
> brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the
> work item before the first failure path that can reach brcmf_sdio_remove(),
> so the cleanup path always observes a valid work object.
[...]
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Regards,
Arend
^ permalink raw reply
* [PATCH] wifi: mac80211: recalculate rx_nss on IBSS peer capability update
From: Miri Korenblit @ 2026-07-06 19:00 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Shahar Tzarfati, Johannes Berg
From: Shahar Tzarfati <shahar.tzarfati@intel.com>
When IBSS peer capabilities change, rates_updated is set to true in
ieee80211_update_sta_info(), but rx_nss is never recalculated.
For peers with HT/VHT, this leaves rx_nss at 0 instead of the
correct value, causing drivers to use incorrect rate scaling
parameters.
The root cause is that the commit below moved NSS initialisation
out of rate_control_rate_init() into explicit call sites, but
missing the rates_updated path in ieee80211_update_sta_info().
Fix this by calling ieee80211_sta_init_nss_bw_capa() before
rate_control_rate_init() when peer capabilities are updated,
consistent with the other IBSS call sites added by that commit.
Fixes: e5ad38a9b261 ("wifi: mac80211: clean up STA NSS handling")
Signed-off-by: Shahar Tzarfati <shahar.tzarfati@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
net/mac80211/ibss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index d0fd6054f182..1e5414ee27c0 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -1029,8 +1029,8 @@ static void ieee80211_update_sta_info(struct ieee80211_sub_if_data *sdata,
u32 changed = IEEE80211_RC_SUPP_RATES_CHANGED;
u8 rx_nss = sta->sta.deflink.rx_nss;
- /* Force rx_nss recalculation */
- sta->sta.deflink.rx_nss = 0;
+ ieee80211_sta_init_nss_bw_capa(&sta->deflink,
+ &sdata->deflink.conf->chanreq.oper);
rate_control_rate_init(&sta->deflink);
if (sta->sta.deflink.rx_nss != rx_nss)
changed |= IEEE80211_RC_NSS_CHANGED;
--
2.34.1
^ permalink raw reply related
* Re: Atheros AR9280 / AR7010 Initial low scaning signal range
From: cybersnow_2001 @ 2026-07-06 18:15 UTC (permalink / raw)
To: John Scott; +Cc: Linux Wireless
In-Reply-To: <c2163c6ee67e982fd95d1f965ecf0b853f687214.camel@posteo.net>
Thanks for looking at it. Here is what I could find on the Web about the same issue. Someone said Kernel 6.4 and earlier worked. You might try with Debian Live DVD Buster, Bullseye and others distro if you want. I tried to use an older firmware of Atheros v1.3 instead of 1.4, same problem. I wonder if there are older firmware... But I'm not sure if this is related to the firmware. It might be more about the kernel 80211 modules... Or it might be an electronic issue coming from the chip itself. I need to do a cold/freeze and very hot test to see if it solve the issue...
https://discussion.fedoraproject.org/t/need-help-with-weak-wifi-signal-on-fedora-with-qualcomm-atheros-card/87854
https://www.spinics.net/lists/linux-wireless/msg90423.html
https://forum.mikrotik.com/t/ar9280-low-speed/62030
https://forums.freebsd.org/threads/atheros-ar9280-wifi-not-working.68357/
https://forum.opnsense.org/index.php?topic=28266.0
https://forum.mikrotik.com/t/compex-wle200nx-atheros-ar9280/166217/3
https://forum.netgate.com/topic/83364/atheros-ar9280-testing-settings-craziness-success-ymmv/2
https://forums.tomshardware.com/threads/qualcomm-atheros-ar9287-terrible-range.2687938/
https://forum.netgate.com/topic/53616/atheros-ar9280-ath0-stuck-beacon-resetting-bmiss-count-4-hangs-later/2
https://forums.linuxmint.com/viewtopic.php?t=299646
Jul 4, 2026, 17:25 by jscott@posteo.net:
> On Wed, 2026-07-01 at 04:08 +0200, cybersnow_2001@tutamail.com wrote:
>
>> I've read in another forum that people experienced the same issue after a kernel update, maybe after 6.8. What do you think?
>>
>
> I think I can partially reproduce the problem. I have a Sony UWA-BR100 on Debian Trixie (kernel 6.12.94) and a wireless scan only shows very few access points, never more than -65 dBm or so. The access point for my home, being the closest one to me, actually has the *worst* signal strength value reported as -80 dBm consistently. A scan for access points does show 5GHz ones, but it chose to connect to my AP on 2.4GHz (which may or may not be legitimate; iwd normally joins the 5GHz ones when I'm using dual-band NICs). I did not observe any circumstance in which the reported signal became better, though.
>
> With a TP-Link TL-WN822N v2 (still AR7010, but the 2.4GHz-only AR9287 instead of dual-band AR9280), everything is excellent, so indeed it seems only the AR9280 devices are affected.
> Could you share that forum link? I'm not sure I'll get around to it but my next steps would be to bisect the kernel using a virtual machine and USB pass-through. This is strange indeed...
>
^ permalink raw reply
* [PATCH] wifi: mac80211_hwsim: avoid NULL skb in stop queue drain
From: Cen Zhang @ 2026-07-06 16:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel, baijiaju1990, zzzccc427
mac80211_hwsim_stop() drops any frames left in data->pending. The loop
currently checks skb_queue_empty() and then dequeues separately.
That split is racy with TX status handling, which can remove a pending
frame under the queue lock. If the last entry is removed after the empty
check, skb_dequeue() returns NULL and the stop path passes that NULL skb
to ieee80211_free_txskb().
Use skb_dequeue() as the loop condition instead. The dequeue result is the
object that stop owns and frees, and a concurrent status completion that
empties the queue simply makes the loop terminate.
Fixes: bd18de517923 ("mac80211_hwsim: drop pending frames on stop")
Assisted-by: Codex:gpt-5.5
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
---
drivers/net/wireless/virtual/mac80211_hwsim_main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/virtual/mac80211_hwsim_main.c b/drivers/net/wireless/virtual/mac80211_hwsim_main.c
index 0dd8a6c85953..f92d90bc7107 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim_main.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim_main.c
@@ -2303,6 +2303,7 @@ static int mac80211_hwsim_start(struct ieee80211_hw *hw)
static void mac80211_hwsim_stop(struct ieee80211_hw *hw, bool suspend)
{
struct mac80211_hwsim_data *data = hw->priv;
+ struct sk_buff *skb;
int i;
data->started = false;
@@ -2310,8 +2311,8 @@ static void mac80211_hwsim_stop(struct ieee80211_hw *hw, bool suspend)
for (i = 0; i < ARRAY_SIZE(data->link_data); i++)
hrtimer_cancel(&data->link_data[i].beacon_timer);
- while (!skb_queue_empty(&data->pending))
- ieee80211_free_txskb(hw, skb_dequeue(&data->pending));
+ while ((skb = skb_dequeue(&data->pending)))
+ ieee80211_free_txskb(hw, skb);
wiphy_dbg(hw->wiphy, "%s\n", __func__);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH wireless-next v3 23/33] mmc: sdio: add Morse Micro vendor ids
From: Ulf Hansson @ 2026-07-06 15:47 UTC (permalink / raw)
To: Lachlan Hodges
Cc: johannes, Ulf Hansson, arien.judge, dan.callaghan, ayman.grais,
linux-wireless, linux-mmc, linux-kernel
In-Reply-To: <20260626063014.1275235-24-lachlan.hodges@morsemicro.com>
On Fri, Jun 26, 2026 at 8:32 AM Lachlan Hodges
<lachlan.hodges@morsemicro.com> wrote:
>
> Add the Morse Micro mm81x series vendor ids.
>
> Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Acked-by: Ulf Hansson <ulfh@kernel.org>
Kind regards
Uffe
> ---
> Hi Ulf, since v2 we've made another slight change to the name removing
> a "B2" suffix so even though you acked v2, I suppose it's best to
> recollect again - sorry about that. As last time, the patchset is
> split once per file following wireless driver submission guidelines,
> but will be a pull request with a single patch adding the driver +
> sdio ID once review is complete through the wireless tree.
> ---
> include/linux/mmc/sdio_ids.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
> index 0685dd717e85..bbffad9ae88e 100644
> --- a/include/linux/mmc/sdio_ids.h
> +++ b/include/linux/mmc/sdio_ids.h
> @@ -117,6 +117,9 @@
> #define SDIO_VENDOR_ID_MICROCHIP_WILC 0x0296
> #define SDIO_DEVICE_ID_MICROCHIP_WILC1000 0x5347
>
> +#define SDIO_VENDOR_ID_MORSEMICRO 0x325b
> +#define SDIO_DEVICE_ID_MORSEMICRO_MM8108 0x0809
> +
> #define SDIO_VENDOR_ID_NXP 0x0471
> #define SDIO_DEVICE_ID_NXP_IW61X 0x0205
>
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH v2] wifi: cfg80211: use wiphy work for socket owner autodisconnect
From: Cen Zhang @ 2026-07-06 15:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel, zzzccc427, baijiaju1990
nl80211_netlink_notify() walks the cfg80211 wireless device list when a
NETLINK_GENERIC socket is released. If the socket owns a connection, the
notifier queues the embedded wdev->disconnect_wk work item.
That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a
NETLINK_URELEASE notifier that already observed conn_owner_nlportid can
queue it after that cancel returns. _cfg80211_unregister_wdev() then
removes the wdev from the list and waits for RCU readers, but
synchronize_net() does not drain work queued by such a reader.
Make the autodisconnect work a wiphy_work instead. The callback already
needs the wiphy mutex, and wiphy_work runs under that mutex. This lets
teardown cancel pending autodisconnect work while holding the mutex,
without a cancel_work_sync() vs. worker locking concern.
Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any
NETLINK_URELEASE notifier that had already reached the wdev list has then
either queued the work and it is removed, or can no longer find the wdev.
Fixes: bd2522b16884 ("cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT")
Suggested-by: Johannes Berg <johannes@sipsolutions.net>
Assisted-by: Codex:gpt-5.5
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
---
v2:
- Convert the autodisconnect work to wiphy_work instead of taking RTNL in
nl80211_netlink_notify().
- Add a final wiphy_work_cancel() after list_del_rcu()/synchronize_net().
include/net/cfg80211.h | 2 +-
net/wireless/core.c | 10 ++++++----
net/wireless/core.h | 2 +-
net/wireless/nl80211.c | 3 ++-
net/wireless/sme.c | 6 ++----
5 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8188ad200de5..76827c965f41 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -7228,7 +7228,7 @@ struct wireless_dev {
enum ieee80211_bss_type conn_bss_type;
u32 conn_owner_nlportid;
- struct work_struct disconnect_wk;
+ struct wiphy_work disconnect_wk;
u8 disconnect_bssid[ETH_ALEN];
struct list_head event_list;
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 3dcf63b04c41..de86464695ba 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1424,6 +1424,7 @@ static void _cfg80211_unregister_wdev(struct wireless_dev *wdev,
list_del_rcu(&wdev->list);
synchronize_net();
rdev->devlist_generation++;
+ wiphy_work_cancel(wdev->wiphy, &wdev->disconnect_wk);
cfg80211_mlme_purge_registrations(wdev);
@@ -1637,7 +1638,7 @@ void cfg80211_init_wdev(struct wireless_dev *wdev)
wdev->iftype == NL80211_IFTYPE_ADHOC) && !wdev->use_4addr)
wdev->netdev->priv_flags |= IFF_DONT_BRIDGE;
- INIT_WORK(&wdev->disconnect_wk, cfg80211_autodisconnect_wk);
+ wiphy_work_init(&wdev->disconnect_wk, cfg80211_autodisconnect_wk);
}
void cfg80211_register_wdev(struct cfg80211_registered_device *rdev,
@@ -1743,10 +1744,11 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
break;
case NETDEV_GOING_DOWN:
cfg80211_leave(rdev, wdev, -1);
- scoped_guard(wiphy, &rdev->wiphy)
+ scoped_guard(wiphy, &rdev->wiphy) {
cfg80211_remove_links(wdev);
- /* since we just did cfg80211_leave() nothing to do there */
- cancel_work_sync(&wdev->disconnect_wk);
+ /* since we just did cfg80211_leave() nothing to do there */
+ wiphy_work_cancel(wdev->wiphy, &wdev->disconnect_wk);
+ }
cancel_work_sync(&wdev->pmsr_free_wk);
break;
case NETDEV_DOWN:
diff --git a/net/wireless/core.h b/net/wireless/core.h
index df47ed6208a5..f343d1074ace 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -428,7 +428,7 @@ void __cfg80211_port_authorized(struct wireless_dev *wdev, const u8 *peer_addr,
const u8 *td_bitmap, u8 td_bitmap_len);
int cfg80211_mgd_wext_connect(struct cfg80211_registered_device *rdev,
struct wireless_dev *wdev);
-void cfg80211_autodisconnect_wk(struct work_struct *work);
+void cfg80211_autodisconnect_wk(struct wiphy *wiphy, struct wiphy_work *work);
/* SME implementation */
void cfg80211_conn_work(struct work_struct *work);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 53b4b3f76697..153a9e8f35eb 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -22942,7 +22942,8 @@ static int nl80211_netlink_notify(struct notifier_block * nb,
wdev->nl_owner_dead = true;
schedule_work(&rdev->destroy_work);
} else if (wdev->conn_owner_nlportid == notify->portid) {
- schedule_work(&wdev->disconnect_wk);
+ wiphy_work_queue(wdev->wiphy,
+ &wdev->disconnect_wk);
}
cfg80211_release_pmsr(wdev, notify->portid);
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index b451df3096dd..2a719b5c487e 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -1578,13 +1578,11 @@ int cfg80211_disconnect(struct cfg80211_registered_device *rdev,
* Used to clean up after the connection / connection attempt owner socket
* disconnects
*/
-void cfg80211_autodisconnect_wk(struct work_struct *work)
+void cfg80211_autodisconnect_wk(struct wiphy *wiphy, struct wiphy_work *work)
{
struct wireless_dev *wdev =
container_of(work, struct wireless_dev, disconnect_wk);
- struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy);
-
- guard(wiphy)(wdev->wiphy);
+ struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
if (wdev->conn_owner_nlportid) {
switch (wdev->iftype) {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] wifi: nl80211: serialize socket owner release with netdev teardown
From: Cen Zhang @ 2026-07-06 15:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel, baijiaju1990
In-Reply-To: <a2dd36c58cb228693428c5a5abe3e14ef6376e7c.camel@sipsolutions.net>
Hi Johannes,
> Sounds like maybe it should just be a wiphy work so we don't have to
> worry about the locking at all?
Yes, that makes sense. I reworked it and will send v2.
Best regards,
Cen Zhang
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7925: Fix unregister deadlock
From: Rafael Passos @ 2026-07-06 15:06 UTC (permalink / raw)
To: JB Tsai, nbd, lorenzo
Cc: linux-wireless, linux-mediatek, Sean.Wang, Quan.Zhou, Ryder.Lee,
Leon.Yen, litien.chang, Fei Shao
In-Reply-To: <20260630090610.586954-1-jb.tsai@mediatek.com>
I was having issues with the MT7925 on the ASRock B850M with Bluetooth.
I tested this and other patches in my investigation.
My issue was a platform bug causing a failure in USB enumeration
before the driver path (unrelated to the patch).
I can confirm this patch does not introduce regressions on this platform.
I tested system power cycling and suspension, BT/Wifi adapter enable/disable,
and also modprobing in/out mt7925{e/u}
Patch applied on top of mailine (7.2 rc1).
Tested-by: Rafael Passos <rafael@rcpassos.me>
Thanks,
Rafael Passos
^ permalink raw reply
* FYI: wireless & wireless-next rebased
From: Johannes Berg @ 2026-07-06 14:54 UTC (permalink / raw)
To: linux-wireless
As much as I like to avoid it, given the linux-next reports I've rebased
both of the trees. The heads are currently:
wireless: 4a360c6e18df ("wifi: mac80211: validate deauth frame length
before reason access")
wireless-next: f9202a374ec3 ("wifi: cfg80211: support MAC address
filtering in station dump for link stats")
If you have prior versions of those commits, sorry, please rebase as
well.
(neither of the prior versions were live for very long, but I figured
I'd give a heads-up anyway)
johannes
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: mt76: fix MAC address for non OF pcie cards
From: Klara Modin @ 2026-07-06 14:40 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-wireless, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, Tobias Klausmann,
Thorsten Leemhuis, Linux kernel regressions list
In-Reply-To: <20260630210215.400379-1-rosenp@gmail.com>
On 2026-06-30 14:02:15 -0700, Rosen Penev wrote:
> If seems the check for err is wrong as the proper macaddr gets written
> to from the EEPROM itself. Meaning checking err from of_get_mac_address is
> wrong as the proper macaddr has been written by this point.
>
> Fixes: 31ee1582717e ("wifi: mt76: fix of_get_mac_address error handling")
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Tested-by: Klara Modin <klarasmodin@gmail.com>
> ---
> drivers/net/wireless/mediatek/mt76/eeprom.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/eeprom.c b/drivers/net/wireless/mediatek/mt76/eeprom.c
> index b99d7452800f..afdb73661866 100644
> --- a/drivers/net/wireless/mediatek/mt76/eeprom.c
> +++ b/drivers/net/wireless/mediatek/mt76/eeprom.c
> @@ -181,7 +181,7 @@ mt76_eeprom_override(struct mt76_phy *phy)
> if (err == -EPROBE_DEFER)
> return err;
>
> - if (err) {
> + if (!is_valid_ether_addr(phy->macaddr)) {
> eth_random_addr(phy->macaddr);
> dev_info(dev->dev,
> "Invalid MAC address, using random address %pM\n",
> --
> 2.55.0
>
^ permalink raw reply
* [PATCH net v3] wifi: mac80211: fix memory leak in ieee80211_register_hw()
From: Dawei Feng @ 2026-07-06 14:35 UTC (permalink / raw)
To: johannes
Cc: linux-wireless, linux-kernel, zilin, jianhao.xu, Dawei Feng,
stable
If kmemdup() fails while copying supported band structures, the error
path jumps to fail_rate. This skips rate_control_deinitialize() and
leaks the initialized local->rate_ctrl.
Fix this by adding a fail_band label that shares the rate-control cleanup
path before falling through to the remaining teardown.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still present in
v7.1-rc7.
An x86_64 allyesconfig build showed no new warnings. As we do not have a
suitable mac80211 device/driver combination to test with, no runtime
testing was able to be performed.
Fixes: 09b4a4faf9d0 ("mac80211: introduce capability flags for VHT EXT NSS support")
Cc: stable@vger.kernel.org
Reviewed-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
---
Changes in v3:
- Replace Zilin Guan's Signed-off-by with Reviewed-by.
Changes in v2:
- Add a fail_band label for the band-copy failure path instead of jumping
directly to fail_wiphy_register.
net/mac80211/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index f47dd58770ad..dba66dd964af 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -1599,7 +1599,7 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
sband = kmemdup(sband, sizeof(*sband), GFP_KERNEL);
if (!sband) {
result = -ENOMEM;
- goto fail_rate;
+ goto fail_band;
}
wiphy_dbg(hw->wiphy, "copying sband (band %d) due to VHT EXT NSS BW flag\n",
@@ -1675,6 +1675,7 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
#endif
wiphy_unregister(local->hw.wiphy);
fail_wiphy_register:
+ fail_band:
rtnl_lock();
rate_control_deinitialize(local);
ieee80211_remove_interfaces(local);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] wifi: nl80211: serialize socket owner release with netdev teardown
From: Johannes Berg @ 2026-07-06 14:34 UTC (permalink / raw)
To: Cen Zhang; +Cc: linux-wireless, linux-kernel, baijiaju1990
In-Reply-To: <CAFRLqsXDDO=fzwwe5eNEkS=qUjf9=2X=NrX+LcZ+TNkMN+fF5Q@mail.gmail.com>
On Mon, 2026-07-06 at 20:24 +0800, Cen Zhang wrote:
> Hi Johannes,
>
> Thanks for your review and comments.
>
> > What's that supposed to mean? Of course there's ordering between those
> > two things?
>
> You're right, that wording was imprecise.
>
> I didn't mean that NETDEV_GOING_DOWN and NETDEV_UNREGISTER are unordered with
> respect to each other. What I meant is that the NETLINK_URELEASE notifier's
> schedule_work() site is not ordered against the teardown-side
> cancel_work_sync() for the same wdev.
Yeah, fair.
> I chose RTNL because netdev notifier delivery is already serialized by RTNL,
> so it orders the existing schedule_work() producer against the existing
> cancel_work_sync() with a small change. But if you prefer moving the cancel,
> I can rework v2 in that direction.
>
> My only concern with simply moving a final cancel into
> _cfg80211_unregister_wdev() is that this path is called with the wiphy mutex
> held, while cfg80211_autodisconnect_wk() also takes the wiphy mutex. So I
> think the final drain would need to happen after the RCU readers are gone,
> but outside the wiphy lock and before the wdev/netdev lifetime can end.
Sounds like maybe it should just be a wiphy work so we don't have to
worry about the locking at all?
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox