vulnerability
Amazon Linux 2023: CVE-2025-40231: Important priority package update for kernel
| Severity | CVSS | Published | Added | Modified |
|---|---|---|---|---|
| 5 | (AV:L/AC:L/Au:S/C:N/I:N/A:C) | Dec 4, 2025 | Jan 12, 2026 | Jan 12, 2026 |
Severity
5
CVSS
(AV:L/AC:L/Au:S/C:N/I:N/A:C)
Published
Dec 4, 2025
Added
Jan 12, 2026
Modified
Jan 12, 2026
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().
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().
Solutions
amazon-linux-2023-upgrade-bpftoolamazon-linux-2023-upgrade-bpftool-debuginfoamazon-linux-2023-upgrade-kernelamazon-linux-2023-upgrade-kernel-debuginfoamazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64amazon-linux-2023-upgrade-kernel-develamazon-linux-2023-upgrade-kernel-headersamazon-linux-2023-upgrade-kernel-libbpfamazon-linux-2023-upgrade-kernel-libbpf-debuginfoamazon-linux-2023-upgrade-kernel-libbpf-develamazon-linux-2023-upgrade-kernel-libbpf-staticamazon-linux-2023-upgrade-kernel-livepatch-6-1-158-178-288amazon-linux-2023-upgrade-kernel-modules-extraamazon-linux-2023-upgrade-kernel-modules-extra-commonamazon-linux-2023-upgrade-kernel-toolsamazon-linux-2023-upgrade-kernel-tools-debuginfoamazon-linux-2023-upgrade-kernel-tools-develamazon-linux-2023-upgrade-perfamazon-linux-2023-upgrade-perf-debuginfoamazon-linux-2023-upgrade-python3-perfamazon-linux-2023-upgrade-python3-perf-debuginfo
NEW
Explore Exposure Command
Confidently identify and prioritize exposures from endpoint to cloud with full attack surface visibility and threat-aware risk context.