CVE-2025-40231
BaseFortify
Publication date: 2025-12-04
Last updated on: 2025-12-04
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a lock inversion deadlock issue in the Linux kernel's vsock subsystem. It occurs due to a circular dependency between two locks: vsock_register_mutex and sk_lock-AF_VSOCK. Specifically, when vsock_linger() is called during vsock_assign_transport(), the locking order can cause a deadlock because vsock_linger() temporarily releases and re-acquires sk_lock, and if another thread holds vsock_register_mutex while trying to acquire sk_lock, a circular wait happens. The fix involves releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(), preventing the deadlock.
How can this vulnerability impact me? :
This vulnerability can cause a deadlock in the Linux kernel's vsock subsystem, potentially leading to system hangs or degraded performance when the affected code paths are executed. This can impact system stability and availability, especially in environments relying on vsock communication.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, update the Linux kernel to a version that includes the fix for the lock inversion issue in vsock_assign_transport(). The fix involves releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(), preventing the deadlock. Until the update is applied, avoid workloads or configurations that heavily use vsock transports to reduce the risk of triggering the deadlock.