CVE-2022-48786 in Linux
Summary
by MITRE • 07/16/2024
In the Linux kernel, the following vulnerability has been resolved:
vsock: remove vsock from connected table when connect is interrupted by a signal
vsock_connect() expects that the socket could already be in the TCP_ESTABLISHED state when the connecting task wakes up with a signal pending. If this happens the socket will be in the connected table, and it is not removed when the socket state is reset. In this situation it's common for the process to retry connect(), and if the connection is successful the socket will be added to the connected table a second time, corrupting the list.
Prevent this by calling vsock_remove_connected() if a signal is received while waiting for a connection. This is harmless if the socket is not in the connected table, and if it is in the table then removing it will prevent list corruption from a double add.
Note for backporting: this patch requires d5afa82c977e ("vsock: correct removal of socket from the list"), which is in all current stable trees except 4.9.y.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/03/2025
The vulnerability described in CVE-2022-48786 represents a critical race condition within the Linux kernel's virtual socket implementation that could lead to memory corruption and system instability. This issue affects the vsock subsystem which provides virtual socket communication between virtual machines and host systems, commonly used in containerized environments and virtualization platforms. The vulnerability manifests when a socket connection process is interrupted by a signal during the connection establishment phase, creating a scenario where the socket state becomes inconsistent and leads to data structure corruption.
The technical flaw occurs within the vsock_connect() function where the kernel fails to properly clean up socket state when a signal interrupts the connection process. Specifically, when a connecting task is woken up with a pending signal while in the TCP_ESTABLISHED state, the socket remains in the connected table even though its state has been reset. This creates a scenario where subsequent connection attempts can result in the same socket being added to the connected table twice, causing list corruption and potential memory corruption issues. The vulnerability is classified under CWE-362 as a race condition that can lead to improper handling of concurrent operations, and it aligns with ATT&CK technique T1059.003 for privilege escalation through kernel exploitation.
The operational impact of this vulnerability extends beyond simple memory corruption to potentially enable privilege escalation attacks and system instability. When the connected table becomes corrupted due to double addition of socket entries, it can cause the kernel to access invalid memory locations or maintain inconsistent internal state that may be exploited by malicious actors. This vulnerability is particularly concerning in virtualized environments where vsock is extensively used, as it could allow attackers to compromise the integrity of the host system or gain elevated privileges within virtual machine environments. The flaw affects all kernel versions that implement the vsock subsystem and requires careful consideration during system updates and patch management.
The mitigation strategy involves implementing a proper cleanup mechanism by calling vsock_remove_connected() when a signal is received while waiting for a connection. This solution is designed to be safe for all scenarios since it is harmless when the socket is not in the connected table, but essential when it is present to prevent the double-add corruption. The patch references a previous fix d5afa82c977e that corrected socket removal from lists, which is present in all current stable kernel trees except the older 4.9.y branch. System administrators should prioritize applying this patch across all affected systems, particularly in production environments where virtualization and containerization are prevalent, as the vulnerability could be exploited to compromise system integrity and enable unauthorized access to sensitive resources.