CVE-2025-40231 in Linuxinformation

Résumé

par VulDB • 13/08/2026

Dans le noyau Linux, la vulnérabilité suivante a été corrigée :

vsock : correction d'une inversion de verrou dans vsock_assign_transport()

Syzbot a signalé un potentiel blocage mortel (deadlock) dû à une inversion de verrous entre `vsock_register_mutex` et `sk_lock-AF_VSOCK` lorsque `vsock_linger()` est appelé.

Le problème a été introduit par le commit 687aa0c5581b (« vsock : Correction d'une condition de concurrence TOCTOU sur transport_* »), qui a ajouté un verrouillage de `vsock_register_mutex` dans `vsock_assign_transport()` autour de l'appel à `transport->release()`, lequel peut invoquer `vsock_linger()`. La fonction `vsock_assign_transport()` peut être appelée avec le verrou `sk_lock` déjà acquis. `vsock_linger()` appelle `sk_wait_event()`, qui libère temporairement puis réacquiert `sk_lock`. Pendant cette fenêtre, si un autre thread détient `vsock_register_mutex` tout en essayant d'acquérir `sk_lock`, une dépendance circulaire est créée.

Cette correction consiste à relâcher `vsock_register_mutex` avant d'appeler `transport->release()` et `vsock_deassign_transport()`. Cette approche est sûre car nous n'avons pas besoin de maintenir le verrou `vsock_register_mutex` lors de la libération de l'ancien transport, et nous garantissons que le nouveau transport ne disparaîtra pas en obtenant d'abord une référence au module via `try_module_get()`.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Responsable

Linux

Réserver

16/04/2025

Divulgation

04/12/2025

Modérer

accepté

Entrée

VDB-334288

CPE

prêt

EPSS

0.00207

KEV

non

Activités

très faible

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!