* 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
* 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: Thorsten Leemhuis @ 2026-07-06 14:21 UTC (permalink / raw)
To: B X, linux-wireless
Cc: nbd, lorenzo, ryder.lee, shayne.chen, sean.wang, regressions,
Rosen Penev
In-Reply-To: <CAPpkL-y54ySw8ftqeumccNEVatY0Zt6-Ag4PejYddK5WcsiV3A@mail.gmail.com>
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
* Re: [PATCH wireless-next v3 00/33] wifi: mm81x: add mm81x driver
From: Johannes Berg @ 2026-07-06 14:25 UTC (permalink / raw)
To: Lachlan Hodges
Cc: arien.judge, dan.callaghan, ayman.grais, linux-wireless,
Andrew Pope, Bassem Dawood, Chetan Mistry, James Herbert,
Sahand Maleki, Simon Wadsworth
In-Reply-To: <5nwjtflsihwo745k6cqi7lqsb5dblcb3fymw25y5hwcosxtfjj@y2szij6jmes2>
On Mon, 2026-07-06 at 22:50 +1000, Lachlan Hodges wrote:
> On Mon, Jul 06, 2026 at 01:45:49PM +0200, Johannes Berg wrote:
> > On Fri, 2026-06-26 at 16:28 +1000, Lachlan Hodges wrote:
> > > This series adds the first Wi-Fi HaLow driver to support the Morse
> > > Micro mm81x chip family via USB and SDIO.
> >
> > I've applied the cfg80211 patches in this set, please send a pull
> > request for the actual driver.
>
> We were actually going to send a v4 this week sometime just to modify
> the firmware path for linux-firmware... I can either just send that
> as a PR or would it be best to send a v4 as patches again? Obviously
> PR is easier but I didn't want to include further changes without
> at least letting you know.
Please just send a PR. If you want to get it merged soon then please
send it soon, there's netdevconf coming up next week.
johannes
^ permalink raw reply
* Re: [PATCH net] wifi: mac80211: fix memory leak in ieee80211_register_hw()
From: Dawei Feng @ 2026-07-06 14:24 UTC (permalink / raw)
To: johannes
Cc: dawei.feng, jeff.johnson, jianhao.xu, linux-kernel,
linux-wireless, stable, zilin
In-Reply-To: <986fff6416ba2acd8d7a4e5fb2f6a89eb40e10d1.camel@sipsolutions.net>
On Mon, 06 Jul 2026 13:47:22 +0200, Johannes Berg wrote:
> Reported-by? Reviewed-by?
>
>> To better align with the kernel submission guidelines, I will add a
>> "Co-developed-by:" tag in the v2 patch for Zilin to properly reflect his
>> contributions. Would this be acceptable?
>
> If he did development, I guess?
>
> Anyway you didn't do that for v2, so please resend after you figure out
> what you want :-)
Hi, Johannes,
Thank you for pointing out my omission. I will use Reviewed-by tags for
Zilin in v3 patch.
Best regards,
Dawei
^ permalink raw reply
* [PATCH] wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock
From: Cen Zhang @ 2026-07-06 14:08 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel, baijiaju1990, zzzccc427
ieee80211_do_stop() removes AP_VLAN packets from the parent AP
ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then
calls ieee80211_free_txskb() before dropping the lock.
ieee80211_free_txskb() is not just a passive SKB release. For SKBs with
TX status state it can report a dropped frame through cfg80211/nl80211,
and that path can reach netlink tap transmit. This is the same reason
the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs
under the queue lock and frees them after IRQ state is restored.
The buggy scenario involves two paths, with each column showing the
order within that path:
AP_VLAN management TX: AP_VLAN stop:
1. attach ACK-status state 1. clear the running state
2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs
parent ps->bc_buf disabled
3. unlink the AP_VLAN SKB
4. call ieee80211_free_txskb()
Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock,
but move them to a local free queue. Drop the lock and restore IRQ state
before calling ieee80211_free_txskb().
WARNING: kernel/softirq.c:430 at __local_bh_enable_ip
Fixes: 397a7a24ef8c ("mac80211: free ps->bc_buf skbs on vlan device stop")
Assisted-by: Codex:gpt-5.5
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
---
net/mac80211/iface.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 086272c3ec08..43460a705a6b 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -588,6 +588,7 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata, bool going_do
WARN_ON(!list_empty(&sdata->u.ap.vlans));
} else if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
/* remove all packets in parent bc_buf pointing to this dev */
+ __skb_queue_head_init(&freeq);
ps = &sdata->bss->ps;
spin_lock_irqsave(&ps->bc_buf.lock, flags);
@@ -595,10 +596,15 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata, bool going_do
if (skb->dev == sdata->dev) {
__skb_unlink(skb, &ps->bc_buf);
local->total_ps_buffered--;
- ieee80211_free_txskb(&local->hw, skb);
+ __skb_queue_tail(&freeq, skb);
}
}
spin_unlock_irqrestore(&ps->bc_buf.lock, flags);
+
+ skb_queue_walk_safe(&freeq, skb, tmp) {
+ __skb_unlink(skb, &freeq);
+ ieee80211_free_txskb(&local->hw, skb);
+ }
}
if (going_down)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 5.15.y] wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work
From: Sasha Levin @ 2026-07-06 14:08 UTC (permalink / raw)
To: Robert Garcia
Cc: Sasha Levin, stable, Duoming Zhou, Johannes Berg, linux-wireless,
Arend van Spriel
In-Reply-To: <20260706102512.1429947-1-arend.vanspriel@broadcom.com>
> The upstream fix uses timer_shutdown_sync() which prevents the timer from
> being re-armed after it returns. del_timer_sync() does not have this
> guarantee.
>
> brcmf_btcoex_handler() has three mod_timer() calls - two in
> BRCMF_BT_DHCP_START and one in BRCMF_BT_DHCP_OPPR_WIN - none of which are
> guarded by timer_on. A work item running between del_timer_sync() and
> cancel_work_sync() can re-arm the timer, leaving it pending when kfree() is
> called.
Agreed on the analysis. One thing to note: this backport already
shipped in v5.15.210, and 6.1.y shipped the same weakened
del_timer_sync() variant in v6.1.167, so this needs follow-up patches
rather than a v2 of the original.
> If the mod_timer() calls were made conditional on timer_on, setting
> timer_on = false before del_timer_sync() would be sufficient. That would be
> my preferred fix. Alternatively a second del_timer_sync() after
> cancel_work_sync() would also work.
>
> Also the commit message still mentions timer_shutdown_sync() rather than
> del_timer_sync().
There's a simpler option: timer_shutdown_sync() is actually available
in both 5.15.y and 6.1.y, so the del_timer_sync() substitution was
never necessary in the first place. A one-line follow-up converting
del_timer_sync() to timer_shutdown_sync() makes brcmf_btcoex_detach()
match the upstream post-image exactly, closes the re-arm window you
describe, and avoids a stable-only divergence guarding the mod_timer()
calls.
Robert, could you send follow-up patches for 5.15.y and 6.1.y doing
that conversion?
--
Thanks,
Sasha
^ 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-06 13:35 UTC (permalink / raw)
To: linux-wireless
Cc: nbd, lorenzo, ryder.lee, shayne.chen, sean.wang, regressions
In-Reply-To: <CAPpkL-yLfeNwsePSGDK7m8ctzPLXTVto1HhrufHv12HO0+B1Vw@mail.gmail.com>
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.
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
* Re: [PATCH] wifi: carl9170: reject mismatched command response lengths
From: Yousef Alhouseen @ 2026-07-06 13:13 UTC (permalink / raw)
To: chunkeey, chunkeey
Cc: linux-wireless, linux-kernel, stable, syzbot+5c1ca6ccaa1215781cac
In-Reply-To: <741085b4-3892-487d-a39e-75c62a7b6d0f@gmail.com>
Hi Christian,
Thanks for pointing out Tristan's earlier patch and the prior security
discussion. I had not found that submission before sending mine.
I agree that returning after carl9170_restart() is not the right fix
if the restart can unbind the device, and that the copy itself should
be bounded instead. Please drop my patch; I will defer to the existing
discussion and will not send a v2.
Thanks,
Yousef
On Sat, 4 Jul 2026 21:56:30 +0200, Christian Lamparter
<chunkeey@gmail.com> wrote:
> Hi,
>
> On 6/28/26 11:28 AM, Yousef Alhouseen wrote:
> > The firmware response length is controlled by the USB device. Although
> > carl9170_cmd_callback() detects when it differs from the output buffer
> > length, the function falls through and copies the entire response into
> > that buffer. Callers commonly provide stack objects, so a malformed
> > response can overwrite the kernel stack.
> >
> > Return after scheduling device recovery. This also preserves the stated
> > behavior of leaving the command incomplete so that its waiter times out
> > and clears the pending output buffer.
> >
> > Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend")
> > Reported-by: syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
>
> This was posted earlier too:
> https://lore.kernel.org/linux-wireless/20260421134929.325662-1-tristmd@gmail.com/
>
> In fact, there was even a mail before that that was sent to security@vger.kernel.org.
> I told Tristan that I would much rather not return and instead fix the memcpy.
> carl9170_restart can completely unbind the device, so it's unlikely that one would
> see a timeout.
>
> Cheers,
> Christian
>
> > ---
> > drivers/net/wireless/ath/carl9170/rx.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/net/wireless/ath/carl9170/rx.c b/drivers/net/wireless/ath/carl9170/rx.c
> > index 6833430130f4..ea3f435fb64c 100644
> > --- a/drivers/net/wireless/ath/carl9170/rx.c
> > +++ b/drivers/net/wireless/ath/carl9170/rx.c
> > @@ -145,6 +145,7 @@ static void carl9170_cmd_callback(struct ar9170 *ar, u32 len, void *buffer)
> > * and we get a stack trace from there.
> > */
> > carl9170_restart(ar, CARL9170_RR_INVALID_RSP);
> > + return;
> > }
> >
> > spin_lock(&ar->cmd_lock);
^ permalink raw reply
* Re: [PATCH wireless-next v3 00/33] wifi: mm81x: add mm81x driver
From: Lachlan Hodges @ 2026-07-06 12:50 UTC (permalink / raw)
To: Johannes Berg
Cc: arien.judge, dan.callaghan, ayman.grais, linux-wireless,
Andrew Pope, Bassem Dawood, Chetan Mistry, James Herbert,
Sahand Maleki, Simon Wadsworth
In-Reply-To: <c48d02d04101e50ece0feab60fb04f63aef37140.camel@sipsolutions.net>
On Mon, Jul 06, 2026 at 01:45:49PM +0200, Johannes Berg wrote:
> On Fri, 2026-06-26 at 16:28 +1000, Lachlan Hodges wrote:
> > This series adds the first Wi-Fi HaLow driver to support the Morse
> > Micro mm81x chip family via USB and SDIO.
>
> I've applied the cfg80211 patches in this set, please send a pull
> request for the actual driver.
We were actually going to send a v4 this week sometime just to modify
the firmware path for linux-firmware... I can either just send that
as a PR or would it be best to send a v4 as patches again? Obviously
PR is easier but I didn't want to include further changes without
at least letting you know.
lachlan
^ permalink raw reply
* [PATCH v2] wifi: mac80211_hwsim: clean up radio rhashtable on free
From: Cen Zhang @ 2026-07-06 12:37 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel, baijiaju1990, zzzccc427
mac80211_hwsim_free() removes each radio from hwsim_radios before calling
mac80211_hwsim_del_radio(), but leaves the matching hwsim_radios_rht entry
in place until the whole table is destroyed.
Other radio removal paths remove both the list entry and data->rht while
holding hwsim_radio_lock, before dropping the lock and deleting the radio.
Do the same here so the all-radio cleanup path follows the same object
visibility ordering.
This helper is used while all radios are being torn down, either after
callback users have already been unregistered or while module init is
unwinding, so no hwsim_radios_generation update is needed.
Assisted-by: Codex:gpt-5.5
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
---
v2:
- Reword as a small cleanup rather than a sanitizer/race report.
- Do not update hwsim_radios_generation while all radios are being torn down.
- Drop the Fixes tag from v1.
drivers/net/wireless/virtual/mac80211_hwsim_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/virtual/mac80211_hwsim_main.c b/drivers/net/wireless/virtual/mac80211_hwsim_main.c
index 0dd8a6c85953..5c59c1a8e720 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim_main.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim_main.c
@@ -6274,6 +6274,8 @@ static void mac80211_hwsim_free(void)
struct mac80211_hwsim_data,
list))) {
list_del(&data->list);
+ rhashtable_remove_fast(&hwsim_radios_rht, &data->rht,
+ hwsim_rht_params);
spin_unlock_bh(&hwsim_radio_lock);
mac80211_hwsim_del_radio(data, wiphy_name(data->hw->wiphy),
NULL);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] wifi: nl80211: serialize socket owner release with netdev teardown
From: Cen Zhang @ 2026-07-06 12:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel, baijiaju1990
In-Reply-To: <4fc7e89b3203e9bc8843c848268519d34585a038.camel@sipsolutions.net>
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 I guess that seems like it could happen.
Yes, that is the race I was trying to describe:
notifier observes conn_owner_nlportid
teardown clears the connection state and cancel_work_sync() returns
notifier then queues disconnect_wk
unregister/free can then happen before the queued work runs
> That seems a bit over the top vs. just moving the cancel - why is this
> the only correct fix?
Agreed, I should not have implied that RTNL is the only correct fix.
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.
Best regards,
Cen Zhang
^ permalink raw reply
* Re: [PATCH 0/4] bcma: support SHIM-attached big-endian SoC backplanes (BCM6362)
From: Arend van Spriel @ 2026-07-06 12:22 UTC (permalink / raw)
To: Alessio Ferri, Rafał Miłecki, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel,
Florian Fainelli
Cc: linux-kernel, linux-wireless, devicetree
In-Reply-To: <20260529-add-bcm6362-wlan-v1-0-722242777f58@gmail.com>
On 29/05/2026 02:05, Alessio Ferri wrote:
> Some BMIPS xDSL SoCs (BCM6362) integrate a Broadcom 802.11 backplane that is reachable
> through bcma but differs from the BCM47xx SoCs host_soc was written for:
> the AXI backplane is big-endian on a big-endian CPU, and the cores bcma must gate
> (ChipCommon, the 802.11 core, the SHIM core) expose no per-core DMP wrappers — clock
> and reset live in a small SoC-level SHIM Control register instead.
>
> Rather than describe these quirks as DT properties on the bcma node, the SoC-specific
> configuration is delivered to host_soc via platform_data from a parent bridge driver. The
> bcma DT node stays a plain "brcm,bus-axi" and all the 6362-specific knowledge lives in the
> bridge driver. The standard brcm,bus-axi path is unchanged.
>
> The series is:
> 1/4 bcma: support driver specific quirks from soc pdata
> 2/4 bcma: allow SHIM-style mini-EROM wrapper-less cores in scan
> 3/4 dt-bindings: bus: add brcm,bcm6362-wlan
> 4/4 bus: add BCM6362 on-chip WLAN SHIM bridge driver
>
> Patches 1-2 touch drivers/bcma (wireless tree); patch 3 is a new drivers/bus driver; patch 4 is
> the binding. The patches are sent together to keep the whole context intact.
>
> The original Broadcom driver materialized a fake PCI device, i don't think that would be allowed
> in the kernel.
>
> Tested on a D-Link DSL-3580L (BCM6362, d11 corerev 22, N-PHY):
> - SHIM brings the backplane up,
> - bcma enumerates ChipCommon + the 802.11 core,
> - b43 binds.
>
> b43 patches are necessary for the last point, but those has
> already been sent in linux-wireless.
Hi Alessio,
This patch series ended up on my patchwork plate for the linux-wireless
project. However, there is not much wifi specifics going on in these
patches that I can comment on. So this probably needs the attention of
Rafał and Florian who are already listed. Added linux-mips mailing list
here. Hopefully it showed up on the review list in other subsystems.
Regarding this hardware I suspect the rest of the SoC used the Broadcom
UBUS interconnect so the SHIM bridge would actually be a UBUS-AXI bridge
of sorts which hooks up the WLAN cores.
Regards,
Arend
> Assisted-by: Claude:claude-4.8-opus
> Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it>
>
> ---
> Alessio Ferri (4):
> bcma: support driver specific quirks from soc pdata
> bcma: allow SHIM-style mini-EROM wrapper-less cores in scan
> dt-bindings: bus: add brcm,bcm6362-wlan
> bus: add BCM6362 on-chip WLAN SHIM bridge driver
^ permalink raw reply
* Re: [PATCH] wifi: mac80211_hwsim: remove radios from rhashtable before freeing
From: Johannes Berg @ 2026-07-06 12:14 UTC (permalink / raw)
To: Cen Zhang; +Cc: linux-wireless, linux-kernel, baijiaju1990
In-Reply-To: <CAFRLqsXZYTC-AZr76+Dgj8THPqpz50-g3rH+zCg+HvD9G4QUdw@mail.gmail.com>
On Mon, 2026-07-06 at 20:10 +0800, Cen Zhang wrote:
> Hi Johannes,
>
> > How does the init even fail? I think this is fairly contrived,
> > especially in a test tool. The whole thing is maybe worth a cleanup, but
> > the whole scary commit message is nonsense.
> >
> > johannes
>
> Thanks for your review.
>
> The init failure I had in mind is a late one after radios have already
> been created and inserted into hwsim_radios_rht, for example in the
> monitor netdev setup after the radio loop. My local validation used
> fault injection at dev_alloc_name() plus a bounded debug delay to make
> that unwind window observable.
Yeah, I guess it _could_ technically happen, though I think the memory
allocation failures should be virtually impossible here. And it's hwsim
after all.
> That means the test shows the cleanup ordering issue, but it is indeed
> contrived, especially for mac80211_hwsim. The changelog I sent made this
> sound much scarier than it should have, and including the long KASAN
> report was not helpful.
Fair.
> The actual change I wanted is just the small consistency cleanup:
> mac80211_hwsim_free() should remove data->rht before freeing the radio,
> like the other radio removal paths already do.
I'd apply this, or maybe a reverse of ordering (making things visible
only after the radios exist), but please resend.
Also, if it's going to be this version, we don't really need
hwsim_radios_generation I think, anyway it's all going away so
consistency to userspace is effectively already dead at that point.
johannes
^ permalink raw reply
* Re: [PATCH] wifi: mac80211_hwsim: remove radios from rhashtable before freeing
From: Cen Zhang @ 2026-07-06 12:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel, baijiaju1990
In-Reply-To: <ab97c01b73b96bf36527007e19743d3bb5a07634.camel@sipsolutions.net>
Hi Johannes,
> How does the init even fail? I think this is fairly contrived,
> especially in a test tool. The whole thing is maybe worth a cleanup, but
> the whole scary commit message is nonsense.
>
> johannes
Thanks for your review.
The init failure I had in mind is a late one after radios have already
been created and inserted into hwsim_radios_rht, for example in the
monitor netdev setup after the radio loop. My local validation used
fault injection at dev_alloc_name() plus a bounded debug delay to make
that unwind window observable.
That means the test shows the cleanup ordering issue, but it is indeed
contrived, especially for mac80211_hwsim. The changelog I sent made this
sound much scarier than it should have, and including the long KASAN
report was not helpful.
The actual change I wanted is just the small consistency cleanup:
mac80211_hwsim_free() should remove data->rht before freeing the radio,
like the other radio removal paths already do.
Best regards,
Cen Zhang
^ permalink raw reply
* Missing signoff in the wireless tree
From: Mark Brown @ 2026-07-06 12:08 UTC (permalink / raw)
To: Johannes Berg, Wireless; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 136 bytes --]
Commit
e4fa2545a610d ("wifi: cfg80211: cancel sched scan results work on unregister")
is missing a Signed-off-by from its committer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH wireless] wifi: mac80211: clear beaconing state in ieee80211_do_stop()
From: Johannes Berg @ 2026-07-06 11:50 UTC (permalink / raw)
To: Hojun Choi
Cc: linux-wireless, linux-kernel, Deepak Karn,
syzbot+ca7a2759caaa6cd4e3db
In-Reply-To: <20260628141311.12488-1-ghwns6743@gmail.com>
On Sun, 2026-06-28 at 23:13 +0900, Hojun Choi wrote:
> Following up with the concrete path, since the question is whether
> cfg80211_leave() already covers this. It does not for AP start failure:
> ieee80211_start_ap() sets enable_beacon before its fail-able steps, but
> its error path (cfg.c:1930) only releases the channel, never clearing it
> (unlike the IBSS/mesh paths), while cfg80211 leaves ap.beacon_interval at
> 0. A later interface-down then makes ___cfg80211_stop_ap() short-circuit
> (-ENOENT, net/wireless/ap.c:30) and skip the stop_ap clear, so
> ieee80211_do_stop() runs with enable_beacon still set. I could not get a
> driver to fail start_ap() there, so this is by inspection, not a
> reproducer.
How did syzbot hit it then?
> I can fold this into the commit message in a v2, or instead fix the
> producer by clearing enable_beacon on the start_ap() error path
> (mirroring IBSS/mesh) - whichever you prefer. I used do_stop() since
> you suggested it might need to clear that bit.
Who is "you" here? I guess not me?
It seems to me the cleanup paths make more sense though? This looks
really quite out-of-place in do_stop() I think, especially the
offchannel bit? How would that even happen?
johannes
^ permalink raw reply
* Re: [PATCH net] wifi: mac80211: fix memory leak in ieee80211_register_hw()
From: Johannes Berg @ 2026-07-06 11:47 UTC (permalink / raw)
To: Dawei Feng, jeff.johnson
Cc: jianhao.xu, linux-kernel, linux-wireless, stable, zilin
In-Reply-To: <20260609074044.3745473-1-dawei.feng@seu.edu.cn>
On Tue, 2026-06-09 at 15:40 +0800, Dawei Feng wrote:
>
> Zilin is the discoverer of this bug. We are in the same research group,
> and he actively participated in reviewing this patch.
Reported-by? Reviewed-by?
> To better align with the kernel submission guidelines, I will add a
> "Co-developed-by:" tag in the v2 patch for Zilin to properly reflect his
> contributions. Would this be acceptable?
If he did development, I guess?
Anyway you didn't do that for v2, so please resend after you figure out
what you want :-)
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v3 00/33] wifi: mm81x: add mm81x driver
From: Johannes Berg @ 2026-07-06 11:45 UTC (permalink / raw)
To: Lachlan Hodges
Cc: arien.judge, dan.callaghan, ayman.grais, linux-wireless,
Andrew Pope, Bassem Dawood, Chetan Mistry, James Herbert,
Sahand Maleki, Simon Wadsworth
In-Reply-To: <20260626063014.1275235-1-lachlan.hodges@morsemicro.com>
On Fri, 2026-06-26 at 16:28 +1000, Lachlan Hodges wrote:
> This series adds the first Wi-Fi HaLow driver to support the Morse
> Micro mm81x chip family via USB and SDIO.
I've applied the cfg80211 patches in this set, please send a pull
request for the actual driver.
johannes
^ permalink raw reply
* Re: [PATCH] wifi: cfg80211: bound element ID read when checking non-inheritance
From: Johannes Berg @ 2026-07-06 11:43 UTC (permalink / raw)
To: HE WEI (ギカク); +Cc: linux-wireless, linux-kernel
In-Reply-To: <20260626144543.5034-1-skyexpoc@gmail.com>
On Fri, 2026-06-26 at 23:45 +0900, HE WEI (ギカク) wrote:
>
> Fixes: dfd9aa3e7a45 ("wifi: cfg80211: rewrite merging of inherited elements")
This doesn't seem right at all?
johannes
^ permalink raw reply
* Re: [PATCH] wifi: nl80211: serialize socket owner release with netdev teardown
From: Johannes Berg @ 2026-07-06 11:42 UTC (permalink / raw)
To: Cen Zhang; +Cc: linux-wireless, linux-kernel, baijiaju1990
In-Reply-To: <20260619162500.3876325-1-zzzccc427@gmail.com>
On Sat, 2026-06-20 at 00:25 +0800, Cen Zhang wrote:
> NETDEV_GOING_DOWN tears the interface down and cancels disconnect_wk, and
> NETDEV_UNREGISTER removes the wireless device from the cfg80211 list. There
> is no ordering between those paths today,
What's that supposed to mean? Of course there's ordering between those
two things?
> so the netlink notifier can pass
> the conn_owner_nlportid check before teardown clears it, then queue
> disconnect_wk after the NETDEV_GOING_DOWN cancel has already returned.
Yeah I guess that seems like it could happen.
> Take RTNL while the notifier walks cfg80211 devices and schedules owner
> cleanup work. Netdevice notifier delivery already runs under RTNL, so the
> schedule and cancel are ordered: either the work is queued before
> NETDEV_GOING_DOWN and the existing cancel drains it, or teardown runs first
> and the notifier no longer queues work for that connection owner.
That seems a bit over the top vs. just moving the cancel - why is this
the only correct fix?
johannes
^ permalink raw reply
* Re: [PATCH] wifi: mac80211_hwsim: remove radios from rhashtable before freeing
From: Johannes Berg @ 2026-07-06 11:38 UTC (permalink / raw)
To: Cen Zhang; +Cc: linux-wireless, linux-kernel, baijiaju1990
In-Reply-To: <20260619162419.3874564-1-zzzccc427@gmail.com>
On Sat, 2026-06-20 at 00:24 +0800, Cen Zhang wrote:
> mac80211_hwsim_new_radio() publishes each registered radio on the
> hwsim_radios list and in hwsim_radios_rht. The generic-netlink and
> virtio command paths use the rhashtable to find radios by address.
>
> Most radio removal paths remove the hash entry while holding
> hwsim_radio_lock before unregistering and freeing the radio. However,
> mac80211_hwsim_free() only removes the list entry. During init error
> unwinding after hwsim netlink and virtio registration, this can leave a
> freed radio reachable from hwsim_radios_rht until the callback surfaces
> are unpublished and the rhashtable is destroyed.
How does the init even fail? I think this is fairly contrived,
especially in a test tool. The whole thing is maybe worth a cleanup, but
the whole scary commit message is nonsense.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v5 3/4] wifi: mac80211: implement STA-mode peer probing
From: Johannes Berg @ 2026-07-06 10:54 UTC (permalink / raw)
To: Priyansha Tiwari; +Cc: veerendranath.jakkam, linux-wireless, quic_drohan
In-Reply-To: <20260611062225.2144241-4-pritiwa@qti.qualcomm.com>
On Thu, 2026-06-11 at 11:52 +0530, Priyansha Tiwari wrote:
>
> + conf = wiphy_dereference(local->hw.wiphy,
> + sdata->vif.link_conf[link_id]);
> + if (unlikely(!conf))
could drop the unlikely() that you copied - fairly pointless here
> nullfunc = skb_put(skb, size);
> + memset(nullfunc, 0, size);
skb_put_zero() exists.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v5 3/4] wifi: mac80211: implement STA-mode peer probing
From: Johannes Berg @ 2026-07-06 10:53 UTC (permalink / raw)
To: Priyansha Tiwari; +Cc: veerendranath.jakkam, linux-wireless, quic_drohan
In-Reply-To: <20260611062225.2144241-4-pritiwa@qti.qualcomm.com>
On Thu, 2026-06-11 at 11:52 +0530, Priyansha Tiwari wrote:
>
> @@ -1396,7 +1396,7 @@ struct ieee80211_tx_info {
> u8 pad;
> u16 tx_time;
> u8 flags;
> - u8 pad2;
> + u8 link_valid:1, link_id:4;
[...]
> info->control.flags |= u32_encode_bits(link_id,
> IEEE80211_TX_CTRL_MLO_LINK);
> + if (link_id != IEEE80211_LINK_UNSPECIFIED) {
> + info->status.link_valid = 1;
> + info->status.link_id = link_id;
> + }
These changes seem so *obviously* wrong that I can't believe you're
actually trying to achieve what it looks like.
I guess I'll apply patches 1 and 2.
johannes
^ permalink raw reply
* Re: [PATCH 2/3] wifi: cfg80211: validate assoc response length before status and IE access
From: Johannes Berg @ 2026-07-06 10:39 UTC (permalink / raw)
To: Zhao Li; +Cc: linux-wireless, linux-kernel
In-Reply-To: <20260612185042.66260-5-enderaoelyther@gmail.com>
On Sat, 2026-06-13 at 02:50 +0800, Zhao Li wrote:
> 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.
What makes you claim "unsafe"?
johannes
^ permalink raw reply
* Re: [PATCH 1/3] wifi: cfg80211: validate rx/tx MLME callback frame lengths before access
From: Johannes Berg @ 2026-07-06 10:37 UTC (permalink / raw)
To: Zhao Li; +Cc: linux-wireless, linux-kernel
In-Reply-To: <20260612185042.66260-4-enderaoelyther@gmail.com>
On Sat, 2026-06-13 at 02:50 +0800, Zhao Li wrote:
> cfg80211_rx_mlme_mgmt() and cfg80211_tx_mlme_mgmt() read the frame
> control field without first checking len >= 2, then dispatch into
> subtype handlers that assume their fixed fields are present.
>
> 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 replaced by a silent early return, since
> these cfg80211 callbacks can legitimately receive short frames from
> drivers.
Can they? How?
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