CVE-2022-48721 in Linux
Summary
by MITRE • 06/20/2024
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Forward wakeup to smc socket waitqueue after fallback
When we replace TCP with SMC and a fallback occurs, there may be some socket waitqueue entries remaining in smc socket->wq, such as eppoll_entries inserted by userspace applications.
After the fallback, data flows over TCP/IP and only clcsocket->wq will be woken up. Applications can't be notified by the entries which were inserted in smc socket->wq before fallback. So we need a mechanism to wake up smc socket->wq at the same time if some entries remaining in it.
The current workaround is to transfer the entries from smc socket->wq to clcsock->wq during the fallback. But this may cause a crash like this:
general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI
CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E 5.16.0+ #107 RIP: 0010:__wake_up_common+0x65/0x170 Call Trace: __wake_up_common_lock+0x7a/0xc0 sock_def_readable+0x3c/0x70 tcp_data_queue+0x4a7/0xc40 tcp_rcv_established+0x32f/0x660 ? sk_filter_trim_cap+0xcb/0x2e0 tcp_v4_do_rcv+0x10b/0x260 tcp_v4_rcv+0xd2a/0xde0 ip_protocol_deliver_rcu+0x3b/0x1d0 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0x6a/0x110 ? tcp_v4_early_demux+0xa2/0x140 ? tcp_v4_early_demux+0x10d/0x140 ip_sublist_rcv_finish+0x49/0x60 ip_sublist_rcv+0x19d/0x230 ip_list_rcv+0x13e/0x170 __netif_receive_skb_list_core+0x1c2/0x240 netif_receive_skb_list_internal+0x1e6/0x320 napi_complete_done+0x11d/0x190 mlx5e_napi_poll+0x163/0x6b0 [mlx5_core]
__napi_poll+0x3c/0x1b0 net_rx_action+0x27c/0x300 __do_softirq+0x114/0x2d2 irq_exit_rcu+0xb4/0xe0 common_interrupt+0xba/0xe0
The crash is caused by privately transferring waitqueue entries from smc socket->wq to clcsock->wq. The owners of these entries, such as epoll, have no idea that the entries have been transferred to a different socket wait queue and still use original waitqueue spinlock (smc socket->wq.wait.lock) to make the entries operation exclusive, but it doesn't work. The operations to the entries, such as removing from the waitqueue (now is clcsock->wq after fallback), may cause a crash when clcsock waitqueue is being iterated over at the moment.
This patch tries to fix this by no longer transferring wait queue entries privately, but introducing own implementations of clcsock's callback functions in fallback situation. The callback functions will forward the wakeup to smc socket->wq if clcsock->wq is actually woken up and smc socket->wq has remaining entries.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/01/2025
The vulnerability CVE-2022-48721 affects the Linux kernel's SMC (Scalable Memory Communication) implementation and represents a critical issue in socket waitqueue management during fallback scenarios. This flaw occurs when TCP is replaced with SMC and a fallback to TCP/IP occurs, creating a race condition and potential system crash due to improper handling of waitqueue entries. The vulnerability stems from the kernel's inability to properly notify applications when socket waitqueue entries remain in the SMC socket's waitqueue after a fallback event, leading to incomplete notification mechanisms and potential system instability.
The technical flaw manifests when applications use epoll or similar mechanisms to monitor socket events through waitqueue entries that are inserted into the SMC socket's waitqueue before fallback occurs. During the fallback process from SMC to TCP/IP, data flows over the TCP stack while only the clcsocket's waitqueue gets woken up, leaving the original SMC socket waitqueue entries unattended. This creates a scenario where applications fail to receive proper notifications about socket events, as the waitqueue entries that were meant to trigger notifications remain dormant in the SMC socket's waitqueue structure. The initial workaround of transferring waitqueue entries from smc socket->wq to clcsock->wq proved problematic and caused general protection faults, indicating a fundamental design flaw in the approach.
The operational impact of this vulnerability is severe as it can lead to complete system crashes through general protection faults when the kernel attempts to process waitqueue entries that have been moved between different socket structures. The crash occurs during the wake-up process when the original waitqueue spinlock (smc socket->wq.wait.lock) is used to operate on entries that have been moved to a different waitqueue structure (clcsock->wq), causing memory access violations and system instability. This vulnerability affects systems using SMC with fallback mechanisms and can be exploited to cause denial of service conditions or system crashes, particularly in high-performance networking environments where SMC is utilized for low-latency communication.
The patch addresses this issue by implementing a more robust approach that avoids the problematic private transfer of waitqueue entries. Instead of moving entries between waitqueues, the solution introduces custom callback function implementations during fallback scenarios that properly forward wake-up signals to the SMC socket's waitqueue when entries remain there and the TCP socket's waitqueue has been woken up. This approach eliminates the risk of accessing invalid memory locations and prevents the spinlock conflicts that caused the original crashes. The solution aligns with best practices for kernel memory management and follows the principles of proper resource handling in concurrent systems, as outlined in CWE-119 (Memory Access Violation) and CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization). The fix also addresses potential issues related to ATT&CK technique T1499.004 (Endpoint Detection and Response) by ensuring proper socket notification mechanisms that maintain system stability and prevent unexpected service interruptions.