CVE-2026-23118: RxRPC Kernel Data-Race Fix and Affected Receive Path

In February 2026, the Linux kernel’s RxRPC subsystem received a small-looking but technically important correction: a data-race warning was eliminated, and a possible load/store tearing problem on 32-bit systems was removed at the same time. The issue landed as CVE-2026-23118, and while it is not the sort of kernel flaw that screams “instant compromise,” it sits in a path that matters: the receive-and-keepalive logic that helps RxRPC decide whether a peer still needs a periodic nudge. The fix is a good example of how modern kernel security work often blends correctness, concurrency hygiene, and exploit hardening into a single patch. (nvd.nist.gov)

Background — full context​

RxRPC is not a generic networking footnote; it is a real protocol layer in the Linux kernel. The kernel documentation describes it as a reliable two-phase transport over UDP that supports secure remote operations, with both kernel and userspace use cases through AF_RXRPC sockets. It is designed around a request/reply model, and the kernel side keeps protocol state, call tracking, and transport bookkeeping in play while data moves through send and receive phases. (docs.kernel.org)
That background matters because the vulnerable code sits in a subsystem that is already highly stateful. RxRPC maintains call objects, peer objects, timers, workers, and packet handling logic that can all overlap in time. In this environment, a field that is read by one execution context and written by another can trigger the Linux Kernel Concurrency Sanitizer, even when the practical impact is much less dramatic than the warning suggests. The CVE description makes clear that this is exactly what happened: rxrpc_peer_keepalive_worker and rxrpc_send_data_packet were both accessing ->last_tx_at without locking. (nvd.nist.gov)
The key detail is that the field was being used for an approximate decision, not for a strict accounting guarantee. The kernel description says the read only needs an estimated “time of last transmission” to decide whether a keepalive packet is warranted. That explains why the fix did not require a broad locking redesign. Instead, maintainers chose a narrower type change that preserves the behavioral intent while eliminating the race report and the possibility of torn reads on 32-bit architectures. (nvd.nist.gov)
For WindowsForum readers who follow kernel security beyond the headlines, this is one of those patches that illustrates the difference between a bug that is exploitable in theory and a bug that is operationally meaningful in practice. The CVE exists because the kernel community wanted a clean, robust description for a flaw that was observable under KCSAN and potentially unsafe on certain architectures. But the remediation strategy reflects a subtler truth: not every race needs a mutex; sometimes it needs a better data representation. (nvd.nist.gov)

---

What CVE-2026-23118 actually changes​

The field at the center of the issue​

The affected field is peer->last_tx_at, which records the time of the most recent transmission. In the buggy form described by NVD, one path wrote conn->peer->last_tx_at = ktime_get_seconds(); while another path later computed keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;. Those accesses were lockless and therefore visible to the concurrency sanitizer as a data race. (nvd.nist.gov)
The kernel note also points out a second issue: because last_tx_at was a 64-bit value, a 32-bit architecture could experience load/store tearing. That means a reader could observe a value that was split across two machine-word updates, producing a bogus timestamp rather than a clean, atomic read. (nvd.nist.gov)

Why the race was tolerated conceptually​

This is one of the more interesting parts of the vulnerability story. The kernel description says the lockless access was “not actually a problem” in the sense of protocol correctness, because the read is only used to decide whether a keepalive is needed. In other words, a slightly stale value would not necessarily break the transport, but it still looked wrong to KCSAN and still exposed a tearing hazard on 32-bit systems. (nvd.nist.gov)
That distinction is important. Kernel developers often differentiate between:

• semantic bugs, where the wrong value causes visible protocol failure;
• concurrency bugs, where memory ordering or atomicity is violated;
• hardening bugs, where the code is technically legal on one architecture but fragile elsewhere.

CVE-2026-23118 sits in the overlap of all three categories. (nvd.nist.gov)

The chosen fix​

The fix was deliberately conservative: switch last_tx_at from a 64-bit time value to an unsigned int, and store only the low 32 bits of the time64_t value. The kernel notes that the timestamp can be reconstructed when needed as long as no more than 68 years have elapsed since the last transmission. That is an almost comic upper bound, but it reflects the practical intent: preserve usable time information while avoiding atomicity problems. (nvd.nist.gov)
This is a classic kernel engineering tradeoff:

• reduce the width of the shared datum;
• retain enough precision for protocol logic;
• avoid introducing extra locks into a hot path;
• make the data race disappear at the representation level.

That approach is particularly attractive in a receive path where latency and contention matter. (nvd.nist.gov)

---

Why the receive path matters​

RxRPC receive handling is stateful​

