CVE-2025-38461

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

vsock: Fix transport_* TOCTOU

Transport assignment may race with module unload. Protect new_transport from becoming a stale pointer.

This also takes care of an insecure call in vsock_use_local_transport(); add a lockdep assert.

BUG: unable to handle page fault for address: fffffbfff8056000 Oops: Oops: 0000 [#1] SMP KASAN RIP: 0010:vsock_assign_transport+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

This patch addresses a race condition in the vsock core that could lead to a use-after-free or NULL pointer dereference when assigning transports during socket initialization. The vulnerability stems from a lack of synchronization between transport selection and potential module unloading, leading to stale pointers being dereferenced. A mutex now protects access to the transport selection logic, and reference counting ensures the module is retained during use. The issue has low impact on confidentiality, but may cause a system crash, resulting in high availability impact. Since the problem is reachable by unprivileged users via socket operations, Privileges Required = Low (for the CVSS). While the issue is most clearly triggered during manual module unload, similar conditions can also arise from automatic module unloading, hotplug scripts, or asynchronous transport (de)registration in multi-threaded environments.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

To mitigate this issue, prevent module vsock from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.