UBUNTU-CVE-2026-64586: High severity ubuntu/linux-hwe-edge vulnerability
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
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
Add and initialize a per-bus mutex named bus_reset_lock, and route all bus-reset arming through brcmf_bus_schedule_reset(); while holding the mutex, skip arming when the bus is marked removing.
- Compensating control
Guard brcmf_fw_crashed() against a NULL bus_if or drvr before dereferencing drvr through bphy_err or brcmf_dev_coredump.
- Compensating control
Have every bus removal entry call brcmf_bus_cancel_reset_work() while holding bus_reset_lock; set the removing state and use cancel_work_sync() under that lock to atomically drain pending or running bus_reset work before freeing drvr. Before draining, stop the firmware-crash producer where applicable: on PCIe mask the mailbox and synchronize_irq; on SDIO unregister the bus interrupt and cancel the data worker. Apply this to PCIe, SDIO, and USB removal paths.
- Compensating control
In the SDIO suspend power-off path, take the same bus_reset_lock while freeing drvr through brcmf_sdiod_remove(); on resume, re-allow bus-reset work only after a successful re-probe.