CVE-2026-23066: RxRPC recvmsg Locking Bug and Kernel Patch

A subtle locking bug in the kernel's RxRPC recvpath can corrupt internal socket queues and lead to use-after-free and refcount underruns — a flaw tracked as CVE-2026-23066 that was introduced by incorrect requeue logic in rxrpc_recvmsg() and fixed upstream by a targeted patch in early 2026. (ubuntu.com)

Background​

RxRPC (AF_RXRPC) is the kernel's transport implementation for the RxRPC protocol, historically used by the Andrew File System (AFS) and a small set of other in-kernel and userspace consumers. It provides a reliable RPC-like session layer on top of UDP and exposes a socket API (sendmsg/recvmsg) to callers. Because RxRPC lives inside the kernel networking stack and interacts with per-call and per-socket locking, subtle races or queue-corruption bugs can lead to memory safety issues at kernel privilege level.
In February 2026 the Linux CNA published CVE-2026-23066 describing a defect in rxrpc_recvmsg(): when recvmsg() fails while MSG_DONTWAIT is specified and the call at the front of the recvmsg queue already has its mutex locked, the code would unconditionally requeue the call. That requeue happens regardless of whether the call was already present on the queue (for example because MSG_PEEK had been used or an I/O thread requeued it). The unconditional requeue can corrupt the recvmsg queue, producing outcomes like use-after-free (UAF) or refcount underruns. The upstream fix changes the logic to only requeue if the call is not already queued, and to move it to the front if it is. It also tightens handling of MSG_PEEK so the socket is not notified when the call remains on the queue. (ubuntu.com)

---

What exactly went wrong: a technical walkthrough​

Where in the stack​

• The bug is in net/rxrpc/recvmsg.c inside the kernel's RxRPC implementation.
• It arises during recvmsg() processing: the kernel inspects the call at the head of the socket's recvmsg queue, grabs a reference to it, and attempts to handle the request; if it cannot proceed due to the call's per-call mutex being held and the caller specified MSG_DONTWAIT, the code must decide how to place the call back (or not) on the socket queue.

The incorrect requeue​

• The problematic behavior is simple but dangerous: when the code decides it needs to requeue the call, it does so without checking whether that same call is already present on the socket queue.
• If the call was already queued (for example, because the thread used MSG_PEEK and therefore deliberately left it queued), re-inserting it produces duplicate/list corruption conditions on a circular or linked queue structure.
• Queue corruption at kernel level frequently manifests as out-of-bounds pointer walks, double-free, or refcount underflow — each of which can be escalated into memory corruption and arbitrary kernel memory access/deallocation patterns. (ubuntu.com)

Why MSG_PEEK made things worse​

• MSG_PEEK is intended to let a reader inspect data without removing it from the queue. The old code logic could pop a call reference for inspection and — if it didn't consume all data — erroneously notify the socket (rxrpc_notify_socket()) under the assumption the call had been dequeued.
• The fix avoids notifying the socket when MSG_PEEK was used and the call remained queued, preventing spurious wakeups and avoiding additional queue manipulations that could compound the corruption. (ubuntu.com)

The safe fix​

• The upstream patch makes three practical changes:
• Only requeue if the call is not already queued.
• If the call is already on the queue, move it to the front instead of re-inserting it a second time.
• Ensure any reference-count adjustments (put/put_ref) are balanced when dequeuing but not re-queued.
• This repair eliminates the duplicate-insertion path and reduces the attack surface for queue-corruption exploitation.

---

Affected systems and urgency​

What kernels are impacted​

• The vulnerability was assigned and published in early February 2026. The Linux CNA and major tracking systems list the issue and point to upstream commits that close it in recent stable series. Multiple stable trees had the patch backported or proposed for backporting (6.6.y, 6.12.y, 6.18, etc.), with some stable trees accepting it and others showing failed cherry-picks where the patch needed adjustments.

Distribution advisories and product status​

• Canonical's Ubuntu security advisory lists CVE-2026-23066 with a Medium priority and enumerates which Ubuntu kernel flavors and releases are vulnerable or patched; many mainstream Ubuntu kernel flavors were recorded as vulnerable until vendor updates were applied. (ubuntu.com)
• The National Vulnerability Database (NVD) has a published record describing the bug and its impact; third-party CVE aggregators mirror the description and link to the upstream commits. Some vendor pages (e.g., distribution security bulletins) also include it as part of their kernel hardening releases.

Who should care most​

• Systems running kernels built with RxRPC/AF_RXRPC enabled (either built-in or as a loadable module) and those using AFS or kernel-level RxRPC consumers are the primary risk group.
• Many commodity servers and desktops do not use AFS or AF_RXRPC. If your box does not have rxrpc loaded and you do not run AFS or related software, practical exposure is lower — but kernel vulnerabilities that cause UAFs are high-risk enough that vendors recommend applying security updates regardless.

