CVE-2026-64586 Overview
CVE-2026-64586 is a use-after-free vulnerability in the Linux kernel brcmfmac Wi-Fi driver for Broadcom FullMAC chipsets. The flaw resides in the handling of the drvr->bus_reset work item, which can outlive the drvr structure when a device is removed while a reset callback is pending or running. Both brcmf_fw_crashed() and the debugfs reset entry schedule this work, whose callback dereferences drvr through container_of(). The removal path frees drvr via brcmf_free and wiphy_free without draining the work first, creating a use-after-free window across PCIe, SDIO, and USB buses.
Critical Impact
A pending or running bus_reset callback can dereference freed driver memory during device removal, leading to kernel memory corruption on systems using Broadcom FullMAC Wi-Fi hardware.
Affected Products
- Linux kernel brcmfmac Wi-Fi driver (Broadcom FullMAC)
- PCIe, SDIO, and USB bus implementations within brcmfmac
- Distributions shipping vulnerable Linux kernel versions prior to the fix commits
Discovery Timeline
- 2026-08-06 - CVE-2026-64586 published to NVD
- 2026-08-06 - Last updated in NVD database
Technical Details for CVE-2026-64586
Vulnerability Analysis
The brcmfmac driver schedules a bus_reset work item from two producers: brcmf_fw_crashed(), invoked when firmware halts, and the debugfs reset entry, invoked from user space. The work callback recovers the drvr pointer via container_of() and dereferences it to drive teardown. On device removal, brcmf_free() and wiphy_free() release drvr without draining any pending or running instance of the work item, so a delayed callback can access freed memory [CWE-416].
Cancellation cannot be added inside brcmf_detach() or brcmf_free() because the work callback itself reaches teardown through the bus .reset operation. On PCIe, that path runs brcmf_pcie_reset -> brcmf_detach; on SDIO it runs brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free. Cancelling from inside these functions would wait for the running work and deadlock.
Root Cause
The root cause is missing lifetime coordination between the shared bus_reset work item and the drvr object it dereferences. There is no atomic step that both marks the bus as removing and drains the work, so a producer can arm the work after removal has begun.
Attack Vector
A local attacker with access to trigger firmware crashes or the debugfs reset entry can race a device removal to force the work callback to dereference freed memory. On PCIe systems, the firmware-halt notification runs in the threaded IRQ handler brcmf_pcie_isr_thread. On SDIO, the hostmail path runs from the data workqueue and can also report firmware halts through brcmf_fw_crashed(). USB systems reach the work through the debugfs reset entry.
The issue was identified by an in-house static analysis tool. No public exploit is available.
No verified proof-of-concept code is available. See the referenced
kernel commits for the exact source-level fix.
Detection Methods for CVE-2026-64586
Indicators of Compromise
- Kernel oops or panic traces referencing brcmf_bus_reset or container_of inside the brcmfmac module during device removal or firmware recovery.
- KASAN use-after-free reports naming drvr, brcmf_pcie_reset, brcmf_sdiod_remove, or brcmf_fw_crashed on kernels built with sanitizers enabled.
- Repeated firmware crash log entries from brcmfmac immediately preceding driver unload or suspend cycles.
Detection Strategies
- Enable KASAN on test kernels running affected brcmfmac versions and exercise device removal, suspend, and debugfs reset writes to surface the use-after-free.
- Audit installed kernel packages against the fix commits 177a25be1195 and 43b25879f004 to identify unpatched hosts.
- Monitor dmesg and journal output for brcmfmac firmware halt messages correlated with hotplug or suspend events.
Monitoring Recommendations
- Collect kernel ring buffer output centrally and alert on brcmfmac crash signatures tied to reset or removal paths.
- Track kernel version inventory across Linux endpoints to confirm patched builds are deployed on systems with Broadcom Wi-Fi hardware.
- Include debugfs write activity to brcmfmac reset entries in host telemetry where debugfs is exposed.
How to Mitigate CVE-2026-64586
Immediate Actions Required
- Apply the upstream fix commits 177a25be1195f8bdc6160ba5f1a5699f7041c985 and 43b25879f004c98defa2776bedc6ca4763c51945 or update to a distribution kernel that includes them.
- Restrict access to debugfs on production systems so unprivileged users cannot write to the brcmfmacreset entry.
- Prioritize patching on laptops, embedded devices, and IoT hardware that use Broadcom FullMAC Wi-Fi chipsets.
Patch Information
The fix introduces a per-bus mutex bus_reset_lock and routes all arming of the work through brcmf_bus_schedule_reset(), which skips scheduling when the bus is marked removing. Each bus remove entry calls brcmf_bus_cancel_reset_work(), which sets the removing flag and cancels the work under the same lock, making the set-removing and drain step atomic. The patch also guards brcmf_fw_crashed() against a NULL bus_if or drvr, since it can fire before brcmf_attach() wires up drvr. See Kernel Git Commit 177a25be and Kernel Git Commit 43b25879.
Workarounds
- Unload the brcmfmac module (modprobe -r brcmfmac) on systems that do not require Broadcom Wi-Fi until a patched kernel is installed.
- Mount debugfs with restrictive permissions or disable it entirely to block user-space triggering of the reset entry.
- Avoid hotplug and suspend cycles on unpatched systems experiencing repeated firmware crashes.
# Verify the running kernel and brcmfmac module status
uname -r
modinfo brcmfmac | grep -E 'filename|version'
# Temporarily unload the driver until a patched kernel is applied
sudo modprobe -r brcmfmac
# Restrict debugfs access to root only
sudo mount -o remount,mode=700 /sys/kernel/debug
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
