From: Sean Anderson <sanderson@brivo.com>
To: Arend van Spriel <arend.vanspriel@broadcom.com>,
linux-wireless@vger.kernel.org
Cc: "Johannes Berg" <johannes.berg@intel.com>,
brcm80211@lists.linux.dev, linux-kernel@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com,
"Sean Anderson" <sanderson@brivo.com>,
"Cássio Gabriel" <cassiogabrielcontato@gmail.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Fan Wu" <fanwu01@zju.edu.cn>,
"Franky Lin" <franky.lin@broadcom.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"John W. Linville" <linville@tuxdriver.com>,
"Luis Chamberlain" <mcgrof@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Takashi Iwai" <tiwai@suse.de>,
driver-core@lists.linux.dev
Subject: [PATCH 0/4] wifi: brcmfmac: Fix bugs when the device is removed before firmware is loaded
Date: Mon, 21 Sep 2026 17:18:10 -0400 [thread overview]
Message-ID: <20260921211817.2432341-1-sanderson@brivo.com> (raw)
I was working on a different bug, and I noticed that brcmfmac tends to
crash quite spectacularly when the device gets removed before the
firmware request completes. This is because brcmfmac does quite a lot of
initialization that would be normally be done in probe() only when the
firmware is loaded. I found two general classes of bugs:
- Some of the remove paths try to clean up things that the firmware
request callback sets up, which doesn't work too well if the firmware
isn't loaded (patches 1 and 2).
- The firmware request callback generally assumes that the driver is
still alive and kicking. So if it runs after the driver is removed it
will procede to access all sorts of memory after it's been free'd.
A fairly-reliable way to trigger these bugs is to edit really_probe in
drivers/base/dd.c and replace
IS_ENABLED(CONFIG_DEBUG_TEST_DRIVER_REMOVE)
with
!strcmp("brcmfmac", drv->name)
Alternatively, you can use the name of the bus's driver.
I have only tested these fixes on SDIO. I would really appreciate if
someone could test this series on PCIe with the above snippet in their
kernel (preferably with KASAN).
Right now if the firmware cannot be loaded for whatever reason then the
firmware request callback will unbind the driver. This is incompatible
with canceling the firmware request and waiting for it to complete in
the driver's remove() callback. As such, I removed this behavior so the
device now sticks around even if we can't load the firmware. If this
behavior is really, truly desired then we can drop device_lock while
waiting for the firmware request to complete and attempt to recover from
the consequences.
Sean Anderson (4):
wifi: brcmfmac: Fix canceling uninitialized datawork
wifi: brcmfmac: Fix brcmf_pno_detach NULL-pointer deference
firmware_loader: Return status from request_firmware_nowait_cancel
wifi: brcmfmac: Fix firmware requests racing against SDIO removal
drivers/base/firmware_loader/main.c | 11 +++++---
.../broadcom/brcm80211/brcmfmac/bcmsdh.c | 7 ++++-
.../broadcom/brcm80211/brcmfmac/bus.h | 2 ++
.../broadcom/brcm80211/brcmfmac/core.c | 3 +--
.../broadcom/brcm80211/brcmfmac/firmware.c | 26 ++++++++++++++++---
.../broadcom/brcm80211/brcmfmac/firmware.h | 16 +++++++++++-
.../broadcom/brcm80211/brcmfmac/pcie.c | 11 +++++---
.../broadcom/brcm80211/brcmfmac/pno.c | 2 ++
.../broadcom/brcm80211/brcmfmac/sdio.c | 8 +++---
.../broadcom/brcm80211/brcmfmac/usb.c | 6 +++--
include/linux/firmware.h | 2 +-
11 files changed, 75 insertions(+), 19 deletions(-)
---
base-commit: 587858367581b9c55c3690f4e63382ad622719d4
branch: brcmfmac_firmware_cancel
--
2.53.0
next reply other threads:[~2026-09-21 21:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 21:18 Sean Anderson [this message]
2026-09-21 21:18 ` [PATCH 1/4] wifi: brcmfmac: Fix canceling uninitialized datawork Sean Anderson
2026-09-21 21:18 ` [PATCH 2/4] wifi: brcmfmac: Fix brcmf_pno_detach NULL-pointer deference Sean Anderson
2026-09-21 21:18 ` [PATCH 3/4] firmware_loader: Return status from request_firmware_nowait_cancel Sean Anderson
2026-09-21 21:18 ` [PATCH 4/4] wifi: brcmfmac: Fix firmware requests racing against SDIO removal Sean Anderson
2026-09-22 13:33 ` Sean Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260921211817.2432341-1-sanderson@brivo.com \
--to=sanderson@brivo.com \
--cc=arend.vanspriel@broadcom.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=brcm80211@lists.linux.dev \
--cc=cassiogabrielcontato@gmail.com \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=fanwu01@zju.edu.cn \
--cc=franky.lin@broadcom.com \
--cc=gregkh@linuxfoundation.org \
--cc=johannes.berg@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mcgrof@kernel.org \
--cc=rafael@kernel.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox