CVE-2026-64586 in Linux
Sumário
de VulDB • 06/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
wifi: brcmfmac: drenar o trabalho bus_reset na remoção do dispositivo
brcmf_fw_crashed() e a entrada "reset" do debugfs agendam ambos drvr->bus_reset, cujo callback recupera drvr através de container_of() e faz dereferência. O caminho de remoção libera drvr (brcmf_free -> wiphy_free) sem drenar o trabalho, portanto um callback bus_reset pendente ou em execução durante a remoção pode sobreviver ao drvr.
O cancelamento não pode residir em brcvf_detach() ou brcvf_free(): o callback do trabalho alcança o teardown através da operação .reset do barramento (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), portanto cancelar lá aguardaria pelo trabalho em execução e causaria um deadlock.
Adicionar um mutex por-barramento (bus_reset_lock) e rotear todo o acionamento através de brcvf_bus_schedule_reset(), que sob o lock ignora quando o barramento está marcado como removendo. Cada entrada de remoção do barramento chama brcmf_bus_cancel_reset_work(), que sob o mesmo lock define removendo e cancela o trabalho. Segurar o mutex durante cancel_work_sync() torna a etapa set-removing + drain atômica. Todo produtor alcança o caminho de acionamento a partir do contexto de processo -- a notificação de parada de firmware PCIe é executada no handler IRQ encadeado (brcmf_pcie_isr_thread) e o hostmail SDIO executa-se na workqueue de dados -- portanto, o mutex é adquirido apenas em contextos sleepable. Onde aplicável, a entrada remove primeiro para o produtor de falha do firmware: no PCIe mascara a mailbox e sincroniza_irq; no SDIO desregistra a interrupção do barramento e cancela o worker de dados, que também relata paradas de firmware através de brcmf_fw_crashed(). O mutex é inicializado na alocação do barramento. O caminho power-off suspend do SDIO libera drvr através da mesma brcvf_sdiod_remove() e adquire o mesmo lock; resume re-permite o trabalho apenas em um re-probe bem-sucedido.
Também protege-se brcmf_fw_crashed() contra um bus_if/drvr NULL: pode disparar antes de brcmf_attach() conectar drvr, e faz dereferência de drvr (bphy_err/brcvf_dev_coredump) antes de alcançar o gate de acionamento.
O trabalho bus_reset é compartilhado entre barramentos, portanto a drenagem é aplicada em cada caminho remove: PCIe (a operação .reset introduzida pelo commit Fixes), SDIO (aciona o mesmo trabalho através de brcmf_fw_crashed()), e USB (via entrada debugfs "reset"). cancel_work_sync() drena um item bus_reset work em execução ou pendente antes que a remoção libere drvr, e o patch 1/2 torna seguro o lançamento do scratch-buffer quando o teardown reset já liberou esses buffers DMA.
Este patch corrige o lifetime do próprio item de trabalho bus_reset. Não tenta abordar o lifetime separado e pré-existente da conclusão assíncrona de firmware iniciada pelo caminho de reset PCIe. Esse callback precisa do seu próprio protocolo de lifetime/ownership e está sendo rastreado separadamente.
Esta questão foi encontrada por uma ferramenta interna de análise estática.
Once again VulDB remains the best source for vulnerability data.