---

Can this be exploited remotely?​

The underlying flaw is an internal queue-corruption and memory-safety issue triggered by local socket/recvmsg interactions. In theory, a remote attacker who can send crafted RxRPC packets to a listening RxRPC socket or induce specific recvmsg() behavior could attempt to trigger the faulty code paths. However, exploitation requires:

• The RxRPC service to be reachable (socket open and not firewalled),
• The attacker to craft traffic or orchestrate recvmsg timing such that MSG_DONTWAIT and the call mutex locking path occur as needed,
• And in many real-world setups, the RxRPC service is not exposed to the broader internet.

No widespread public exploit weaponization or worming campaigns were publicly reported at the time of the initial advisories; most vendors prioritized backporting the safe fix into their stable kernels. That said, absence of public exploit reports is not proof of non-exploitability: memory-safety kernel bugs are routinely targeted by researchers and attackers, so treating the defect as high-risk by patching promptly is the prudent course. (ubuntu.com)

---

Detection and triage — how to check your systems​

Perform these checks on each Linux host to determine exposure and triage risk.

• Check whether the rxrpc module is loaded:
• lsmod | grep rxrpc
• If no output appears, rxrpc is not currently loaded as a module; it may still be compiled into the running kernel.
• See if the kernel was built with AF_RXRPC:
• grep -i af_rxrpc /boot/config-$(uname -r) || zgrep -i af_rxrpc /proc/config.gz
• Look for CONFIG_AF_RXRPC and related options (e.g., CONFIG_AF_RXRPC=y or =m). If set to 'm' the feature is a loadable module; if 'y' it is built-in and cannot be unloaded without rebooting into a patched kernel.
• Search for active RxRPC sockets and AFS usage:
• ss -a | grep rxrpc
• ps aux | grep -i afs
• Check for in-kernel AFS clients (kAFS) or userspace clients dependent on AF_RXRPC.
• Review kernel version and vendor patch status:
• uname -r
• Compare your kernel release with your vendor's security advisory for CVE-2026-23066 (Ubuntu, RHEL, SUSE, Debian, etc.). Vendors will typically supply kernel packages that incorporate the upstream fix; the presence of the fix can also be verified by checking stable changelogs or the applied upstream commit IDs in the vendor package changelog. (ubuntu.com)

---

Immediate mitigations and recommended remediation​

The only complete remediation is to install a kernel that contains the upstream fix or a vendor backport. Prioritize updates on machines that:

• Run AFS or any software that relies on AF_RXRPC.
• Expose RxRPC services to untrusted networks.
• Perform multi-tenant workloads or run code from untrusted sources (cloud VMs, container hosts where shared kernel vulnerabilities are of special concern).

Practical steps:

• Patch promptly
• For Debian/Ubuntu: update the kernel packages and reboot at earliest maintenance window (apt update && apt upgrade linux-image-$(uname -r) or install the specific security package the vendor releases). Verify vendor advisory for the exact package name. (ubuntu.com)
• For RHEL/CentOS/Alma/Rocky: apply kernel updates from your vendor (yum/dnf update kernel) after confirming the advisory. OpenCVE and vendor databases indicate RHEL 9/10 lines were marked affected in some inventories, so pay attention to vendor-provided errata.
• For other distros: follow the distro/security vendor's kernel update instructions and use their kernels rather than attempting manual cherry-picks unless you maintain custom kernel trees.
• If RxRPC is a module and you do not need it: consider unloading it as a short-term mitigation
• rmmod rxrpc
• modprobe -r rxrpc
• Note: unloading may not be possible if services are using it or if the module is built into the kernel. Unloading is only a stopgap and must be followed by patching.
• Firewall or block RxRPC traffic
• If plausible in your environment, block RxRPC-related ports or protocols at the network boundary and host-based firewall rules for untrusted networks. This reduces remote attack surface while you patch. Keep in mind that RxRPC runs over UDP and uses AF_RXRPC sockets — use vendor guidance for exact port/protocol identification.
• Patch verification
• After updating, check kernel changelogs or vendor package metadata for the commit ID that references the rxrpc recvmsg fix.
• Optionally validate by checking that the specific upstream commit referenced in advisories (the stable commit IDs listed by upstream vendors) is present in your vendor's change log.

---

Exploitation scenarios and risk assessment​

