CVE-2025-40329

Vulnérabilité non évaluée dans Linux (Linux)

CVSS 0.0 · Non évaluée
EPSS 0.2%
Linux•Linux•Versions : <487df8b698345dd5a91346335f05170ed5f29d4e, <=*, <=6.12.*, 2fdb8a8f07c2f1353770a324fd19b8114e4329ac, <3e8ada4fd838e3fd2cca94000dac054f3a347c01, <=6.17.*, 6.17.8, <0d63031ee4a57be0252cb9a4e09ae921c75cece9, 6.18, <6.2, 6.6.117, <70150b9443dddf02157d821c68abf438f55a2e8e, 0, <=6.6.*, 6.12.58, 6.2

Description

In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb The Mesa issue referenced below pointed out a possible deadlock: [ 1231.611031] Possible interrupt unsafe locking scenario: [ 1231.611033] CPU0 CPU1 [ 1231.611034] ---- ---- [ 1231.611035] lock(&xa->xa_lock#17); [ 1231.611038] local_irq_disable(); [ 1231.611039] lock(&fence->lock); [ 1231.611041] lock(&xa->xa_lock#17); [ 1231.611044] <Interrupt> [ 1231.611045] lock(&fence->lock); [ 1231.611047] *** DEADLOCK *** In this example, CPU0 would be any function accessing job->dependencies through the xa_* functions that don't disable interrupts (eg: drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()). CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling callback so in an interrupt context. It will deadlock when trying to grab the xa_lock which is already held by CPU0. Replacing all xa_* usage by their xa_*_irq counterparts would fix this issue, but Christian pointed out another issue: dma_fence_signal takes fence.lock and so does dma_fence_add_callback. dma_fence_signal() // locks f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // locks f2.lock This will deadlock if f1 and f2 share the same spinlock. To fix both issues, the code iterating on dependencies and re-arming them is moved out to drm_sched_entity_kill_jobs_work(). [phasta: commit message nits]

Gravité et risque d'exploitation

CVE-2025-40329 obtient un score CVSS de 0.0/10, soit une gravité non évaluée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.22 %, ce qui la place devant 12.0 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions <487df8b698345dd5a91346335f05170ed5f29d4e, <=*, <=6.12.*, 2fdb8a8f07c2f1353770a324fd19b8114e4329ac, <3e8ada4fd838e3fd2cca94000dac054f3a347c01, <=6.17.*, 6.17.8, <0d63031ee4a57be0252cb9a4e09ae921c75cece9, 6.18, <6.2, 6.6.117, <70150b9443dddf02157d821c68abf438f55a2e8e, 0, <=6.6.*, 6.12.58, 6.2) 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