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().
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().
Advisories
| Source | ID | Title |
|---|---|---|
Debian DLA |
DLA-4404-1 | linux security update |
Ubuntu USN |
USN-8029-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8030-1 | Linux kernel (GCP) vulnerabilities |
Ubuntu USN |
USN-8033-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8033-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8033-3 | Linux kernel (FIPS) vulnerabilities |
Ubuntu USN |
USN-8034-1 | Linux kernel (NVIDIA Tegra) vulnerabilities |
Ubuntu USN |
USN-8033-4 | Linux kernel (AWS) vulnerabilities |
Ubuntu USN |
USN-8029-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8033-5 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8034-2 | Linux kernel (NVIDIA Tegra IGX) vulnerabilities |
Ubuntu USN |
USN-8048-1 | Linux kernel (OEM) vulnerabilities |
Ubuntu USN |
USN-8033-6 | Linux kernel (NVIDIA) vulnerabilities |
Ubuntu USN |
USN-8033-7 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8033-8 | Linux kernel (Intel IoTG) vulnerabilities |
Ubuntu USN |
USN-8029-3 | Linux kernel (Azure) vulnerabilities |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Sat, 06 Dec 2025 00:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Thu, 04 Dec 2025 15:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| 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(). | |
| Title | vsock: fix lock inversion in vsock_assign_transport() | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-12-04T15:31:22.199Z
Reserved: 2025-04-16T07:20:57.180Z
Link: CVE-2025-40231
No data.
Status : Awaiting Analysis
Published: 2025-12-04T16:16:15.870
Modified: 2025-12-04T17:15:08.283
Link: CVE-2025-40231
OpenCVE Enrichment
No data.
Weaknesses
No weakness.
Debian DLA
Ubuntu USN