CVE-2026-23066 Overview
CVE-2026-23066 is a Use After Free vulnerability in the Linux kernel's rxrpc subsystem. The vulnerability exists in the rxrpc_recvmsg() function, which handles message reception for the AF_RXRPC socket family used primarily by the AFS (Andrew File System) distributed file system.
The flaw occurs when rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at the front of the recvmsg queue already has its mutex locked. In this scenario, the function unconditionally requeues the call regardless of whether the call is already present in the queue. This can happen when MSG_PEEK was also passed (preventing dequeue) or when the I/O thread has already requeued the call.
Critical Impact
The unconditional requeue operation can corrupt the recvmsg queue, leading to Use After Free conditions or reference count underruns, potentially allowing local attackers to cause system instability or gain elevated privileges.
Affected Products
- Linux kernel (rxrpc subsystem)
- Systems using AF_RXRPC sockets
- AFS (Andrew File System) implementations
Discovery Timeline
- 2026-02-04 - CVE CVE-2026-23066 published to NVD
- 2026-02-05 - Last updated in NVD database
Technical Details for CVE-2026-23066
Vulnerability Analysis
The rxrpc protocol implementation in the Linux kernel provides a reliable datagram protocol used primarily by the AFS distributed file system. The vulnerability resides in the message reception handling path within rxrpc_recvmsg().
When a user-space application calls recvmsg() on an AF_RXRPC socket with the MSG_DONTWAIT flag, the kernel attempts to receive data without blocking. If the call at the front of the queue has its mutex already locked (by another operation), the function fails and attempts to requeue the call. The critical flaw is that this requeue operation occurs unconditionally, without checking whether the call is already present in the queue.
This creates two problematic scenarios: First, when MSG_PEEK is used in combination with MSG_DONTWAIT, the call is never dequeued but may still be requeued, creating a duplicate entry. Second, if the I/O thread has already requeued the call, a second requeue corrupts the queue structure.
The queue corruption can manifest as Use After Free vulnerabilities when freed memory is still referenced through the corrupted queue, or as reference count underruns when dequeue operations decrement counters for entries that were never properly queued.
Root Cause
The root cause is improper state checking in the rxrpc_recvmsg() error handling path. The function fails to verify queue membership before performing a requeue operation. Additionally, when MSG_PEEK is used and not all data is consumed, the function incorrectly calls rxrpc_notify_socket() even though the call was never dequeued, further contributing to the state corruption.
Attack Vector
A local attacker with the ability to create and manipulate AF_RXRPC sockets could exploit this vulnerability by crafting specific recvmsg() calls with MSG_DONTWAIT and MSG_PEEK flags while racing with other socket operations. By carefully timing these operations to trigger the mutex contention scenario, an attacker could corrupt the queue structure and potentially achieve privilege escalation or cause a denial of service.
The exploitation requires local access and the ability to interact with AF_RXRPC sockets, which limits the attack surface to multi-user systems or scenarios where untrusted code can execute.
Detection Methods for CVE-2026-23066
Indicators of Compromise
- Kernel log messages indicating rxrpc queue corruption or reference count errors
- Unexpected kernel crashes or panics in the rxrpc subsystem
- KASAN (Kernel Address Sanitizer) reports showing use-after-free in rxrpc functions
- Unusual AFS client behavior or connectivity issues
Detection Strategies
- Monitor kernel logs for rxrpc-related warnings, errors, or KASAN reports
- Deploy kernel live patching solutions to detect vulnerable code paths
- Use system call auditing to monitor recvmsg() operations on AF_RXRPC sockets
- Implement endpoint detection rules for unusual AF_RXRPC socket activity patterns
Monitoring Recommendations
- Enable KASAN in development and staging environments to detect memory safety violations
- Configure kernel auditing to log AF_RXRPC socket operations in sensitive environments
- Monitor for repeated rxrpc-related kernel warnings that may indicate exploitation attempts
- Track system stability metrics for AFS-dependent services
How to Mitigate CVE-2026-23066
Immediate Actions Required
- Update to a patched Linux kernel version containing the fix commits
- If kernel updates are not immediately possible, consider disabling the rxrpc module if not required
- Restrict access to AF_RXRPC socket creation using LSM (Linux Security Modules) policies
- Monitor systems for signs of exploitation while patches are being deployed
Patch Information
The vulnerability has been fixed in the upstream Linux kernel. The fix ensures that calls are only requeued if they are not already on the queue, moving them to the front if already queued. Additionally, the fix properly handles reference counting when a call is not queued and corrects the MSG_PEEK behavior to avoid unnecessary rxrpc_notify_socket() calls.
Patches are available through the following kernel commits:
Workarounds
- Unload the rxrpc kernel module if AFS functionality is not required: modprobe -r rxrpc
- Use SELinux or AppArmor policies to restrict AF_RXRPC socket creation to trusted processes
- Implement network segmentation to limit exposure of AFS services
- Consider using container isolation to limit the impact of potential exploitation
# Disable rxrpc module loading (temporary workaround)
echo "install rxrpc /bin/false" >> /etc/modprobe.d/disable-rxrpc.conf
modprobe -r rxrpc
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
