HIGH
rxrpc RecvMsg Queue UAF
CVE-2026-23066
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI7.8HIGH
01Description
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recvmsg() unconditional requeue If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at the front of the recvmsg queue already has its mutex locked, it requeues the call - whether or not the call is already queued. The call may be on the queue because MSG_PEEK was also passed and so the call was not dequeued or because the I/O thread requeued it. The unconditional requeue may then corrupt the recvmsg queue, leading to things like UAFs or refcount underruns. Fix this by only requeuing the call if it isn't already on the queue - and moving it to the front if it is already queued. If we don't queue it, we have to put the ref we obtained by dequeuing it. Also, MSG_PEEK doesn't dequeue the call so shouldn't call rxrpc_notify_socket() for the call if we didn't use up all the data on the queue, so fix that also.
02KernelScan AI Analysis
Risk summary
A local attacker with the ability to create rxrpc sockets can trigger use-after-free conditions by calling recvmsg() with specific flag combinations. This can lead to memory corruption, potential privilege escalation, or system crashes. The vulnerability affects the rxrpc protocol implementation used for network communication in distributed file systems like AFS.
Vulnerability analysis
Root Cause: The rxrpc_recvmsg() function unconditionally requeues calls when MSG_DONTWAIT is specified and the call mutex is locked, without checking if the call is already on the queue. This can happen when MSG_PEEK was used (call not dequeued) or when the I/O thread requeued it. The unconditional requeue corrupts the recvmsg queue structure, leading to use-after-free conditions and reference count underruns.
Attack Surface: Local attack surface requiring the ability to make rxrpc system calls with specific flag combinations (MSG_DONTWAIT and MSG_PEEK). The vulnerability is triggered through the recvmsg() system call on rxrpc sockets, which requires local access and the ability to create and manipulate rxrpc connections.
Fix Mechanism: The patch adds proper queue state checking before requeuing. It only requeues the call if it's not already on the queue, moves it to the front if already queued, and properly manages reference counts by putting the reference obtained during dequeue when not requeuing. Additionally, it fixes MSG_PEEK to not call rxrpc_notify_socket() when data remains on the queue.
03Fix Versions
| Branch | Fixed in | Patch commit |
|---|---|---|
| 5.10 | 5.10.258 | 8fd3b5e29785 |
| 5.15 | 5.15.209 | c198628f3fca |
| 6.1 | 6.1.175 | c6cebcb4e0b3 |
| 6.12 | 6.12.78 | cf969bddd6e6 |
| 6.18 | 6.18.8 | 930114425065 |
| 6.6 | 6.6.130 | 0464bf75590d |
| mainline | 6.19 | 2c28769a51de |