CVE-2026-64586 in Linux
Résumé
par VulDB • 06/08/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
wifi: brcmfmac : vider (drain) l’œuvre bus_reset lors du retrait de l’appareil
brcmf_fw_crashed() et l’entrée « reset » de debugfs planifient tous deux drvr->bus_reset, dont la fonction de rappel récupère drvr via container_of() puis le déréférence. Le chemin de suppression libère drvr (brcmf_free -> wiphy_free) sans vider les œuvres en attente ; ainsi, une fonction de rappel bus_reset en attente ou en cours d’exécution pendant la suppression peut survivre à drvr.
L’annulation ne peut pas être placée dans brcrf_detach() ou brcmf_free() : le callback de l’œuvre atteint la phase de démontage via l’opération .reset du bus (PCIe brcmf_pcie_reset -> brcmf_detach ; SDIO brcmf_sdio_bus_reset -> brcmf_sdiod_remove -> brcmf_free), donc annuler à cet endroit attendrait que l’œuvre en cours s’exécute et provoquerait une interblocage (deadlock).
Ajout d’un mutex par bus (bus_reset_lock) et routage de toute activation via brcmf_bus_schedule_reset(), qui, sous verrou, saute si le bus est marqué comme étant supprimé. Chaque point d’entrée de suppression de bus appelle brcmf_bus_cancel_reset_work(), qui, sous le même verrou, définit l’état « en cours de suppression » et annule l’œuvre. Le maintien du mutex pendant cancel_work_sync() rend les étapes de définition de l’état « supprimé » + vidage atomiques. Tous les producteurs atteignent le chemin d’activation depuis un contexte processus : la notification d’arrêt du firmware PCIe s’exécute dans le gestionnaire d’interruption threadé (brcmf_pcie_isr_thread) et le chemin SDIO hostmail s’exécute à partir de l’aire de travail des données ; ainsi, le mutex n’est acquis que dans des contextes dormants (sleepable). Le cas échéant, le point d’entrée de suppression arrête d’abord le producteur de crash du firmware : sur PCIe, masquer la messagerie et synchroniser_irq ; sur SDIO, désenregistrer l’interruption du bus et annuler l’œuvre des données, qui signale également les arrêts du firmware via brcmf_fw_crashed(). Le mutex est initialisé lors de l’allocation du bus. Le chemin d’arrêt (suspend) / mise hors tension SDIO libère drvr via le même brcmf_sdiod_remove() et acquiert le même verrou ; la reprise ne réautorise l’œuvre qu’en cas de nouveau sondage réussi.
Protéger également brcmf_fw_crashed() contre un bus_if/drvr NULL : il peut se déclencher avant que brcmf_attach() n’associe drvr, et il déréférence drvr (bphy_err/brcmf_dev_coredump) avant d’atteindre la porte d’activation.
L’œuvre bus_reset étant partagée entre les buses, le vidage est appliqué à chaque chemin de suppression : PCIe (l’opération .reset introduite par l’engagement Fixes), SDIO (active la même œuvre via brcmf_fw_crashed()), et USB (via l’entrée debugfs « reset »). cancel_work_sync() vide une œuvre bus_reset en cours d’exécution ou en attente avant que la suppression ne libère drvr, et le correctif 1/2 rend sécurisée la libération du tampon temporaire lorsque le démontage de la réinitialisation a déjà libéré ces buffers DMA.
Ce correctif corrige la durée de vie de l’élément d’œuvre bus_reset lui-même. Il ne tente pas de traiter la durée de vie distincte et préexistante de la complétion asynchrone du firmware initiée par le chemin de réinitialisation PCIe. Ce callback nécessite son propre protocole de gestion des durées de vie/propriété et est suivi séparément.
Ce problème a été détecté par un outil d’analyse statique interne.
Be aware that VulDB is the high quality source for vulnerability data.