No kernel Linux, a seguinte vulnerabilidade foi resolvida. wifi: brcmfmac: drene bus_reset trabalho na remoção do dispositivo brcmf_ fw_crashed() e a entrada de depuração "reset" tanto programar drvr->bus_reset, cujo callback recupera drvr através do container_ of() e o desrefere. O caminho de remoção liberta o drvr (brcmf_free -> wiphy_free) sem drenar o trabalho, assim um callback de bus_reset pendente ou em execução durante a remoção pode sobreviver ao drvr.
Cancelamento não pode viver em brcmf_detach() ou brcmf_free(): o callback de trabalho atinge o desmonte através do ônibus.reset op (PCIe brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), por isso cancelar lá iria esperar pelo trabalho e bloqueio em execução. Adicione um mutex por-bus (bus_reset_lock) e roteia todos os braços através do brcmf_bus_schedule_reset(), que sob o bloqueio pula quando o ônibus está marcado removendo. Cada ônibus remove chamadas brcmf_bus_cancel_reset_work(), que sob o mesmo bloqueio sets removendo e cancela o trabalho. Se segurar o mutex através de cancel_work_sync() faz com que o defeito de remoção + dreno seja atômico. Cada produtor alcança o caminho de armamento do contexto de processo -- a notificação do firmware-halt PCIe é executada no handler IRQ roscado (brcmf_pcie_isr_ thread) e o caminho do hostmail SDIO é executado a partir da queue de dados -- então o mutex é tomado apenas em contextos adormecedores. Quando aplicável, a entrada remover primeiro para o produtor de firmware- crash: no PCIe mascarar a caixa de correio e sincronizar_irq; no SDIO desregistrar o ônibus interrompe e cancelar o trabalhador de dados, que também reporta firmware para o parar através do brcmf_fw_crashed(). O mutex é inicializado na alocação do ônibus. O SDIO suspende o caminho de desligamento de energia libera o drvr através do mesmo brcmf_sdiod_ remove() e toma o mesmo bloqueio; retoma o trabalho apenas em uma re- sonda bem sucedida.
Também guarde brcmf_ fw_crashed() contra um bus_if/ drvr NULL: pode disparar antes de brcmf_ attach() subir os fios drvr, e desrefere o drvr (bphy_ err/ brcmf_dev_coredump) antes de alcançar o portão de armamento. O trabalho do bus_reset é compartilhado entre ônibus, por isso o dreno é aplicado a cada caminho remove: PCIe (o op.reset introduzido pelo commit Fixes), SDIO (arma o mesmo trabalho através do brcmf_fw_crashed()), e USB (via o item de depuração "reset"). cancel_work_sync() drena um item de trabalho do bus_reset em execução ou pendente antes de remover o drvr livre, e patch 1 / 2 torna a liberação segura do arranhão- arranhão quando o desmonte do reexame já libertou os buffers DMA.
Este patch corrige a vida útil do item de trabalho do bus_ reset. Ele não tenta abordar a vida útil separada e pré- existente da conclusão do firmware assincrono iniciada pelo caminho de reset PCIe. Esse callback necessita de seu próprio protocolo de vida/propriedade e está sendo rastreado separadamente. Este problema foi encontrado por uma ferramenta de análise estática interna.
Registro de aconselhamento: GHSA- 5 rg 4 - 8 h 2 h- x 94 w. Identificadores relacionados: CVE- 2026 - 64586. Tempo: GitHub Advisory Database publicou este registro em 2026 - 08 - 06 T 09: 30: 32.000 Z e lista a sua última modificação como 2026 - 08 - 23 T 15: 32: 55.000 Z.
Severidade: ALTAMENTE. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Software afetado: o registro de aconselhamento não fornece um pacote normalizado ou faixa de versões.
Classificação e evidência: nenhum identificador CWE está listado. O registro contém 9 suporte de referências nestes tipos: AVISO, WEB.