CVE-2026-74407

Vulnérabilité élevée dans Linux (Linux)

CVSS 8.8 · Élevée
EPSS 0.4%
Linux•Linux•Versions : <6dd3701facc0cee62d6682e49eed64499f9d0e43, 7.1.5, <=*, <53dd29e8aeb2a1b5f079178551836b85fc6b53df, <=6.18.*, <=7.1.*, 6.18.53, 13da397f884d9c9a3fb6616206eeb6c6ab097287, 0, 7.2, <5.19, 5.19, <8c79aac429b583301f387374ff37c59be671df87

Description

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: cancel SSR work items during PCI shutdown A reboot can crash the kernel if it overlaps with WLAN firmware crash recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown path while freeing DMA-backed MHI contexts. Simplified trace: dma_free_attrs mhi_deinit_dev_ctxt [mhi] ath11k_pci_power_down [ath11k_pci] ath11k_pci_shutdown [ath11k_pci] device_shutdown kernel_restart On the host side, SSR is driven by the MHI RDDM callback, which queues reset_work to perform device recovery. reset_work power-cycles the device by calling ath11k_hif_power_down() followed by ath11k_hif_power_up(). The power-down phase deinitializes MHI and frees DMA resources. Shutdown/reboot runs fully asynchronously with this RDDM-driven SSR recovery flow. As a result, the shutdown path (ath11k_pci_shutdown() -> ath11k_pci_power_down()) can race with the SSR recovery sequence. Fix this by canceling SSR-related work items during PCI shutdown, marking the device as unregistering, and serializing the RDDM callback path that checks and queues reset_work. This ensures that no new SSR recovery work can be queued once teardown has started, and that any in-flight recovery work is fully synchronized before device power-down, preventing MHI teardown and DMA resource freeing from running more than once. Note: This issue only affects PCI/MHI-based devices. AHB-based ath11k devices do not queue reset_work in normal SSR flows. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04866.5-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Gravité et risque d'exploitation

CVE-2026-74407 obtient un score CVSS de 8.8/10, soit une gravité élevée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.38 %, ce qui la place devant 30.0 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions <6dd3701facc0cee62d6682e49eed64499f9d0e43, 7.1.5, <=*, <53dd29e8aeb2a1b5f079178551836b85fc6b53df, <=6.18.*, <=7.1.*, 6.18.53, 13da397f884d9c9a3fb6616206eeb6c6ab097287, 0, 7.2, <5.19, 5.19, <8c79aac429b583301f387374ff37c59be671df87) est présent sur votre parc.
  • Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
  • À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
  • Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.

Références