CVE-2024-41036

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

CVSS 7.5 · Élevée
EPSS 0.8%
Linux•Linux•Versions : <5.11, <=6.1.*, 5.15.146, 6.10, 7c25c5d7274631b655f0f9098a16241fcd5db57b, 6.6.9, 1092525155eaad5c69ca9f3b6f3e7895a9424d66, <0913ec336a6c0c4a2b296bd9f74f8e41c4c83c8c, 0, <a0c69c492f4a8fad52f0a97565241c926160c9a4, 6.1.70, <10fec0cd0e8f56ff06c46bb24254c7d8f8f2bbf0, <6.6.41, <=6.6.*, <=6.9.*, 6.6.41, 6.9.10, 3dc5d44545453de1de9c53cc529cc960a85933da, <5.16, <80ece00137300d74642f2038c8fe5440deaf9f05, <6.1.100, <6.7, 786788bb1396ed5ea27e39c4933f59f4e52004e4, <=*, 5.10.206, 6.1.100, 6.7, 30302b41ffdcd194bef27fb3b1a9f2ca53dedb27

Description

In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Fix deadlock with the SPI chip variant When SMP is enabled and spinlocks are actually functional then there is a deadlock with the 'statelock' spinlock between ks8851_start_xmit_spi and ks8851_irq: watchdog: BUG: soft lockup - CPU#0 stuck for 27s! call trace: queued_spin_lock_slowpath+0x100/0x284 do_raw_spin_lock+0x34/0x44 ks8851_start_xmit_spi+0x30/0xb8 ks8851_start_xmit+0x14/0x20 netdev_start_xmit+0x40/0x6c dev_hard_start_xmit+0x6c/0xbc sch_direct_xmit+0xa4/0x22c __qdisc_run+0x138/0x3fc qdisc_run+0x24/0x3c net_tx_action+0xf8/0x130 handle_softirqs+0x1ac/0x1f0 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x3c/0x58 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x54/0x9c irq_exit_rcu+0x10/0x1c el1_interrupt+0x38/0x50 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 __netif_schedule+0x6c/0x80 netif_tx_wake_queue+0x38/0x48 ks8851_irq+0xb8/0x2c8 irq_thread_fn+0x2c/0x74 irq_thread+0x10c/0x1b0 kthread+0xc8/0xd8 ret_from_fork+0x10/0x20 This issue has not been identified earlier because tests were done on a device with SMP disabled and so spinlocks were actually NOPs. Now use spin_(un)lock_bh for TX queue related locking to avoid execution of softirq work synchronously that would lead to a deadlock.

Gravité et risque d'exploitation

CVE-2024-41036 obtient un score CVSS de 7.5/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.75 %, ce qui la place devant 54.2 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions <5.11, <=6.1.*, 5.15.146, 6.10, 7c25c5d7274631b655f0f9098a16241fcd5db57b, 6.6.9, 1092525155eaad5c69ca9f3b6f3e7895a9424d66, <0913ec336a6c0c4a2b296bd9f74f8e41c4c83c8c, 0, <a0c69c492f4a8fad52f0a97565241c926160c9a4, 6.1.70, <10fec0cd0e8f56ff06c46bb24254c7d8f8f2bbf0, <6.6.41, <=6.6.*, <=6.9.*, 6.6.41, 6.9.10, 3dc5d44545453de1de9c53cc529cc960a85933da, <5.16, <80ece00137300d74642f2038c8fe5440deaf9f05, <6.1.100, <6.7, 786788bb1396ed5ea27e39c4933f59f4e52004e4, <=*, 5.10.206, 6.1.100, 6.7, 30302b41ffdcd194bef27fb3b1a9f2ca53dedb27) 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