• On systems that do not load AF_RXRPC and do not run AFS, exposure is low in practice; however, the kernel-level nature of the bug means a local exploit could still produce privilege escalation if an attacker can create or interact with RxRPC sockets via a local process or container.
• On systems that host RxRPC services and accept network traffic from untrusted sources, the risk is materially higher because remotely reachable code paths could be triggered by crafted packets.
• Multi-tenant and cloud environments deserve special attention: a tenant with limited privileges might be able to interact with RxRPC sockets if those are exposed by other tenants or by misconfiguration, creating a path to kernel-level compromise.
• CVSS and exploit scoring: some aggregators list CVSS vector elements that emphasize local or adjacent attack scenarios rather than unauthenticated remote wormable exploitation; nevertheless the root cause (queue corruption leading to UAF) is a class of bug frequently exploited by skilled attackers and researchers. Treat the defect with high operational priority for systems actually using RxRPC.

---

Why queue corruption matters more than you think​

Kernel queue structures for networking are often implemented as compact linked lists or ring buffers with tight coupling to reference counts and ordering invariants. Small deviations from those invariants can cascade:

• Duplicate entries can cause later code to follow freed pointers or decrement reference counts twice, leading to use-after-free or refcount underflow.
• Use-after-free in kernel context gives attackers the possibility to co-opt freed objects or overwrite kernel control structures, potentially yielding arbitrary kernel read/write primitives in skilled hands.
• Refcount underrun or double-free conditions are especially dangerous because they are a common technique to create overlapping allocations and memory reuse windows, which can be manipulated into code execution or privilege escalation pathways.

The RxRPC bug fits this dangerous pattern: incorrect requeue semantics broke queue invariants and created a plausible memory-safety vulnerability that warranted an upstream fix and distribution backports. (ubuntu.com)

---

How vendors and the kernel community handled the issue​

• The fix was posted upstream as a focused patch and then propagated into stable backports for several active kernel branches. The usual patch submission and backporting process produced a mix of clean cherry-picks and some failed attempts for older stable trees where the code drifted, which is typical for backporting kernel fixes across divergent branches. Systems running older long-term kernels may need vendor-specific patches rather than relying on upstream cherry-picks.
• Distribution vendors (Canonical, Red Hat, others) have recorded the CVE and either shipped updated kernels or included the fix in security advisories. Always prefer vendor-supplied patched kernels over attempting to compile and run a custom patched kernel unless your organization is equipped to maintain that branch. (ubuntu.com)

---

Practical checklist for administrators (prioritized)​

• Inventory
• Identify hosts with AF_RXRPC enabled and running AFS or other RxRPC-dependent services. Check kernel config and loaded modules.
• Patch schedule
• Plan immediate kernel updates for affected hosts; prioritize internet-facing, multi-tenant, and RxRPC-using systems. (ubuntu.com)
• Short-term mitigations
• Unload the rxrpc module where possible; block RxRPC traffic at network boundaries. These are temporary and do not replace patching.
• Post-patch validation
• Reboot into vendor-provided patched kernel, verify kernel package changelog includes the rxrpc recvmsg fix, and confirm the absence of previously observed errata.
• Monitoring
• Watch for unusual kernel oopses or log messages referencing net/rxrpc/recvmsg.c or similar traces; such symptoms may indicate attempted or successful triggering of the problematic path prior to patching.

---

Final analysis: strengths of the fix and remaining risks​

The upstream patch is narrow, well-scoped, and corrects the logical error (requeueing without guard checks) that produced queue corruption. It follows a conservative approach: avoid duplicate insertions, adjust ordering semantics when the call is already queued, and correct MSG_PEEK notification behavior. These are solid engineering choices that preserve RxRPC semantics while restoring queue invariants.
Remaining risks to watch:

• Older, heavily-customized, or long-term-stable kernels where the patch cannot be cleanly cherry-picked may remain unpatched for longer; organizations running such kernels should seek vendor backports or consider moving to a supported kernel line.
• Environments where RxRPC is compiled into the kernel (CONFIG_AF_RXRPC=y) require a full kernel update and reboot — operational impact can delay remediation and increase exposure window.
• Even after patching, the fact that queue corruption bugs existed historically in RxRPC should motivate maintainers to add targeted kernel fuzzing or regression tests around the recv-path and queuing logic. The class of bug (queue invariants vs locking states) benefits from automated testing that covers MSG_PEEK, MSG_DONTWAIT, concurrent recvmsg callers, and I/O thread requeues. (ubuntu.com)

---

Conclusion​

CVE-2026-23066 is a textbook example of how a compact logic bug at the interface between locking and queue management can evolve into a kernel memory safety vulnerability. The defect — unconditional requeueing in rxrpc_recvmsg() — risks queue corruption that can lead to UAFs or refcount underflows and was addressed upstream with a targeted, minimal patch that restores correct queue semantics and MSG_PEEK behavior. Administrators should inventory RxRPC use, prioritize vendor kernel updates for affected machines, and apply short-term mitigations where appropriate (module removal, firewalling) while treating kernel-level UAFs as high-priority patching items even on systems where RxRPC is not obviously used. Vigilance, timely patching, and validation are the practical defenses that will close this window of risk. (ubuntu.com)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center