CVE-2026-23066 in Linux
Summary
by MITRE • 02/04/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 06/02/2026
The vulnerability CVE-2026-23066 represents a critical race condition and queue management flaw within the Linux kernel's rxrpc subsystem, specifically affecting the recvmsg() function implementation. This issue resides in the remote execution rpc protocol handling mechanism that manages asynchronous network communication for distributed applications. The flaw manifests when processing receive operations with specific message flags, creating a scenario where the kernel's receive message queue becomes corrupted through improper requeueing operations. The vulnerability directly impacts the kernel's memory management and object lifecycle handling, potentially leading to severe security implications including use-after-free conditions and reference count manipulation errors.
The technical root cause stems from an unconditional requeue operation within the rxrpc_recvmsg() function that fails to properly check the current state of the receive message queue before attempting to requeue a call. When MSG_DONTWAIT is specified and the mutex lock is already acquired by another process, the system attempts to requeue the call regardless of whether it's already present in the queue. This behavior creates a fundamental race condition where the same call can be processed multiple times, leading to queue corruption. The issue is particularly dangerous because it involves the interaction between different message flags including MSG_PEEK, which does not dequeue calls from the queue but still affects the queue state management. The flaw violates proper queue management principles by not maintaining proper state tracking and conditional logic for queue operations.
The operational impact of this vulnerability extends beyond simple memory corruption to potentially enable privilege escalation and denial of service conditions within kernel space. When the recvmsg queue becomes corrupted through the unconditional requeue operation, it can lead to use-after-free vulnerabilities where freed memory objects are accessed after being reallocated, or reference count underruns that cause kernel objects to be freed prematurely. These conditions can be exploited by malicious actors to execute arbitrary code with kernel privileges, potentially compromising the entire system. The vulnerability affects systems utilizing the rxrpc protocol for remote procedure calls, which is commonly found in distributed computing environments, network file systems, and various enterprise networking applications that rely on kernel-level RPC mechanisms for inter-process communication.
The fix implemented addresses the core issue by introducing proper state checking before requeue operations, ensuring that calls are only requeued when necessary and that existing queue entries are properly managed. The solution implements conditional requeue logic that checks if a call is already present in the queue before performing requeue operations, and moves existing entries to the front of the queue when appropriate. Additionally, the fix corrects the handling of MSG_PEEK flag behavior by ensuring that rxrpc_notify_socket() is only called when appropriate data consumption has occurred, preventing improper notification signaling when calls remain in the queue. This remediation aligns with established security practices for kernel memory management and queue handling, addressing the underlying CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and CWE-415 (Double Free) vulnerabilities that this flaw could potentially enable. The fix also supports ATT&CK techniques related to privilege escalation and kernel exploitation by preventing the memory corruption patterns that could be leveraged for advanced persistent threats.