CVE-2022-49998
published 2025-06-18CVE-2022-49998: 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…
PriorityP418medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.16%
5.8th percentile
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:
[] 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:
__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.
Affected
15 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.0.2-1 (bookworm) | linux 6.0.2-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= bc5e3a546d553e5223851fc199e69040eb70f68b < 79e2ca7aa96e80961828ab6312264633b66183cc | 79e2ca7aa96e80961828ab6312264633b66183cc |
| linux | linux | >= bc5e3a546d553e5223851fc199e69040eb70f68b < 2bc769b8edb158be7379d15f36e23d66cf850053 | 2bc769b8edb158be7379d15f36e23d66cf850053 |
| linux | linux | >= bc5e3a546d553e5223851fc199e69040eb70f68b < 091dc91e119fdd61432347231724f4e861c6b465 | 091dc91e119fdd61432347231724f4e861c6b465 |
| linux | linux | >= bc5e3a546d553e5223851fc199e69040eb70f68b < b0f571ecd7943423c25947439045f0d352ca3dbf | b0f571ecd7943423c25947439045f0d352ca3dbf |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.10.140-1 | 5.10.140-1 |
| linux | linux_kernel | >= 0 < 6.0.2-1 | 6.0.2-1 |
| linux | linux_kernel | >= 0 < 6.0.2-1 | 6.0.2-1 |
| linux | linux_kernel | >= 0 < 6.0.2-1 | 6.0.2-1 |
| linux | linux_kernel | >= 4.15 < 5.10.140 | 5.10.140 |
| linux | linux_kernel | >= 5.11 < 5.15.64 | 5.15.64 |
| linux | linux_kernel | >= 5.16 < 5.19.6 | 5.19.6 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-qc5g-94x3-gf9g: 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 impl
ghsa_unreviewed·2025-06-18
CVE-2022-49998 [MEDIUM] CWE-667 GHSA-qc5g-94x3-gf9g: 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 impl
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.
OSV
CVE-2022-49998: 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 implem
osv·2025-06-18·CVSS 5.5
CVE-2022-49998 [MEDIUM] CVE-2022-49998: 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 implem
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) Af
Red Hat
kernel: rxrpc: Fix locking in rxrpc's sendmsg
vendor_redhat·2025-06-18·CVSS 5.5
CVE-2022-49998 [MEDIUM] CWE-413 kernel: rxrpc: Fix locking in rxrpc's sendmsg
kernel: rxrpc: Fix locking in rxrpc's sendmsg
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
Debian
CVE-2022-49998: linux - In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix ...
vendor_debian·2022·CVSS 5.5
CVE-2022-49998 [MEDIUM] CVE-2022-49998: linux - In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix ...
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) Af
No detection rules found.
No public exploits indexed.
2025-06-18
Published