CVE-2022-49998

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix locking in rxrpc&amp;#39;s sendmsg<br /> <br /> Fix three bugs in the rxrpc&amp;#39;s sendmsg implementation:<br /> <br /> (1) rxrpc_new_client_call() should release the socket lock when returning<br /> an error from rxrpc_get_call_slot().<br /> <br /> (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex<br /> held in the event that we&amp;#39;re interrupted by a signal whilst waiting<br /> for tx space on the socket or relocking the call mutex afterwards.<br /> <br /> Fix this by: (a) moving the unlock/lock of the call mutex up to<br /> rxrpc_send_data() such that the lock is not held around all of<br /> rxrpc_wait_for_tx_window*() and (b) indicating to higher callers<br /> whether we&amp;#39;re return with the lock dropped. Note that this means<br /> recvmsg() will not block on this call whilst we&amp;#39;re waiting.<br /> <br /> (3) After dropping and regaining the call mutex, rxrpc_send_data() needs<br /> to go and recheck the state of the tx_pending buffer and the<br /> tx_total_len check in case we raced with another sendmsg() on the same<br /> call.<br /> <br /> Thinking on this some more, it might make sense to have different locks for<br /> sendmsg() and recvmsg(). There&amp;#39;s probably no need to make recvmsg() wait<br /> for sendmsg(). It does mean that recvmsg() can return MSG_EOR indicating<br /> that a call is dead before a sendmsg() to that call returns - but that can<br /> currently happen anyway.<br /> <br /> Without fix (2), something like the following can be induced:<br /> <br /> WARNING: bad unlock balance detected!<br /> 5.16.0-rc6-syzkaller #0 Not tainted<br /> -------------------------------------<br /> syz-executor011/3597 is trying to release lock (&amp;call-&gt;user_mutex) at:<br /> [] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748<br /> but there are no more locks to release!<br /> <br /> other info that might help us debug this:<br /> no locks held by syz-executor011/3597.<br /> ...<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline]<br /> __lock_release kernel/locking/lockdep.c:5306 [inline]<br /> lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657<br /> __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900<br /> rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748<br /> rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561<br /> sock_sendmsg_nosec net/socket.c:704 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:724<br /> ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409<br /> ___sys_sendmsg+0xf3/0x170 net/socket.c:2463<br /> __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> [Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]