ghsa-qc5g-94x3-gf9g
Vulnerability from github
Published
2025-06-18 12:30
Modified
2025-06-18 12:30
Details

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]

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2022-49998"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-18T11:15:27Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix locking in rxrpc\u0027s sendmsg\n\nFix three bugs in the rxrpc\u0027s sendmsg implementation:\n\n (1) rxrpc_new_client_call() should release the socket lock when returning\n     an error from rxrpc_get_call_slot().\n\n (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex\n     held in the event that we\u0027re interrupted by a signal whilst waiting\n     for tx space on the socket or relocking the call mutex afterwards.\n\n     Fix this by: (a) moving the unlock/lock of the call mutex up to\n     rxrpc_send_data() such that the lock is not held around all of\n     rxrpc_wait_for_tx_window*() and (b) indicating to higher callers\n     whether we\u0027re return with the lock dropped.  Note that this means\n     recvmsg() will not block on this call whilst we\u0027re waiting.\n\n (3) After dropping and regaining the call mutex, rxrpc_send_data() needs\n     to go and recheck the state of the tx_pending buffer and the\n     tx_total_len check in case we raced with another sendmsg() on the same\n     call.\n\nThinking on this some more, it might make sense to have different locks for\nsendmsg() and recvmsg().  There\u0027s probably no need to make recvmsg() wait\nfor sendmsg().  It does mean that recvmsg() can return MSG_EOR indicating\nthat a call is dead before a sendmsg() to that call returns - but that can\ncurrently happen anyway.\n\nWithout fix (2), something like the following can be induced:\n\n\tWARNING: bad unlock balance detected!\n\t5.16.0-rc6-syzkaller #0 Not tainted\n\t-------------------------------------\n\tsyz-executor011/3597 is trying to release lock (\u0026call-\u003euser_mutex) at:\n\t[\u003cffffffff885163a3\u003e] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748\n\tbut there are no more locks to release!\n\n\tother info that might help us debug this:\n\tno locks held by syz-executor011/3597.\n\t...\n\tCall Trace:\n\t \u003cTASK\u003e\n\t __dump_stack lib/dump_stack.c:88 [inline]\n\t dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n\t print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline]\n\t __lock_release kernel/locking/lockdep.c:5306 [inline]\n\t lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657\n\t __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900\n\t rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748\n\t rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561\n\t sock_sendmsg_nosec net/socket.c:704 [inline]\n\t sock_sendmsg+0xcf/0x120 net/socket.c:724\n\t ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409\n\t ___sys_sendmsg+0xf3/0x170 net/socket.c:2463\n\t __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492\n\t do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n\t do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n\t entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n[Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]",
  "id": "GHSA-qc5g-94x3-gf9g",
  "modified": "2025-06-18T12:30:40Z",
  "published": "2025-06-18T12:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49998"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/091dc91e119fdd61432347231724f4e861c6b465"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2bc769b8edb158be7379d15f36e23d66cf850053"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/79e2ca7aa96e80961828ab6312264633b66183cc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b0f571ecd7943423c25947439045f0d352ca3dbf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…