CVE-2026-64586: wifi: brcmfmac: drain bus_reset work on device removal
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: drain busreset work on device removal
brcmffwcrashed() and the debugfs "reset" entry both schedule drvr->busreset, whose callback recovers drvr through containerof() and dereferences it. The removal path frees drvr (brcmffree -> wiphyfree) without draining the work, so a busreset callback pending or running during removal can outlive drvr.
Cancellation cannot live in brcmfdetach() or brcmffree(): the work callback reaches teardown through the bus .reset op (PCIe brcmfpciereset -> brcmfdetach; SDIO brcmfsdiobusreset -> brcmfsdiodremove -> brcmffree), so cancelling there would wait for the running work and deadlock.
Add a per-bus mutex (busresetlock) and route all arming through brcmfbusschedulereset(), which under the lock skips when the bus is marked removing. Each bus remove entry calls brcmfbuscancelresetwork(), which under the same lock sets removing and cancels the work. Holding the mutex across cancelworksync() 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 (brcmfpcieisrthread) 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 synchronizeirq; on SDIO unregister the bus interrupt and cancel the data worker, which also reports firmware halts through brcmffwcrashed(). The mutex is initialized at bus allocation. The SDIO suspend power-off path frees drvr through the same brcmfsdiodremove() and takes the same lock; resume re-allows the work only on a successful re-probe.
Also guard brcmffwcrashed() against a NULL busif/drvr: it can fire before brcmfattach() wires up drvr, and it dereferences drvr (bphyerr/brcmfdevcoredump) before reaching the arming gate.
The busreset 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 brcmffwcrashed()), and USB (via the debugfs "reset" entry). cancelworksync() drains a running or pending busreset 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 busreset 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.190-1Fixed in 6.12.107-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.13-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 6.8.0-1035.38 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Compensating control
In brcmfmac, add and initialize a per-bus mutex named bus_reset_lock; route all bus-reset arming through brcmf_bus_schedule_reset(), which acquires the mutex and skips scheduling when the bus is marked removing.
- Compensating control
Guard brcmf_fw_crashed() against a NULL bus_if or drvr before dereferencing drvr, because it can run before brcmf_attach() wires up drvr.
- Operational
On every brcmfmac bus removal path, first stop the firmware-crash producer where applicable, set the bus as removing under bus_reset_lock, and call brcmf_bus_cancel_reset_work() with cancel_work_sync() while holding the same lock so pending or running bus_reset work is drained before drvr is freed. For PCIe, mask the mailbox and synchronize_irq; for SDIO, unregister the bus interrupt and cancel the data worker.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-64586?
CVE-2026-64586 has been assigned a risk score of 44, indicating a moderate severity level.
What are the impacts of CVE-2026-64586?
CVE-2026-64586 can lead to potential data corruption or system crashes due to incorrect handling of device removal in the Linux kernel.
How do I fix CVE-2026-64586?
To fix CVE-2026-64586, update the Linux kernel to the version that includes the patch addressing this vulnerability.
Which systems are affected by CVE-2026-64586?
CVE-2026-64586 affects systems running vulnerable versions of the Linux kernel that utilize the brcmfmac driver.
When was CVE-2026-64586 published?
CVE-2026-64586 was published on August 6, 2026.