<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/wireless/broadcom, branch v7.1.6</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v7.1.6</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v7.1.6'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-08-03T09:25:51+00:00</updated>
<entry>
<title>wifi: brcmfmac: set F2 blocksize to 256 for BCM43752</title>
<updated>2026-08-03T09:25:51+00:00</updated>
<author>
<name>LiangCheng Wang</name>
<email>zaq14760@gmail.com</email>
</author>
<published>2026-07-15T06:49:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a1734263befc5c9b47299ec54c5efa470d37ed22'/>
<id>urn:sha1:a1734263befc5c9b47299ec54c5efa470d37ed22</id>
<content type='text'>
commit 29ab31f3f27157648f2f7e6d5e1fd9792fdf0614 upstream.

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 &lt;= 6.17
Signed-off-by: LiangCheng Wang &lt;zaq14760@gmail.com&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Link: https://patch.msgid.link/20260715-b43752-f2-blksz-v2-1-f9be49856050@gmail.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcmfmac: make release_scratchbuffers idempotent</title>
<updated>2026-08-03T09:25:51+00:00</updated>
<author>
<name>Fan Wu</name>
<email>fanwu01@zju.edu.cn</email>
</author>
<published>2026-07-18T02:43:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0ca80328df23f851c86866720d4977783c919ee6'/>
<id>urn:sha1:0ca80328df23f851c86866720d4977783c919ee6</id>
<content type='text'>
commit 538c51e9d124cf656f2dd0c0394a8545efc7102d upstream.

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 &lt;fanwu01@zju.edu.cn&gt;
Assisted-by: Codex:gpt-5.6
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Link: https://patch.msgid.link/20260718024353.3147201-2-fanwu01@zju.edu.cn
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcmfmac: drain bus_reset work on device removal</title>
<updated>2026-08-03T09:25:51+00:00</updated>
<author>
<name>Fan Wu</name>
<email>fanwu01@zju.edu.cn</email>
</author>
<published>2026-07-18T02:43:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=177a25be1195f8bdc6160ba5f1a5699f7041c985'/>
<id>urn:sha1:177a25be1195f8bdc6160ba5f1a5699f7041c985</id>
<content type='text'>
commit 43b25879f004c98defa2776bedc6ca4763c51945 upstream.

brcmf_fw_crashed() and the debugfs "reset" entry both schedule
drvr-&gt;bus_reset, whose callback recovers drvr through container_of()
and dereferences it.  The removal path frees drvr (brcmf_free -&gt;
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 -&gt; brcmf_detach; SDIO brcmf_sdio_bus_reset -&gt;
brcmf_sdiod_remove -&gt; 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 &lt;fanwu01@zju.edu.cn&gt;
Assisted-by: Codex:gpt-5.6
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Link: https://patch.msgid.link/20260718024353.3147201-3-fanwu01@zju.edu.cn
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcmfmac: fix 802.1X-SHA256 call trace warning</title>
<updated>2026-08-03T09:25:34+00:00</updated>
<author>
<name>Shelley Yang</name>
<email>shelley.yang@infineon.com</email>
</author>
<published>2026-05-25T08:38:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bd4fac033bb95fcad898cf6734e869991b2561cb'/>
<id>urn:sha1:bd4fac033bb95fcad898cf6734e869991b2561cb</id>
<content type='text'>
[ Upstream commit 7cb34f6c4fe8a68af621d870abe63bfca2275dd6 ]

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]  &lt;TASK&gt;
[ 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 &lt;shelley.yang@infineon.com&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Link: https://patch.msgid.link/20260525083859.581246-1-shelley.yang@infineon.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcmfmac: initialize SDIO data work before cleanup</title>
<updated>2026-08-03T09:25:20+00:00</updated>
<author>
<name>Runyu Xiao</name>
<email>runyu.xiao@seu.edu.cn</email>
</author>
<published>2026-06-19T06:44:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c73c3fc1c7ca5a927639f0884624cb244ba791e4'/>
<id>urn:sha1:c73c3fc1c7ca5a927639f0884624cb244ba791e4</id>
<content type='text'>
[ Upstream commit 2a665946e0407a05a3f81bd56a08553c446498e0 ]

brcmf_sdio_probe() stores the newly allocated bus in sdiodev-&gt;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-&gt;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(&amp;bus-&gt;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 &lt;runyu.xiao@seu.edu.cn&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Link: https://patch.msgid.link/20260619064401.1048976-1-runyu.xiao@seu.edu.cn
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: brcmfmac: cyw: fix heap overflow on a short auth frame</title>
<updated>2026-07-24T14:21:21+00:00</updated>
<author>
<name>Maoyi Xie</name>
<email>maoyixie.tju@gmail.com</email>
</author>
<published>2026-06-27T13:13:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=185bb156c427d0f865d344a6d0eaa02c6d05cc57'/>
<id>urn:sha1:185bb156c427d0f865d344a6d0eaa02c6d05cc57</id>
<content type='text'>
commit 240c8d2c717b3f8153e7e877b22a82518d78dbdc upstream.

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-&gt;datalen - sizeof(struct brcmf_rx_mgmt_data);
	...
	memcpy(&amp;mgmt_frame-&gt;u, frame,
	       mgmt_frame_len - offsetof(struct ieee80211_mgmt, u));

The only length check is e-&gt;datalen &gt;= 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 &lt;kaixuan.li@ntu.edu.sg&gt;
Signed-off-by: Kaixuan Li &lt;kaixuan.li@ntu.edu.sg&gt;
Signed-off-by: Maoyi Xie &lt;maoyixie.tju@gmail.com&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Link: https://patch.msgid.link/20260627131313.3878893-1-maoyixie.tju@gmail.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wifi: b43legacy: enforce bounds check on firmware key index in RX path</title>
<updated>2026-04-27T10:39:57+00:00</updated>
<author>
<name>Tristan Madani</name>
<email>tristan@talencesecurity.com</email>
</author>
<published>2026-04-17T11:11:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a035766f970bde2d4298346a31a80685be5c0205'/>
<id>urn:sha1:a035766f970bde2d4298346a31a80685be5c0205</id>
<content type='text'>
Same fix as b43: the firmware-controlled key index in b43legacy_rx()
can exceed dev-&gt;max_nr_keys. The existing B43legacy_WARN_ON is
non-enforcing in production builds, allowing an out-of-bounds read of
dev-&gt;key[].

Make the check enforcing by dropping the frame for invalid indices.

Fixes: 75388acd0cd8 ("[B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani &lt;tristan@talencesecurity.com&gt;
Link: https://patch.msgid.link/20260417111145.2694196-2-tristmd@gmail.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: b43: enforce bounds check on firmware key index in b43_rx()</title>
<updated>2026-04-27T10:39:57+00:00</updated>
<author>
<name>Tristan Madani</name>
<email>tristan@talencesecurity.com</email>
</author>
<published>2026-04-17T11:11:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1f4f78bf8549e6ac4f04fba4176854f3a6e0c332'/>
<id>urn:sha1:1f4f78bf8549e6ac4f04fba4176854f3a6e0c332</id>
<content type='text'>
The firmware-controlled key index in b43_rx() can exceed the dev-&gt;key[]
array size (58 entries). The existing B43_WARN_ON is non-enforcing in
production builds, allowing an out-of-bounds read.

Make the B43_WARN_ON check enforcing by dropping the frame when the
firmware returns an invalid key index.

Suggested-by: Jonas Gorski &lt;jonas.gorski@gmail.com&gt;
Acked-by: Michael Büsch &lt;m@bues.ch&gt;
Fixes: e4d6b7951812 ("[B43]: add mac80211-based driver for modern BCM43xx devices")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani &lt;tristan@talencesecurity.com&gt;
Link: https://patch.msgid.link/20260417111145.2694196-1-tristmd@gmail.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task</title>
<updated>2026-04-27T10:37:54+00:00</updated>
<author>
<name>Marek Szyprowski</name>
<email>m.szyprowski@samsung.com</email>
</author>
<published>2026-04-16T09:33:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c623b63580880cc742255eaed3d79804c1b91143'/>
<id>urn:sha1:c623b63580880cc742255eaed3d79804c1b91143</id>
<content type='text'>
Watchdog task might end between send_sig() and kthread_stop() calls, what
results in the use-after-free issue. Fix this by increasing watchdog task
reference count before calling send_sig() and dropping it by switching to
kthread_stop_put().

Cc: stable@vger.kernel.org
Fixes: 373c83a801f1 ("brcmfmac: stop watchdog before detach and free everything")
Fixes: a9ffda88be74 ("brcm80211: fmac: abstract bus_stop interface function pointer")
Signed-off-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Acked-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Link: https://patch.msgid.link/20260416093339.2066829-1-m.szyprowski@samsung.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'wireless-next-2026-04-10' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next</title>
<updated>2026-04-12T16:17:42+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2026-04-12T16:17:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=118cbd428e434bc1b8aac92a74b4992c7683f0fe'/>
<id>urn:sha1:118cbd428e434bc1b8aac92a74b4992c7683f0fe</id>
<content type='text'>
Johannes Berg says:

====================
Final updates, notably:
 - crypto: move Michael MIC code into wireless (only)
 - mac80211:
   - multi-link 4-addr support
   - NAN data support (but no drivers yet)
 - ath10k: DT quirk to make it work on some devices
 - ath12k: IPQ5424 support
 - rtw89: USB improvements for performance

* tag 'wireless-next-2026-04-10' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (124 commits)
  wifi: cfg80211: Explicitly include &lt;linux/export.h&gt; in michael-mic.c
  wifi: ath10k: Add device-tree quirk to skip host cap QMI requests
  dt-bindings: wireless: ath10k: Add quirk to skip host cap QMI requests
  crypto: Remove michael_mic from crypto_shash API
  wifi: ipw2x00: Use michael_mic() from cfg80211
  wifi: ath12k: Use michael_mic() from cfg80211
  wifi: ath11k: Use michael_mic() from cfg80211
  wifi: mac80211, cfg80211: Export michael_mic() and move it to cfg80211
  wifi: ipw2x00: Rename michael_mic() to libipw_michael_mic()
  wifi: libertas_tf: refactor endpoint lookup
  wifi: libertas: refactor endpoint lookup
  wifi: at76c50x: refactor endpoint lookup
  wifi: ath12k: Enable IPQ5424 WiFi device support
  wifi: ath12k: Add CE remap hardware parameters for IPQ5424
  wifi: ath12k: add ath12k_hw_regs for IPQ5424
  wifi: ath12k: add ath12k_hw_version_map entry for IPQ5424
  wifi: ath12k: Add ath12k_hw_params for IPQ5424
  dt-bindings: net: wireless: add ath12k wifi device IPQ5424
  wifi: ath10k: fix station lookup failure during disconnect
  wifi: ath12k: Create symlink for each radio in a wiphy
  ...
====================

Link: https://patch.msgid.link/20260410064703.735099-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
</feed>
