VYPR
Unrated severityNVD Advisory· Published Dec 4, 2025· Updated Apr 15, 2026

CVE-2025-40231

CVE-2025-40231

Description

In the Linux kernel, the following vulnerability has been resolved:

vsock: fix lock inversion in vsock_assign_transport()

Syzbot reported a potential lock inversion deadlock between vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.

The issue was introduced by commit 687aa0c5581b ("vsock: Fix transport_* TOCTOU") which added vsock_register_mutex locking in vsock_assign_transport() around the transport->release() call, that can call vsock_linger(). vsock_assign_transport() can be called with sk_lock held. vsock_linger() calls sk_wait_event() that temporarily releases and re-acquires sk_lock. During this window, if another thread hold vsock_register_mutex while trying to acquire sk_lock, a circular dependency is created.

Fix this by releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(). This is safe because we don't need to hold vsock_register_mutex while releasing the old transport, and we ensure the new transport won't disappear by obtaining a module reference first via try_module_get().

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

A lock inversion vulnerability in the Linux kernel's vsock subsystem could lead to a deadlock when vsock_assign_transport() and vsock_linger() are invoked concurrently.

Vulnerability

CVE-2025-40231 describes a lock inversion deadlock in the Linux kernel's AF_VSOCK socket implementation. The issue was introduced in commit 687aa0c5581b ("vsock: Fix transport_* TOCTOU"), which added vsock_register_mutex locking in vsock_assign_transport() around the transport->release() call [1]. This function can be called with sk_lock held, and transport->release() may call vsock_linger(), which invokes sk_wait_event() that temporarily releases and re-acquires sk_lock [2]. If another thread holds vsock_register_mutex while trying to acquire sk_lock, a circular dependency (lock inversion) occurs [3].

Exploitation

An attacker with local access could trigger the deadlock by opening two concurrent VSOCK connections: one causing vsock_assign_transport() with sk_lock held, and another holding vsock_register_mutex while acquiring sk_lock. No special privileges beyond the ability to create AF_VSOCK sockets are required [1]. The vulnerability affects systems where the vsock transport is used (e.g., virtual machine guest-host communication).

Impact

Successful exploitation results in a denial of service (system hang) due to a deadlock that prevents progress of both threads involved [2]. The deadlock could also affect other operations that require vsock_register_mutex, such as transport registration or shutdown. The issue is limited to local denial of service; no privilege escalation or remote code execution has been described.

Mitigation

The Linux kernel stable series have released patches that fix the lock inversion by releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(), while obtaining a module reference via try_module_get() to ensure the new transport remains valid [4]. All kernels including the vulnerable commit and not yet patched are affected. Users should apply the available updates from their distribution or the mainline kernel.

AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2

Patches

7

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

7

News mentions

0

No linked articles in our index yet.