summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/broadcom
AgeCommit message (Collapse)Author
2 dayswifi: b43: fix use-after-free in b43_bcma_remove()Andreas Wendleder
b43_one_core_detach() frees the struct b43_wldev it is given the bus device of. b43_bcma_remove() then reads wldev->dev again to free the bus device, which is a read of freed memory. b43_ssb_remove() does not have the problem: it takes a copy of wldev->dev at the start. Do the same here. Fixes: 96838d61102a ("b43: Fix memory leaks in b43_bus_dev_ssb_init and b43_bus_dev_bcma_init") Cc: stable@vger.kernel.org Signed-off-by: Andreas Wendleder <gonsolo@gmail.com> Link: https://patch.msgid.link/20261013000124.48605-1-gonsolo@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
6 dayswifi: brcmsmac: use freq_reg_info() under RCUJohannes Berg
This will soon be required, because there won't be the RTNL to protect everything. Use RCU for freq_reg_info(). Link: https://patch.msgid.link/20261006120655.d7994c4ac0dc.If1ffc9864b3557ec046c705286e974218a32d9cc@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
6 daysMerge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.3-rc7). Conflicts: include/net/strparser.h 0984ebc631792 ("strparser: make sure __strp_recv isn't running before tearing down the parser") 02fd0a2111374 ("net: strparser: removed the aborted bit and aborts counter") https://lore.kernel.org/asYfmLsfy-SCxXjr@sirena.co.uk Adjacent changes: Documentation/networking/strparser.rst 5f193cdabf25 ("docs: networking: strparser: remove general mode") 0984ebc63179 ("strparser: make sure __strp_recv isn't running before tearing down the parser") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
8 dayswifi: brcmfmac: fix P2P device removal race in brcmf_detach()Michele Dionisio
When the driver is removed while the user space process that created the P2P device (e.g. wpa_supplicant) is still exiting, the P2P device interface is removed twice and the kernel crashes. The two paths are: - wpa_supplicant, on exit, sends NL80211_CMD_DEL_INTERFACE for the P2P device. nl80211_del_interface() holds RTNL and the wiphy mutex and calls brcmf_p2p_del_vif(), which disables discovery and waits up to 1.5 s for BRCMF_E_IF_DEL. Then it calls brcmf_remove_interface(), which unregisters the wdev and frees the vif and the ifp. - brcmf_detach() sets the bus down, so BRCMF_E_IF_DEL never arrives, and calls brcmf_remove_interface(ifp, false) for the same ifp. brcmf_p2p_ifp_removed() reads ifp->vif and then blocks on rtnl_lock(). When brcmf_p2p_del_vif() releases RTNL, it calls cfg80211_unregister_wdev() on the wdev that was already unregistered and freed. The second list_del_rcu() of wdev->list faults on LIST_POISON2: brcmfmac: brcmf_p2p_del_vif delete P2P vif brcmfmac: brcmf_p2p_deinit_discovery enter brcmfmac: brcmf_p2p_del_vif P2P: GO_NEG_PHASE status cleared brcmfmac: brcmf_detach Enter brcmfmac: brcmf_bus_change_state 1 -> 0 brcmfmac: brcmf_remove_interface Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmf_del_if Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmf_p2p_ifp_removed P2P: device interface removed [1.5 s later, brcmf_p2p_del_vif() timed out] brcmfmac: brcmf_remove_interface Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmf_del_if Enter, bsscfgidx=1, ifidx=0 brcmfmac: brcmf_p2p_ifp_removed P2P: device interface removed Unable to handle kernel paging request at virtual address dead000000000122 Internal error: Oops: 96000044 [#1] PREEMPT_RT SMP pc : _cfg80211_unregister_wdev+0x6c/0x264 [cfg80211] Call trace: _cfg80211_unregister_wdev+0x6c/0x264 [cfg80211] cfg80211_unregister_wdev+0x10/0x1c [cfg80211] brcmf_p2p_ifp_removed+0x84/0xb0 [brcmfmac] brcmf_remove_interface+0x1f4/0x254 [brcmfmac] brcmf_detach+0x88/0x180 [brcmfmac] brcmf_sdio_remove+0x90/0x7b0 [brcmfmac] brcmf_sdiod_remove+0x20/0xa0 [brcmfmac] brcmf_ops_sdio_remove+0xbc/0x12c [brcmfmac] sdio_bus_remove+0x38/0x144 device_release_driver_internal+0x1e8/0x2c0 device_release_driver+0x14/0x20 brcmf_sdio_bus_remove+0x2c/0x40 [brcmfmac] brcmf_fwvid_unregister_vendor+0xd8/0x170 [brcmfmac] __exit_compat+0x18/0x418 [brcmfmac_cyw] __arm64_sys_delete_module+0x1ac/0x244 The log was taken with debug=0x406 on an i.MX 8M Plus board with a CYW55513 (Sona IF513) on SDIO. The driver is the Ezurio backport of brcmfmac from v6.18.22 on a 5.4-rt kernel. The code involved is the same in mainline. To reproduce: 1. Start wpa_supplicant on wlan0 and let it associate. It creates the P2P device (iw dev shows "type P2P-device"). 2. Stop wpa_supplicant and remove the driver without waiting for wpa_supplicant to exit: kill $(pidof wpa_supplicant) rmmod brcmfmac_cyw brcmfmac The crash is reproducible on that board. For the interface without a netdev (the P2P device), take RTNL and the wiphy mutex in brcmf_detach() before reading iflist, and remove it with locked=true. If brcmf_p2p_del_vif() runs first, brcmf_detach() finds the slot empty. If brcmf_detach() runs first, nl80211 does not find the wdev any more. The interfaces with a netdev are removed as before, because brcmf_del_if() takes RTNL on its own for the primary interface. Fixes: 9831bcb987df ("brcmfmac: Deleting of p2p device is leaking memory.") Cc: stable@vger.kernel.org Assisted-by: claude-opus-5-5 Signed-off-by: Michele Dionisio <michele.dionisio@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260924123027.4122909-2-michele.dionisio@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
9 dayswifi: brcmsmac: Adjust txpwrindex value in nphy_ipa_rxcal_gaintbl_2GHzNathan Chancellor
After a recent change in clang to warn on signed char conversions within array initializers [1], there is a warning (or error with CONFIG_WERROR=y / W=e) from nphy_ipa_rxcal_gaintbl_2GHz: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:224:18: error: implicit conversion from 'int' to 's8' (aka 'signed char') changes value from 128 to -128 [-Werror,-Wconstant-conversion] 224 | {0, 0, 0, 0, 0, 128}, | ~ ^~~ 1 error generated. This value was introduced in the original staging merge of brcmsmac in commit a9533e7ea3c4 ("Staging: Add initial release of brcm80211 - Broadcom 802.11n wireless LAN driver.") and it is the same in the proprietary driver [2]. Presumably it is correct since there have been no reported issues, so update the value to '-128' to be type correct and clear up the warning. Cc: stable@vger.kernel.org Fixes: a9533e7ea3c4 ("Staging: Add initial release of brcm80211 - Broadcom 802.11n wireless LAN driver.") Link: https://github.com/llvm/llvm-project/commit/a5ef934a8d295dc03be3960f2b3744ec2e53238e [1] Link: https://lore.kernel.org/1a107e21b08.2873.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com/ [2] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20261005-brcmsmac-clang-24-constant-conversion-v1-1-a30c5692d582@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
10 dayswifi: b43legacy: debugfs: NUL terminate string in debugfsDan Carpenter
The "buf" buffer is PAGE_SIZE and allocated with kzalloc(). We store a string from the user in it and then pass it to sscanf() in the write functions such as tsf_write_file(). The buffer is only used to store a number so we never come close to filling up the whole PAGE_SIZE. Reserve the last character of the page for a NUL terminator. This is debugfs so it's root only. Fixes: 75388acd0cd8 ("[B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices") Signed-off-by: Dan Carpenter <error27@gmail.com> Link: https://patch.msgid.link/909ea7a88658b5e7c183bf0fda31687a91d73818.1790839793.git.error27@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
10 dayswifi: b43: don't pass unterminated string to sscanf()Dan Carpenter
The "buf" buffer is a PAGE_SIZE and allocated with kzalloc(). We store a string from the user in it and then pass it to sscanf() in the write functions such as shm32write__write_file(). Only a few numbers are stored in the buffer so it never comes close to filling up the whole PAGE_SIZE. Reserve the last character of the page for a NUL terminator. This is debugfs so it's root only. Fixes: 75388acd0cd8 ("[B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices") Signed-off-by: Dan Carpenter <error27@gmail.com> Link: https://patch.msgid.link/b396713e697c7411b23a2157e2102c347ac900bc.1790839793.git.error27@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
10 dayswifi: brcmfmac: Add clm_blob firmware for brcmfmac43456-sdioBenjamin Drung
On Ubuntu 26.10 these firmware file are missing inside the initrd when including the brcmfmac kernel module: ``` /usr/lib/firmware/brcm/brcmfmac43436-sdio.clm_blob.zst /usr/lib/firmware/brcm/brcmfmac43456-sdio.clm_blob.zst ``` So include the clm_blob firmware file for brcmfmac43456-sdio similar to the other firmware files. Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260923203739.2560527-3-benjamin.drung@canonical.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
10 dayswifi: brcmfmac: Add per-board clm_blob firmware binariesBenjamin Drung
On Ubuntu 26.10 these firmware file are missing inside the initrd when including the brcmfmac kernel module: ``` /usr/lib/firmware/brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.clm_blob.zst /usr/lib/firmware/brcm/brcmfmac43430b0-sdio.raspberrypi,model-zero-2-w.clm_blob.zst /usr/lib/firmware/brcm/brcmfmac43436-sdio.raspberrypi,model-zero-2-w.clm_blob.zst /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-a-plus.clm_blob.zst /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.clm_blob.zst /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-compute-module.clm_blob.zst /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.clm_blob.zst /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,5-compute-module.clm_blob.zst /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,5-model-b.clm_blob.zst /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,500.clm_blob.zst /usr/lib/firmware/brcm/brcmfmac43456-sdio.raspberrypi,4-compute-module.clm_blob.zst /usr/lib/firmware/brcm/brcmfmac43456-sdio.raspberrypi,400.clm_blob.zst ``` Commit 885f256f61f9 ("brcmfmac: Add clm_blob firmware files to modinfo") added clm_blob firmware binaries, but did not add them for per-board firmware binaries. So add a similar glob for the per-board firmware binaries. Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260923203739.2560527-2-benjamin.drung@canonical.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
10 dayswifi: brcmfmac: Set extsae_pwe parameter to Infineon firmware in SAP modeGirish Rudrappa
Parse and configure the extsae_pwe according to the information from the supported rate/extended support rate and RSNX IE Parse the beacon IEs on start_ap() and set the extsae_pwe iovar. Set sae_pwe to 2 when the RSNX IE advertises H2E, 1 when an H2E-only membership selector is present, 0 otherwise. The changes are tested with FW Version 7.45.286 Signed-off-by: Girish Rudrappa <girishbukkasagara.rudrappa@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260922062458.3550-1-girishbukkasagara.rudrappa@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
10 dayswifi: brcmfmac: bound NVRAM comment parsingPengpeng Hou
The NVRAM comment handler searches for a newline with strchr() even though its input is a firmware buffer with an explicit length. A comment at the end of an unterminated buffer can make the search read past that input. Keep the input extent in the parser and use bounded searches for newline and NUL. Preserve the full input length: the capped size used to allocate the output is not a bound on the input, which may contain more than 64KiB of comments. Leave the outer parsing limit unchanged. The issue was found by our static-analysis tool. Assisted-by: gpt 5 Signed-off-by: Pengpeng Hou <hppiscas@163.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260920034414.16948-1-hppiscas@163.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
10 dayswifi: brcmfmac: cfg80211: Report port_authorized for 4-way HS offloadJanne Grunau
Since commit 416386060 ("Mark authorization completed on driver indication during 4-way HS offload") [0] wpa_supplicant expects NL80211_CMD_PORT_AUTHORIZED to complete the authentication when the driver supports 4-way handshake offload. This was apparently never tested with the upstream brcmfmac driver as it does not report this. This broke authentication on Apple silicon devices (BRCM4378, BRMC4387, BRMC4388) and other devices when wpa_supplicant 2.11 was released [1]. This was initially dealt with by reverting the commit in Fedora [2] and other Linux distributions. Instead of carrying the revert over to wpa_supplicant 2.12 add the expected NL80211_CMD_PORT_AUTHORIZED when the connection is established. The "Fixes:" tag is not fully accurate as this has only became an issue after userspace changes years after the change. Since the change is expected to be required in all active stable branches for wpa_supplicant 2.11 / 2.12 compatibility it is helpful even though BRCMF_PROFILE_FWSUP_SAE did not exists then. Link: https://github.com/zephyrproject-rtos/hostap/commit/41638606054a09867fe3f9a2b5523aa4678cbfa5 [0] Link: https://lists.infradead.org/pipermail/hostap/2024-August/042893.html [1] Link: https://bugzilla.redhat.com/show_bug.cgi?id=2302577 [2] Link: https://lore.kernel.org/linux-wireless/20260911065656.1269623-5-Jason.Huang2@infineon.com/ [3] Cc: stable@vger.kernel.org Fixes: b8a64f0e96c2 ("brcmfmac: support 4-way handshake offloading for WPA/WPA2-PSK") Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Neal Gompa <neal@gompa.dev> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260915-brcmfmac-4way-handshake-offload-authenticated-event-v2-1-fbb9cc7ac177@jannau.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
10 dayswifi: brcmfmac: allow ISO3166 fallback for BCM4350Vinícius Ramon Fontanela
BCM4350 devices using brcmfmac on x86/PCIe may have no platform-provided country code map. In that case brcmf_translate_country_code() falls back to ISO3166 codes only for chips accepted by brmcf_use_iso3166_ccode_fallback(). BCM4350 is currently missing from that list, despite the adjacent BCM4345 and BCM4356 being present. Add BCM4350 so these devices can use the ISO3166 country code with revision 0. Signed-off-by: Vinícius Ramon Fontanela <vfontanela@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260915174300.28363-1-vfontanela@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
10 dayswifi: brcmfmac: Improve D3 substate entering timeout handlingSebastian Reichel
Some firmwares (e.g. BCM43752) do not service the D3_INFORM mailbox handshake when idle, so the D3 ACK never arrives. If WoWL is not armed the device is going to be powered off during system suspend and re-probed on resume anyway (brcmf_pcie_pm_leave_D3() handles that), so the missing ACK is harmless and must not abort the whole system suspend. When WoWL is active the device has to stay powered with its state preserved, so keep treating the timeout as fatal. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260915-brcmfmac-bcm43752-suspend-fix-v2-1-1bd84914998b@collabora.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-28wifi: b43legacy: work around stack frame size warningArnd Bergmann
I came across a rare warning in the b43legacy driver while building randconfig kernels using clang-21.1.8, with KASAN enabled: drivers/net/wireless/broadcom/b43legacy/main.c:3250:12: error: stack frame size (1392) exceeds limit (1280) in 'b43legacy_wireless_core_init' [-Werror,-Wframe-larger-than] 3250 | static int b43legacy_wireless_core_init(struct b43legacy_wldev *dev) | ^ There are no actual large variables on the stack here, just excessive spills, and the code looks fine otherwise, so this is really an optimization quirk in the compiler. Marking the prepare_phy_data_for_init() function as noinline completely avoids the issue, with no function in this file using more than 200 bytes of stack space, same as without KASAN. Link: https://pastebin.com/raw/KpV124Ep # .config Link: https://pastebin.com/CxWfsBN0 # assembler output, truncated Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260925130749.4191347-1-arnd@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-28wifi: cfg80211: add Control Integrity Protocol (CIP) APIsBenjamin Berg
The Control Integrity Protocol consists of a set of capabilities for the MIC padding as well as a new CIGTK that can be installed. The CIGTK uses a fixed GMAC-256 cipher for which no RSN extension is defined as it is bound to the pairwise cipher being GCMP-256. The CIGTK uses the key index 0 and 1, making it necessary to add a new key type for it. Add a new CIP feature flag and attributes for CIP Capabilities and enabling the feature for stations and the association. Also extend the cfg80211 API to pass the key type rather than a single pairwise boolean. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Link: https://patch.msgid.link/20260921144048.aa7939493375.I49c0be0a1b05d625cc307e9bdd13c32a6c18667f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-21Merge tag 'wireless-next-2026-09-21' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== More changes, including drivers: - brcmfmac: FT/OKC roaming offload - ath12k: IPQ5332 platform infrastructure - cfg80211/mac80211: non-STA TX/RX infrastructure for MLO to fix address translation bugs - the rest is mostly minor cleanups etc. * tag 'wireless-next-2026-09-21' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (101 commits) dt-bindings: net: wireless: Convert WL1251 to DT schema libertas: mesh: remove unused and undocumented sysfs attribute groups wifi: mac80211: fix multi-link UHR association wifi: nl80211: rename no-ACK bitmap to TID bitmap wifi: radiotap: correct EHT TB U-SIG 1 B20:25 wifi: ieee80211: fix FTM bufferable check wifi: mac80211: allow advertising 20 MHz-only non-AP STA wifi: mac80211: WARN on 40 MHz HT/HE mismatch wifi: mac80211: tests: fix memory leak wifi: mac80211: use assign_bit() where applicable wifi: mac80211: pass error station if non-STA transmit was requested wifi: mac80211: pass station to ieee80211_tx_skb_tid wifi: mac80211: report to cfg80211 when no STA is known for a frame wifi: cfg80211: add attribute for TX/RX denoting there is no station wifi: mac80211: rework RX packet handling wifi: mac80211: refactor RX link_id and station handling wifi: mac80211: change public RX API to use link stations wifi: iwlwifi: use link_sta internally to the driver MAINTAINERS: Replace wireless.wiki.kernel.org links wifi: brcmfmac: log the firmware status when a connect fails ... ==================== Link: https://patch.msgid.link/20260921121635.195723-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-15wifi: brcmfmac: log the firmware status when a connect failsRyohei Hashimoto
brcmf_bss_connect_done() receives the firmware event in @e but discards it on the failure path. Every failed connect is reported to cfg80211 as WLAN_STATUS_AUTH_TIMEOUT (16), whatever the firmware actually said, so userspace only ever sees: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16 The all-zero BSSID comes from the same place: conn_params is memset to zero and profile->bssid has not been filled in when the station never associated. status_code=16 therefore carries no information about the cause. It is not an AP response and it does not mean "authentication timed out" - it is the only failure value this driver can produce. This is a recurring source of confusion: [1] has been open since 2023 with more than twenty follow-ups and no explanation of the code, and covers BCM4345/6, BCM43430 and CYW43455 across several kernel versions. It supersedes [2], filed against the firmware repository a day earlier and closed in favour of it. The firmware's own status (BRCMF_E_STATUS_*) is more specific - FAIL, TIMEOUT, NO_NETWORKS, ABORT and so on - and it is already in hand. Log it so the cause can be narrowed down without rebuilding the kernel. bphy_err() is used rather than brcmf_dbg() or brcmf_info(): it is the form the rest of this file uses, and of the three it is the only one that is both visible in a distribution kernel and bounded. brcmf_dbg(CONN) expands to no_printk() unless CONFIG_BRCMDBG is set, which is what makes the reports in [1] and [2] impossible to act on - the people hitting this run stock kernels. brcmf_info() expands to a plain pr_info() in a non-debug build and is not rate limited, and wpa_supplicant retries the association every few seconds, so it would flood the log. bphy_err() is guarded by net_ratelimit() there, so a station retrying against an unreachable AP prints at most a few lines per second. All three fields are printed because only some of them are meaningful on each path into the failure branch. brcmf_is_nonetwork() keys off @status, so that is the useful field for a join that never associated - the case in [1]. brcmf_is_linkdown() keys off @event_code and @flags and does not look at @status at all, so @status can read 0 there; on those events it is @reason which carries the 802.11 reason code, as the mapping in brcmf_map_fw_linkdown_reason() shows. Printing the three together lets the reader tell which path was taken instead of guessing from one number. The status reported to cfg80211 is left alone; changing it would alter what userspace sees. [1] https://github.com/RPi-Distro/firmware-nonfree/issues/38 [2] https://github.com/raspberrypi/firmware/issues/1829 Assisted-by: Claude:claude-opus-5 Signed-off-by: Ryohei Hashimoto <laurel.medalist12@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260913165526.4426-1-laurel.medalist12@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-15wifi: brcmfmac: advertise firmware fast roam offload supportCarella Chen
Advertise NL80211_EXT_FEATURE_FAST_ROAM_OFFLOAD only when firmware reports FBT or OKC support. That lets userspace provide PMK material for firmware fast roaming without enabling the path on devices that cannot complete the offloaded roam. Assisted-by: GitHub-Copilot-CLI:gpt-5.5 Signed-off-by: Carella Chen <carella.chen@infineon.com> Signed-off-by: Jason Huang <jason.huang2@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260911065656.1269623-6-Jason.Huang2@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-15wifi: brcmfmac: report port authorization after offloaded roamingDarren Li
Firmware can complete FT or OKC roaming before the driver reports the connect or roam event to cfg80211. Detect those successful offloaded cases when the profile uses firmware 1X or roaming offload and the association request carries PMK cache state, FT is in use, or OKC is enabled. After reporting the connect or roam event, call cfg80211_port_authorized() so nl80211 emits the dedicated NL80211_CMD_PORT_AUTHORIZED event instead of reusing the reserved NL80211_ATTR_PORT_AUTHORIZED flag in CONNECT/ROAM notifications. Assisted-by: GitHub-Copilot-CLI:gpt-5.5 Signed-off-by: Darren Li <hsin-hung.li@cypress.com> Signed-off-by: Chung-Hsien Hsu <Chung-Hsien.Hsu@infineon.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by: Carella Chen <carella.chen@infineon.com> Signed-off-by: Jason Huang <jason.huang2@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260911065656.1269623-5-Jason.Huang2@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-15wifi: brcmfmac: add PMK programming for firmware roaming offloadDarren Li
FT and OKC roaming offload need PMK material in firmware even when the initial 802.1X exchange is handled by userspace. Add a roaming firmware-supplicant profile state for those connections and allow PMK configuration while firmware FT or OKC state is active. Program the OKC PMK through the okc_info_pmk iovar before setting the regular PMK when firmware reports OKC state. Only select the roaming firmware-supplicant state when firmware advertises FBT or OKC support; devices without those capabilities keep the profile in the userspace supplicant state and do not issue roaming-offload specific iovars on every connect. For FT-PSK with firmware supplicant support, keep the profile in the PSK firmware-supplicant state. Assisted-by: GitHub-Copilot-CLI:gpt-5.5 Signed-off-by: Darren Li <hsin-hung.li@cypress.com> Signed-off-by: Chung-Hsien Hsu <Chung-Hsien.Hsu@infineon.com> Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com> Co-developed-by: Carella Chen <carella.chen@infineon.com> Signed-off-by: Carella Chen <carella.chen@infineon.com> Co-developed-by: Shelley Yang <shelley.yang@infineon.com> Signed-off-by: Shelley Yang <shelley.yang@infineon.com> Signed-off-by: Jason Huang <jason.huang2@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260911065656.1269623-4-Jason.Huang2@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-15wifi: brcmfmac: detect firmware FBT and OKC supportCarella Chen
Some firmware advertises Fast BSS Transition and Opportunistic Key Caching support through the firmware capability string. Track those capabilities so later roaming offload handling can be enabled only when firmware reports support. Assisted-by: GitHub-Copilot-CLI:gpt-5.5 Signed-off-by: Carella Chen <carella.chen@infineon.com> Signed-off-by: Jason Huang <jason.huang2@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260911065656.1269623-3-Jason.Huang2@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-15wifi: brcmsmac: fix UAF in brcms_free_timer()Jiangshan Yi
brcms_free_timer() calls brcms_del_timer() which uses the non-synchronous cancel_delayed_work() to cancel the timer's underlying delayed work. If the work callback (_brcms_timer) is already running, cancel_delayed_work() returns false without waiting, and brcms_free_timer() proceeds to kfree(t) while the callback still accesses t through container_of(). Add an explicit cancel_delayed_work_sync() after brcms_del_timer() to guarantee that any in-flight callback has completed before the timer structure is freed. Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers") Cc: stable@vger.kernel.org Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260815121043.938414-1-yijiangshan@kylinos.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-15wifi: brcmfmac: fix lost 802.1x TX completion wakeupKarl Mehltretter
brcmf_txfinalize() decrements pend_8021x_cnt before a lockless waitqueue_active() check. atomic_dec() does not order the decrement against the check. The waiter can therefore observe a nonzero count while the waker observes an empty queue, losing the final wakeup and delaying key installation until the 950 ms timeout. Add smp_mb__after_atomic() to order the decrement before the queue check. wait_event_timeout() provides the matching barrier. LKMM confirms that this forbids the lost-wakeup outcome. Fixes: 21fff75d2fb6 ("brcmfmac: use wait_event_timeout for 8021x pending count") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260811082702.44521-1-kmehltretter@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: b43legacy: Use flexible array for DMA metadataRosen Penev
Store the per-descriptor metadata in the DMA ring allocation instead of allocating it separately. This ties the metadata lifetime directly to the ring, removes a separate allocation failure path, and keeps the descriptor count available for __counted_by() bounds checking. Assisted-by: Codex:GPT-5.5 Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260511041934.378209-1-rosenp@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-09-04wifi: brcmfmac: cyw: pass PMKID to firmware if presentBogdan Nicolae
Zero out auth_status on initialization. Otherwise, garbage will leak from the stack to the firmware (when ssid 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). Fixes: 66f909308a7c ("wifi: brcmfmac: cyw: support external SAE authentication in station mode") Signed-off-by: Bogdan Nicolae <bogdan.nicolae@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260807163418.487508-1-bogdan.nicolae@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-06wifi: brcmfmac: Fix memory leak in brcmf_sdio_read_control()Abdun Nihaal
The memory allocated for buf is not freed in some of the error paths in brcmf_sdio_read_control(). Fix that by adding vfree() calls. Cc: stable@vger.kernel.org Fixes: dd43a01c5cdb ("brcmfmac: use dynamically allocated control frame buffer") Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> [arend: rework as suggested by Johannes] Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260803093506.1647790-1-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: brcmfmac: fix P2P action frame handling without device vifJason Huang
Some P2P action frame paths assume the P2P device vif is always available. That is not true when userspace sends non-P2P public action frames through the primary interface, or when action-frame abort runs after the P2P device vif has not been created. Fall back to the primary vif when aborting an action frame without a P2P device vif, and guard P2P device saved IE access before using it for peer channel search. Fixes: 30fb1b272909 ("brcmfmac: use actframe_abort to cancel ongoing action frame") Fixes: 6eda4e2c5425 ("brcmfmac: Add tx p2p off-channel support.") Signed-off-by: Jason Huang <jason.huang2@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260722082608.412472-1-Jason.Huang2@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: brcmfmac: Set DMA direction for msgbuf packet IDsCan Peng
brcmf_msgbuf_init_pktids() takes the DMA direction from its callers, but never stores it in the packet ID state. Since the state is zeroed, pktids->direction remains DMA_BIDIRECTIONAL for both the TX and RX packet ID pools. All msgbuf packet ID map and unmap paths use pktids->direction. As a result, TX buffers requested with DMA_TO_DEVICE and RX buffers requested with DMA_FROM_DEVICE are mapped and unmapped as DMA_BIDIRECTIONAL instead. Store the caller-provided direction when initializing the packet ID state. Signed-off-by: Can Peng <pengcan@kylinos.cn> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260724092530.674624-1-pengcan@kylinos.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: brcmfmac: validate msgbuf flowring IDs before useCan Peng
Firmware messages carry flow_ring_id values which brcmfmac converts to an internal flowid by subtracting BRCMF_H2D_MSGRING_FLOWRING_IDSTART. The resulting value is used as a bit index in txstatus_done_map and as an array index into msgbuf->flowrings and the flowring state. Validate the firmware supplied flow_ring_id before using it. This prevents flow_ring_id values below BRCMF_H2D_MSGRING_FLOWRING_IDSTART from underflowing and rejects values outside msgbuf->max_flowrings. In the tx status path, complete the packet with an error after removing a valid packet id so the skb is not leaked when the flow ring id is invalid. Signed-off-by: Can Peng <pengcan@kylinos.cn> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260723055618.550834-1-pengcan@kylinos.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: cfg80211: convert cookie output to input parameterArend van Spriel
The remain_on_channel, mgmt_tx, and probe_peer ops previously used a u64 *cookie output parameter. Now that cfg80211 pre-assigns the cookie value before invoking drivers, the parameter conveys a value from caller to driver, not the other way around. Convert it to a plain u64 input parameter across the ops struct (cfg80211.h), rdev-ops.h wrappers, nl80211.c/mlme.c call sites, mac80211, and all driver implementations. The tx_control_port op is excluded: its cookie pointer is nullable (passed as NULL when dont_wait_for_ack is set), so the nullable pointer semantics are still required. Internal mac80211 helpers ieee80211_start_roc_work() and ieee80211_attach_ack_skb() still take u64 *cookie because they assign to the pointee; their callers now pass &cookie to take the address of the local value parameter. wil6210's internal wil_p2p_listen() is also updated to take u64 cookie since it is called directly from the remain_on_channel callback. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-12-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-08-02wifi: brcmfmac: use pre-assigned cookie for remain_on_channel and mgmt_txArend van Spriel
Stop generating cookies in brcmf_p2p_remain_on_channel() and brcmf_cfg80211_mgmt_tx(). For remain_on_channel, remove the cookie increment from brcmf_p2p_discover_listen() and store the pre-assigned cookie in p2p->remain_on_channel_cookie. The expiry callback in brcmf_p2p_notify_listen_complete() already reads from that field. For mgmt_tx, remove the "*cookie = 0" assignments in brcmf_cfg80211_mgmt_tx() and the cyw extension. The pre-assigned cookie is then correctly passed to cfg80211_mgmt_tx_status() which already uses *cookie. Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260731123509.1975281-6-arend.vanspriel@broadcom.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-27Merge tag 'wireless-2026-07-26' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== wireless-next-2026-07-26 Mostly driver changes this time: - new driver mm81x for an S1G device - new driver nxpwifi for NXP devices (mostly forked off from mwifiex) - ath12k: much kernel infrastructure integration work - brcmfmac: DPP support, some Cypress part update - nl80211: per-link statistics support ==================== Link: https://patch.msgid.link/20260726105205.942922-60-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-22wifi: brcmfmac: 43430 and 43455 are CYW partsPhil Elwell
The brcmfmac driver uses the SDIO vendor ID values to identify which vendor's driver extensions to use. However, the Cypress/Infineon devices have a vendor ID of 02d0, which is Broadcom. In order to use the Cypress driver extensions, modify the static mapping for "43430", "4345" (sic) and "43455" to indicate that they are Cypress parts. Signed-off-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Shelley Yang <shelley.yang@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260525083926.583964-1-shelley.yang@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-22wifi: brcmfmac: fix 802.1X-SHA256 call trace warningShelley Yang
Based on wpa_auth as 1x_256 mode, need to set up "use_fwsup" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]  <TASK> [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4 Fixes: 2526ff21aa77 ("brcmfmac: support 4-way handshake offloading for 802.1X") Signed-off-by: Shelley Yang <shelley.yang@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260525083859.581246-1-shelley.yang@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: brcmfmac: add DPP supportJason Huang
Add DPP AKM handling and RSN parsing support. Map DPP to the firmware wpa_auth value and recognize DPP public action frames in the P2P action-frame TX path. Gate sup_wpa programming on firmware supplicant capability. Disable it only when the selected connection mode does not use firmware supplicant. This keeps pure SAE and 802.1X firmware-supplicant paths intact while avoiding stale firmware supplicant state for DPP. Signed-off-by: Kurt Lee <kurt.lee@cypress.com> Signed-off-by: Jason Huang <jason.huang2@infineon.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260715084718.667522-1-Jason.Huang2@infineon.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: brcmfmac: set F2 blocksize to 256 for BCM43752LiangCheng Wang
The BCM43752 is not reliable with the default 512-byte SDIO function 2 block size: on an i.MX8MP board with an AMPAK AP6275S module at SDR104 / 200 MHz, an iperf TX stress test kills WLAN within seconds: mmc_submit_one: CMD53 sg block write failed -84 brcmf_sdio_dpc: failed backplane access over SDIO, halting operation Commit d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization") set up the 43752 like the 4373 for the F2 watermark but missed the F2 block size, which the 4373 limits to 256 bytes. The vendor driver (bcmdhd) also programs a 256-byte F2 block size for this chip and runs the same hardware without errors. Group the 43752 with the 4373, matching the F2 watermark handling. With this change a 10-minute bidirectional iperf3 soak completes with zero SDIO errors at ~270 Mbit/s in each direction. Backporting note: kernels before v6.18 name this id SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752, so on those trees the case label added by this patch must be adjusted to that name. Cherry-picking the rename commit 74e2ef72bd4b ("wifi: brcmfmac: fix 43752 SDIO FWVID incorrectly labelled as Cypress (CYW)") first is not a clean alternative: on trees before v6.17 its context collides with the 43751 additions, and trees before v6.2 lack the FWVID framework it touches. Fixes: d2587c57ffd8 ("brcmfmac: add 43752 SDIO ids and initialization") Cc: stable@vger.kernel.org # see patch description, needs adjustments for <= 6.17 Signed-off-by: LiangCheng Wang <zaq14760@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260715-b43752-f2-blksz-v2-1-f9be49856050@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: brcmfmac: drain bus_reset work on device removalFan Wu
brcmf_fw_crashed() and the debugfs "reset" entry both schedule drvr->bus_reset, whose callback recovers drvr through container_of() and dereferences it. The removal path frees drvr (brcmf_free -> wiphy_free) without draining the work, so a bus_reset callback pending or running during removal can outlive drvr. Cancellation cannot live in brcmf_detach() or brcmf_free(): the work callback reaches teardown through the bus .reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for the running work and deadlock. Add a per-bus mutex (bus_reset_lock) and route all arming through brcmf_bus_schedule_reset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which under the same lock sets removing and cancels the work. Holding the mutex across cancel_work_sync() makes the set-removing + drain step atomic. Every producer reaches the arming path from process context -- the PCIe firmware-halt notification runs in the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail path runs from the data workqueue -- so the mutex is taken only in sleepable contexts. Where applicable the remove entry first stops the firmware-crash producer: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmf_fw_crashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmf_sdiod_remove() and takes the same lock; resume re-allows the work only on a successful re-probe. Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire before brcmf_attach() wires up drvr, and it dereferences drvr (bphy_err/brcmf_dev_coredump) before reaching the arming gate. The bus_reset work is shared across buses, so the drain is applied to every remove path: PCIe (the .reset op introduced by the Fixes commit), SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the debugfs "reset" entry). cancel_work_sync() drains a running or pending bus_reset work item before removal frees drvr, and patch 1/2 makes the scratch-buffer release safe when reset teardown has already released those DMA buffers. This patch fixes the lifetime of the bus_reset work item itself. It does not attempt to address the separate, pre-existing lifetime of the asynchronous firmware completion started by the PCIe reset path. That callback needs its own lifetime/ownership protocol and is being tracked separately. This issue was found by an in-house static analysis tool. Fixes: 4684997d9eea ("brcmfmac: reset PCIe bus on a firmware crash") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Assisted-by: Codex:gpt-5.6 Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260718024353.3147201-3-fanwu01@zju.edu.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-21wifi: brcmfmac: make release_scratchbuffers idempotentFan Wu
brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool. Fixes: 4684997d9eea ("brcmfmac: reset PCIe bus on a firmware crash") Cc: stable@vger.kernel.org Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Assisted-by: Codex:gpt-5.6 Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260718024353.3147201-2-fanwu01@zju.edu.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-10Merge tag 'wireless-2026-07-09' of ↵Paolo Abeni
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Too many robustness fixes to list. Mostly for - slight out-of-bounds reads of SKBs, - leaks on error conditions, and - malformed netlink input rejection. * tag 'wireless-2026-07-09' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (46 commits) wifi: cfg80211: bound element ID read when checking non-inheritance wifi: brcmfmac: cyw: fix heap overflow on a short auth frame wifi: brcmfmac: initialize SDIO data work before cleanup wifi: cfg80211: validate assoc response length before status and IE access wifi: cfg80211: validate rx/tx MLME callback frame lengths before access wifi: mac80211: ibss: wait for in-flight TX on disconnect wifi: mac80211: recalculate rx_nss on IBSS peer capability update wifi: cfg80211: use wiphy work for socket owner autodisconnect wifi: mac80211: fix memory leak in ieee80211_register_hw() wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock wifi: mac80211: validate deauth frame length before reason access wifi: mac80211: avoid non-S1G AID fallback for S1G assoc wifi: cfg80211: reject empty PMSR peer lists wifi: cfg80211: reject unsupported PMSR FTM location requests wifi: cfg80211: validate PMSR FTM preamble range wifi: cfg80211: validate PMSR measurement type data wifi: nl80211: constrain MBSSID TX link ID range wifi: nl80211: validate nested MBSSID IE blobs wifi: ieee80211: validate MLE common info length wifi: cfg80211: derive S1G beacon TSF from S1G fields ... ==================== Link: https://patch.msgid.link/20260709115038.243870-3-johannes@sipsolutions.net Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-07wifi: brcmfmac: cyw: fix heap overflow on a short auth frameMaoyi Xie
brcmf_notify_auth_frame_rx() takes the frame length from the firmware event and copies the frame body with the management header offset subtracted: u32 mgmt_frame_len = e->datalen - sizeof(struct brcmf_rx_mgmt_data); ... memcpy(&mgmt_frame->u, frame, mgmt_frame_len - offsetof(struct ieee80211_mgmt, u)); The only length check is e->datalen >= sizeof(*rxframe), so mgmt_frame_len can be anything from 0 up. offsetof(struct ieee80211_mgmt, u) is 24. When mgmt_frame_len is below that, the subtraction wraps as an unsigned value to a huge length. The memcpy then runs far past the kzalloc'd buffer. A malicious or malfunctioning AP can make the frame short during the external SAE auth exchange, so this is a remotely triggered heap overflow. 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> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260627131313.3878893-1-maoyixie.tju@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-07wifi: brcmfmac: initialize SDIO data work before cleanupRunyu Xiao
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. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack. Fixes: 9982464379e8 ("brcmfmac: make sdio suspend wait for threads to freeze") Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260619064401.1048976-1-runyu.xiao@seu.edu.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-06wifi: b43, b43legacy: debugfs: use kzalloc() to allocate formatting buffersMike Rapoport (Microsoft)
b43* debugfs functions allocate 16 KiB buffers for formatting debug output text using __get_free_pages(). kzalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object and for 16 Kib allocation kzalloc() will anyway delegate it to buddy. Replace use of __get_free_pages() with kzalloc(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Link: https://patch.msgid.link/20260701-b4-drivers-wireless-v1-1-60264cdf2efe@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-07-03Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c ↵Uwe Kleine-König (The Capable Hub)
files) Replace the #include of <linux/mod_devicetable.h> by the more specific <linux/device-id/*.h> where applicable. For most cases the include can be dropped completely, only a few drivers need one or two headers added. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
2026-06-10b43: add RF power offset for N-PHY r8 + radio 2057 r8Alessio Ferri
Add the 2.4 GHz RF power offset table for N-PHY rev 8 paired with radio 2057 rev 8 and wire it to the existing dispatcher. b43_ntab_get_rf_pwr_offset_table() currently dispatches on phy->rev == 17 (radio_rev 14) and phy->rev == 16 (radio_rev 9) for 2.4 GHz. phy->rev == 8 falls through and the function logs: b43-phyX ERROR: No 2GHz RF power table available for this device Add a phy->rev == 8 / radio_rev == 8 case returning the new table. The values are sourced from the proprietary Broadcom wl driver's nphy_papd_padgain_dlt_2g_2057rev5 array. Reusing the rev 5 values is structurally appropriate: the IPA TX gain table added by the preceding patch in this series shares the low 24 bits of every entry with rev 5 - same gain step amplitudes, only the PAD-gain selector byte differs. b43's pad_gain extraction in b43_nphy_tx_pwr_ctl_init() reads bits 19..23 of the gain entry, which sit in the shared low-24-bit range; the same gain index therefore maps to the same physical PAD gain code on both revisions and warrants the same per-index dB offset. Note that b43_nphy_tx_gain_table_upload() currently has a "TODO: Enable this once we have gains configured" early-return for phy->rev >= 7. With that early-return in place, this table is fetched (silencing the b43err that would otherwise abort PHY init) but its values are not yet written to MMIO. Resolving the TODO is a future, separate task. Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-7-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10b43: add channel info table for N-PHY r8 + radio 2057 r8Alessio Ferri
Add the 2.4 GHz channel info table for N-PHY rev 8 paired with radio 2057 rev 8 and wire it to the existing dispatcher in r2057_get_chantabent_rev7(). The dispatcher's case 8 currently handles radio_rev == 5 only. For radio_rev == 8 both output pointers stay NULL, b43_nphy_set_channel() returns an error and channel switch to the default channel fails. The new b43_nphy_chantab_phy_rev8_radio_rev8[] is 14 entries covering the standard 2.4 GHz channel set (2412..2472 in 5 MHz steps, plus 2484 for channel 14). Values extracted from an MMIO dump of the proprietary Broadcom wl driver running on BCM6362 silicon (wl driver 6.30.102.7). Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-6-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8Alessio Ferri
Add the 2.4 GHz IPA TX gain table for N-PHY rev 8 paired with radio 2057 rev 8 and wire it to the existing dispatcher. b43_nphy_get_ipa_gain_table() in tables_nphy.c currently handles case 8 only for radio_rev == 5; radio_rev == 8 falls through and the function logs: b43-phyX ERROR: No 2GHz IPA gain table available for this device b43-phyX ERROR: PHY init: Channel switch to default failed leaving b43_phy_init() to return an error and core_init to abort before the MAC is enabled. The high byte of every entry differs from the rev 5 sibling (0x40 vs 0x30): different PAD-gain code prefix for the rev 8 front-end. The low 24 bits coincide with rev 5 across the whole table - the gain step amplitudes are the same, only the PAD-gain selector prefix changes. Values extracted from an MMIO dump of the proprietary Broadcom wl driver running on BCM6362 silicon (wl driver 6.30.102.7). Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-5-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10b43: support radio 2057 rev 8Alessio Ferri
Add support for radio 2057 revision 8, paired with N-PHY rev 8 on the Broadcom BCM6362 single-die integrated 2.4 GHz wireless block. Three correlated changes are needed for the same chip: - main.c: the radio_rev allow-list under B43_PHYTYPE_N currently accepts radio 2057 revisions 9 and 14 only; extend to include rev 8. - radio_2057.c: the existing r2057_rev8_init[] is a 54-entry stub declared inside a TODO comment block and never referenced from r2057_upload_inittabs(). Replace it with the full 412-entry register set actually programmed by the proprietary Broadcom wl driver on this radio. I couldn't find the origin of the original 54-entry stub - 8 of its entries do not appear at all in the rev 8 register set and 7 more carry different values. Loading it instead of using the real table leaves the radio hanging producing a "Microcode not responding" timeout. - radio_2057.c: r2057_upload_inittabs() case 8 handles radio_rev 5 and 7 only; add the radio_rev == 8 branch pointing at the new table. The init table is extracted from an MMIO dump of the radio register set programmed during proprietary driver initialisation on BCM6362 silicon (Broadcom wl driver 6.30.102.7). Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-4-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10b43: route d11 corerev 22 to 24-bit indirect radio accessAlessio Ferri
Rev 22 backports the older 802.11 core but pairs it with a radio in the 2057 family, which requires the 24-bit indirect path. With the current dispatch, corerev 22 falls into the legacy 4-wire branch, reads garbage for radio_id, and bails out with -EOPNOTSUPP at the "FOUND UNSUPPORTED RADIO" branch below. brcmsmac handles the same silicon family with the equivalent dispatch in drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/ phy_cmn.c read_radio_reg() and write_radio_reg(): if ((D11REV_GE(pi->sh->corerev, 24)) || (D11REV_IS(pi->sh->corerev, 22) && (pi->pubpi.phy_type != PHY_TYPE_SSN))) { /* radioregaddr / radioregdata (indirect) */ } else { /* phy4waddr / phy4wdatalo (legacy) */ } b43 does not support SSN/SSLPN PHYs - they are rejected earlier in b43_phy_versioning() at the "unsupported PHY type" switch - so just adding the check corerev == 22 will do. Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-3-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-10b43: add d11 core revision 0x16 to id tableAlessio Ferri
Add d11 core revision 0x16 (= 22) to the b43 bcma device id table. The b43 bcma id table covers d11 revisions 0x11, 0x15, 0x17, 0x18, 0x1C, 0x1D, 0x1E, 0x28 and 0x2A. Revision 0x16 belongs to the same N-PHY family as revisions 0x17 and 0x18 (radio 2057) and needs no new PHY or radio code beyond the radio_rev 8 dispatcher entries added later in this series - only the device id entry is missing. Without it bcma scan enumerates the 802.11 core but no driver binds. The revision is used by the Broadcom BCM6362 single-die integrated 2.4 GHz wireless block found in xDSL SoCs. Assisted-by: Claude:claude-4.7-opus Signed-off-by: Alessio Ferri <alessio.ferri@mythread.it> Acked-by: Michael Büsch <m@bues.ch> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com> Link: https://patch.msgid.link/20260528-b43_complete_n_phy_rev_8_radio_2057_rev_8_support-v4-2-464566194d47@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>