RxRPC’s kernel interface includes explicit receive operations for request and reply payloads. The documentation shows that rxrpc_kernel_recv_data() is used to pull data from a call, with semantics that differ depending on whether the caller wants more data or has reached the end of the receive phase. The protocol also tracks call state, data sequence endings, and abort conditions. (docs.kernel.org)
That means the receive side is not just a dumb buffer drain. It participates in call lifecycle decisions, state transitions, and completion handling. A field like last_tx_at may seem peripheral, but in a protocol stack, “peripheral” fields often determine whether state machines remain healthy under load. (docs.kernel.org)

The keepalive worker is part of receive-side maintenance​

The CVE specifically identifies rxrpc_peer_keepalive_worker as one of the racing contexts. Keepalive logic typically runs as deferred maintenance, triggered when a peer has been quiet long enough that the kernel wants to probe liveness or keep a path active. That is not the same thing as payload receipt, but it is tightly coupled to traffic flow and call liveness. (nvd.nist.gov)
In practical terms, the receive path and the keepalive path both depend on a coherent view of peer activity:

• if traffic has just been sent, a keepalive may be unnecessary;
• if the peer has been quiet, a keepalive may be useful;
• if the timestamp is read incorrectly, the worker may make the wrong decision.

The bug did not turn RxRPC into a broken protocol, but it did expose a correctness blemish in the path that decides when to ask, “Are you still there?” (nvd.nist.gov)

What “affected receive path” really means​

The phrase “affected receive path” can sound more dramatic than it is. Here, it does not mean that incoming packets were being parsed incorrectly or that data could be forged. Instead, it means the receive-related code paths interacted with shared peer state in a way that created a race and potential tearing hazard. The vulnerable behavior lived in the bookkeeping around receive activity and keepalive timing, not in the integrity of packet payload decoding itself. (nvd.nist.gov)
That nuance matters for security teams triaging exposure. A flaw in protocol bookkeeping may warrant kernel updates, but it is not automatically evidence of a direct remote code execution path. CVE-2026-23118 reads more like a correctness-and-hardening issue than a straightforward exploitation primitive. (nvd.nist.gov)

---

How the bug was discovered​

KCSAN did the heavy lifting​

The CVE text explicitly mentions a BUG: KCSAN: data-race warning. KCSAN is the Linux Kernel Concurrency Sanitizer, a tool designed to detect data races by observing concurrent accesses and flagging patterns that violate expected synchronization rules. In this case, it caught the read-write overlap on last_tx_at. (nvd.nist.gov)
That is an important clue about the quality of the fix. Kernel maintainers were not responding to a crash dump or a confirmed exploit chain. They were responding to sanitizer output and then making the code more robust across architectures. In modern kernel security, that is a standard and increasingly necessary path to remediation. (nvd.nist.gov)

The patch is evidence-driven, not speculative​

The vulnerability entry states plainly that the kernel team believed the lockless accesses were “not actually a problem” for the intended use case. That kind of language often appears when a sanitizer catches a technically real race that does not map cleanly to a user-visible bug. The resulting patch is less about panicked firefighting and more about improving the kernel’s concurrency story so the code remains clean, analyzable, and portable. (nvd.nist.gov)

Why this still became a CVE​

A common question with bugs like this is why they get CVE assignment at all if the immediate impact seems low. The answer is that CVEs are not limited to dramatic exploit primitives. They also cover flaws that can:

• trigger undefined concurrency behavior,
• produce architecture-specific errors,
• degrade reliability in kernel state machines,
• or represent security-relevant correctness issues when combined with other weaknesses.

CVE-2026-23118 fits that model well. It is a narrow, technically precise flaw in a kernel transport subsystem with enough cross-architecture nuance to justify public tracking. (nvd.nist.gov)

---

The technical mechanics of the fix​

From 64-bit time to low-word storage​

The fix replaces a full 64-bit timestamp with an unsigned int holding only the least significant word of time64_t. That makes the shared value more suitable for lockless use, especially on architectures where atomic 64-bit access is not guaranteed. (nvd.nist.gov)
The logic is straightforward:

• the code does not need perfect historical precision;
• it only needs a recent-enough indicator;
• the low bits are enough for the keepalive decision;
• reconstruction is possible if the elapsed interval is bounded.

This is one of those kernel tricks that looks suspicious from a distance but is entirely reasonable once you understand the workload. (nvd.nist.gov)

Why the 68-year remark matters​

The “68 years” detail is not a joke, exactly. It comes from the span of a 32-bit seconds counter before wraparound becomes meaningful in the reconstruction logic. In the context of RxRPC keepalive decisions, that is effectively infinite, because no realistic peer activity gap should depend on a timestamp from decades ago. The point is to show that the lower 32 bits provide enough practical range for the feature. (nvd.nist.gov)

Why not just add a lock?​

The kernel could have introduced stronger synchronization around last_tx_at, but that would have created a different tradeoff:

• more contention,
• more overhead in a time-sensitive path,
• more complexity in code that only needs approximate freshness,
• and potentially broader ripple effects through the RxRPC timing model.

By changing the representation, maintainers solved the issue where it lived. That is often the cleanest kernel fix when the data itself is advisory rather than authoritative. (nvd.nist.gov)

The broader design lesson​

Kernel developers routinely face a choice between:

• protecting data with synchronization,
• or changing the invariant so synchronization is unnecessary.

This CVE shows the second option in action. If the code only needs a rough “last sent” marker, a smaller atomic-friendly representation is often better than a larger precise value that invites tearing. (nvd.nist.gov)

---

Scope and likely impact​

Which systems are most likely to care​

Any Linux kernel build that includes RxRPC support can theoretically be affected if it contains the vulnerable code before the fix. That said, the practical exposure is limited by deployment reality. RxRPC is not a universal desktop feature; it is more likely to matter in environments using AFS-related workloads, specialized network services, or kernel configurations that actively enable AF_RXRPC. The kernel documentation notes that AF_RXRPC is the protocol driver underlying RxRPC and that kAFS uses it for AFS functionality. (docs.kernel.org)

Architecture sensitivity​

The load/store tearing angle is the part that makes this more than a theoretical cleanliness issue. On 32-bit architectures, non-atomic 64-bit accesses are a known hazard. That means the bug had one profile on 64-bit systems and another on 32-bit systems:

• on 64-bit systems, the concern is primarily the data race warning and stale timing logic;
• on 32-bit systems, there is an additional correctness risk from torn values.

That dual nature helps explain the chosen fix. (nvd.nist.gov)

Exploitability should not be overstated​

Nothing in the available kernel description suggests a direct route to code execution or privilege escalation from this bug alone. The issue is about a raced timestamp used to decide on keepalive behavior, not about attacker-controlled memory corruption. So while it is absolutely worth patching, it should be viewed as a reliability-and-hardening CVE rather than a high-confidence attack primitive. (nvd.nist.gov)

Operational significance​

Even non-exploitable kernel bugs matter because they can:

• destabilize maintenance workers,
• complicate debugging,
• mask genuine races in nearby code,
• and reduce confidence in protocol correctness.

CVE-2026-23118 is exactly the kind of flaw that kernel teams prefer to eliminate early, before it becomes a maintenance tax or a foundation for a more serious bug. (nvd.nist.gov)

---

Relationship to the wider RxRPC codebase​

RxRPC is built around concurrency​

The protocol documentation shows a surprisingly rich kernel interface: starting and shutting down calls, sending and receiving data, aborting calls, tracking RTT, and handling remote aborts and errors. That breadth means state transitions are constant, and any shared field used for timing or peer liveness is living in a busy neighborhood. (docs.kernel.org)

Keepalive logic is only one piece​

The CVE mentions the worker path and the send-data path, but RxRPC also has logic for:

• call acceptance,
• service upgrade,
• end-of-transmit handling,
• abort processing,
• and packet completion.

That diversity makes it unsurprising that a seemingly modest field like last_tx_at could attract concurrency scrutiny. In a protocol stack, seemingly minor shared state often turns out to be one of the most sensitive objects in the subsystem. (docs.kernel.org)

Why this kind of bug is common in kernel networking​

Kernel networking code is frequently optimized for speed and low overhead. That means lockless reads, per-CPU state, timers, and deferred work are commonplace. Those patterns are valid, but they also produce exactly the kind of race KCSAN detected here. The presence of a sanitizer warning does not necessarily imply a fatal flaw; it often means the subsystem has reached the edge of its carefully managed concurrency model. (nvd.nist.gov)

---

Strengths and Opportunities​

Strengths​

• Minimal fix surface: The patch changes representation rather than behavior, limiting collateral impact. (nvd.nist.gov)
• Architecture-aware design: The new unsigned int approach avoids 64-bit tearing on 32-bit systems. (nvd.nist.gov)
• Protocol intent preserved: The keepalive decision only needs an approximate time. (nvd.nist.gov)
• Good sanitization discipline: KCSAN found the issue before it turned into a bigger debugging problem. (nvd.nist.gov)
• Low operational disruption: The fix should be easy to carry in stable trees. (nvd.nist.gov)

Opportunities​

• Audit adjacent RxRPC fields for similar lockless timekeeping patterns. (docs.kernel.org)
• Review other protocol workers that use “approximate enough” timestamps without explicit synchronization. (docs.kernel.org)
• Reinforce concurrency documentation so future maintainers understand which fields are advisory and which are authoritative. (docs.kernel.org)
• Expand sanitizer coverage in protocol-heavy test builds to catch similar issues earlier. (nvd.nist.gov)
• Benchmark keepalive logic after representation changes to ensure no measurable regression. (nvd.nist.gov)

---

Risks and Concerns​

Risks​

• Residual race patterns may exist nearby.
• 32-bit support always raises atomicity questions.
• Timestamp compression can complicate future maintenance.
• Keepalive heuristics may become harder to reason about over time.
• A “harmless” race can still obscure more serious bugs.

Concerns​

• The CVE description is terse, so downstream users may overestimate or underestimate the real impact. (nvd.nist.gov)
• The receive path wording can sound broader than the affected code actually is, which may confuse triage teams. (nvd.nist.gov)
• The lack of a CVSS score from NVD at publication time leaves some organizations without immediate severity guidance. (nvd.nist.gov)
• Patch adoption timing may vary across vendor kernels and long-term support branches. (nvd.nist.gov)
• Kernel maintainers must ensure that representation shortcuts remain valid as protocol timing logic evolves. (docs.kernel.org)

---

What administrators should do​

For Linux kernel operators​

• Check whether your kernel tree includes the RxRPC fix.
• Treat the CVE as a real kernel update item, even if it appears low severity.
• Prioritize it on systems that actually use AF_RXRPC or kAFS.
• Do not assume x86-only deployment eliminates the issue; 32-bit concerns are part of the story.
• Verify vendor backports rather than relying solely on mainline version numbers.

For enterprise teams​

• Map AF_RXRPC exposure in your fleet.
• Review whether AFS or other RxRPC-dependent services are in use.
• Correlate kernel package versions with vendor advisories.
• Include this CVE in routine patch cycles, especially for servers.
• Watch for backported fixes under vendor-specific patch numbers.

For security teams​

• Classify this as a correctness-driven kernel vulnerability with architecture-specific implications.
• Avoid overclaiming exploitability.
• Use it as a reminder to look for race conditions in “noncritical” timing fields.
• Track whether related RxRPC issues appear in nearby releases.
• Ensure your vulnerability management tooling reflects the actual fixed build, not only the CVE label.

---

Wider lessons from the fix​

Data races are not always dramatic, but they are always meaningful​

One of the recurring lessons in kernel development is that a “harmless” race often isn’t harmless in the long run. It might not crash anything today, but it can still create undefined behavior, portability problems, or maintenance blind spots. CVE-2026-23118 is a good illustration of that principle. (nvd.nist.gov)

Correctness and security keep converging​

The more mature kernel security becomes, the more it looks like engineering discipline rather than isolated patching. Sanitizers, architecture portability, and protocol semantics are now part of the same conversation. This CVE is not a blockbuster exploit story; it is a sign of a kernel ecosystem that is increasingly unwilling to leave concurrency warnings unresolved. (nvd.nist.gov)

Approximation is sometimes the right answer​

It is easy to think that more precision is always better. In practice, protocol code often wants a timestamp that is “good enough” rather than perfectly exact. The RxRPC fix is a reminder that correctness depends on matching the data structure to the actual question being asked. If the question is “Should I send a keepalive now?”, then a compact and tear-resistant time marker may be better than a perfect but fragile one. (nvd.nist.gov)

---

What to Watch Next​

Follow-up kernel releases​

The first thing to watch is straightforward: whether downstream stable trees and vendor kernels have absorbed the RxRPC fix everywhere it matters. Because NVD’s description is sourced from kernel.org material and cites multiple stable references, this is the kind of vulnerability that is often backported rather than left to drift until the next mainline release. (nvd.nist.gov)

Adjacent RxRPC cleanup​

A second area to watch is whether maintainers use this opportunity to audit other RxRPC state fields for similar assumptions. Once a subsystem gets one concurrency-driven CVE, it often prompts a broader review of related code. The protocol documentation shows enough moving parts—call state, keepalive logic, receive handling, abort tracking—that such a review would be sensible. (docs.kernel.org)

Vendor severity guidance​

A third thing to watch is how vendors classify the issue in their advisories. NVD had not assigned a base score at the time of publication, which leaves room for differing interpretations of impact. Some vendors may present it as a low-severity correctness fix; others may place more emphasis on 32-bit atomicity and kernel hygiene. (nvd.nist.gov)

Any related race disclosures​

Finally, keep an eye on whether neighboring RxRPC paths produce additional data-race reports. When a protocol subsystem is already using lockless timing fields and deferred workers, more sanitizer findings are always possible. The good news is that such findings often lead to exactly the kind of small, local, high-value fixes seen here. (nvd.nist.gov)
The bottom line is that CVE-2026-23118 is a deceptively modest kernel flaw with a very kernel-like lesson: if a field only needs to be approximate, make it safely approximate. In RxRPC’s receive-and-keepalive machinery, that meant shrinking a timestamp, eliminating a race report, and preserving protocol behavior without burdening the hot path with unnecessary locking. It is not the flashiest security story of the year, but it is exactly the kind of fix that keeps a large, concurrent kernel honest.

---

Source: msrc.microsoft.com Security Update Guide - Microsoft Security Response Center