CVE-2022-49998 in Linux
Summary
by MITRE • 06/18/2025
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix locking in rxrpc's sendmsg
Fix three bugs in the rxrpc's sendmsg implementation:
(1) rxrpc_new_client_call() should release the socket lock when returning an error from rxrpc_get_call_slot().
(2) rxrpc_wait_for_tx_window_intr() will return without the call mutex held in the event that we're interrupted by a signal whilst waiting for tx space on the socket or relocking the call mutex afterwards.
Fix this by: (a) moving the unlock/lock of the call mutex up to rxrpc_send_data() such that the lock is not held around all of rxrpc_wait_for_tx_window*() and (b) indicating to higher callers whether we're return with the lock dropped. Note that this means recvmsg() will not block on this call whilst we're waiting.
(3) After dropping and regaining the call mutex, rxrpc_send_data() needs to go and recheck the state of the tx_pending buffer and the tx_total_len check in case we raced with another sendmsg() on the same call.
Thinking on this some more, it might make sense to have different locks for sendmsg() and recvmsg(). There's probably no need to make recvmsg() wait for sendmsg(). It does mean that recvmsg() can return MSG_EOR indicating that a call is dead before a sendmsg() to that call returns - but that can currently happen anyway.
Without fix (2), something like the following can be induced:
WARNING: bad unlock balance detected! 5.16.0-rc6-syzkaller #0 Not tainted ------------------------------------- syz-executor011/3597 is trying to release lock (&call->user_mutex) at: [<ffffffff885163a3>] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748
but there are no more locks to release!
other info that might help us debug this: no locks held by syz-executor011/3597. ... Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline]
__lock_release kernel/locking/lockdep.c:5306 [inline]
lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657 __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561 sock_sendmsg_nosec net/socket.c:704 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae
[Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/30/2025
The vulnerability CVE-2022-49998 resides within the Linux kernel's rxrpc networking subsystem, specifically addressing critical locking issues in the sendmsg implementation. This vulnerability manifests as improper lock management during asynchronous remote execution protocol operations, creating potential for kernel lockdep warnings and system instability. The rxrpc protocol implements a remote procedure call mechanism that enables communication between kernel space and user space applications, making this issue particularly significant for networked kernel operations.
The technical flaw stems from three distinct but interrelated bugs in the rxrpc sendmsg function's locking mechanism. First, the rxrpc_new_client_call() function fails to release the socket lock when returning an error from rxrpc_get_call_slot(), violating fundamental lock acquisition and release principles. Second, rxrpc_wait_for_tx_window_intr() function exhibits improper mutex handling by returning without maintaining the call mutex lock when interrupted by signals, creating a scenario where the lock state becomes inconsistent. Third, the rxrpc_send_data() function lacks proper state revalidation after dropping and regaining the call mutex, potentially causing race conditions where the tx_pending buffer state and tx_total_len checks become invalid due to concurrent sendmsg() operations.
The operational impact of this vulnerability extends beyond simple kernel lock warnings to potentially destabilize system operations and create denial-of-service conditions. When the kernel's lockdep subsystem detects the improper unlock balance, it generates warnings indicating that locks are being released without corresponding acquisitions, which can lead to undefined behavior and system crashes. The race condition described in the third bug can cause data corruption or inconsistent state management within the rxrpc call structure, particularly affecting concurrent send operations on the same call. This vulnerability is particularly dangerous in multi-threaded environments where multiple processes attempt to send data simultaneously through the same rxrpc socket, as the improper lock management can cascade into broader system instability.
The fix addresses these issues through careful reorganization of lock management within the sendmsg path. The solution involves moving the unlock/lock operations for the call mutex earlier in the rxrpc_send_data() function to ensure the lock is not held during the potentially long-running rxrpc_wait_for_tx_window*() operations. Additionally, the fix implements signaling mechanisms to indicate to higher-level callers when the lock has been dropped, preventing recvmsg() operations from blocking indefinitely during tx window waits. This approach aligns with the principle of minimizing lock hold times and reducing contention in concurrent systems, a pattern that follows established best practices in kernel development and concurrent programming. The suggested approach of potentially implementing separate locks for sendmsg() and recvmsg() operations represents a more fundamental architectural improvement that could prevent similar issues in the future.
This vulnerability maps directly to CWE-367, which describes Time-of-Check to Time-of-Use (TOCTOU) race conditions, and CWE-116, which covers improper handling of locking mechanisms. From an ATT&CK perspective, this vulnerability could be leveraged in privilege escalation scenarios or for creating persistent denial-of-service conditions, potentially allowing adversaries to disrupt network services or compromise system stability. The vulnerability demonstrates the critical importance of proper lock management in kernel space, where improper synchronization can lead to system crashes, data corruption, and potential security implications. The fix represents a defensive programming approach that addresses the root cause of the lock imbalance while maintaining the functional integrity of the rxrpc protocol implementation.