CVE-2026-64586

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: drain bus_reset work on device removal<br /> <br /> brcmf_fw_crashed() and the debugfs "reset" entry both schedule<br /> drvr-&gt;bus_reset, whose callback recovers drvr through container_of()<br /> and dereferences it. The removal path frees drvr (brcmf_free -&gt;<br /> wiphy_free) without draining the work, so a bus_reset callback pending<br /> or running during removal can outlive drvr.<br /> <br /> Cancellation cannot live in brcmf_detach() or brcmf_free(): the work<br /> callback reaches teardown through the bus .reset op (PCIe<br /> brcmf_pcie_reset -&gt; brcmf_detach; SDIO brcmf_sdio_bus_reset -&gt;<br /> brcmf_sdiod_remove -&gt; brcmf_free), so cancelling there would wait for<br /> the running work and deadlock.<br /> <br /> Add a per-bus mutex (bus_reset_lock) and route all arming through<br /> brcmf_bus_schedule_reset(), which under the lock skips when the bus is<br /> marked removing. Each bus remove entry calls<br /> brcmf_bus_cancel_reset_work(), which under the same lock sets removing<br /> and cancels the work. Holding the mutex across cancel_work_sync() makes<br /> the set-removing + drain step atomic. Every producer reaches the arming<br /> path from process context -- the PCIe firmware-halt notification runs in<br /> the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail<br /> path runs from the data workqueue -- so the mutex is taken only in<br /> sleepable contexts. Where applicable the remove entry first stops the<br /> firmware-crash producer: on PCIe mask the mailbox and synchronize_irq;<br /> on SDIO unregister the bus interrupt and cancel the data worker, which<br /> also reports firmware halts through brcmf_fw_crashed(). The mutex is<br /> initialized at bus allocation. The SDIO suspend power-off path frees<br /> drvr through the same brcmf_sdiod_remove() and takes the same lock;<br /> resume re-allows the work only on a successful re-probe.<br /> <br /> Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire<br /> before brcmf_attach() wires up drvr, and it dereferences drvr<br /> (bphy_err/brcmf_dev_coredump) before reaching the arming gate.<br /> <br /> The bus_reset work is shared across buses, so the drain is applied to<br /> every remove path: PCIe (the .reset op introduced by the Fixes commit),<br /> SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the<br /> debugfs "reset" entry). cancel_work_sync() drains a running or pending<br /> bus_reset work item before removal frees drvr, and patch 1/2 makes the<br /> scratch-buffer release safe when reset teardown has already released<br /> those DMA buffers.<br /> <br /> This patch fixes the lifetime of the bus_reset work item itself. It does<br /> not attempt to address the separate, pre-existing lifetime of the<br /> asynchronous firmware completion started by the PCIe reset path. That<br /> callback needs its own lifetime/ownership protocol and is being tracked<br /> separately.<br /> <br /> This issue was found by an in-house static analysis tool.