CVE-2025-40329 in Linux
Résumé
par VulDB • 30/05/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
drm/sched : Correction d'un blocage dans drm_sched_entity_kill_jobs_cb
Le problème Mesa mentionné ci-dessous a mis en évidence un blocage potentiel :
[ 1231.611031] Scénario de verrouillage non sûr pour les interruptions possible :
[ 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]
*** BLOCAGE ***
Dans cet exemple, CPU0 correspondrait à n'importe quelle fonction accédant à job->dependencies via les fonctions xa_* qui ne désactivent pas les interruptions (par exemple : drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).
CPU1 exécute drm_sched_entity_kill_jobs_cb() en tant que rappel de signalisation de fence (fence signalling callback), donc dans un contexte d'interruption. Il se bloquera lors de la tentative d'acquisition de xa_lock, qui est déjà détenu par CPU0.
Le remplacement de toutes les utilisations de xa_* par leurs équivalents xa_*_irq corrigerait ce problème, mais Christian a signalé un autre problème : dma_fence_signal prend fence.lock, tout comme dma_fence_add_callback.
dma_fence_signal() // verrouille f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // verrouille f2.lock
Cela provoquera un blocage si f1 et f2 partagent le même spinlock.
Pour corriger les deux problèmes, le code itérant sur les dépendances et les réarmant est déplacé vers drm_sched_entity_kill_jobs_work().
[phasta : corrections mineures du message de commit]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.