CVE-2026-23118: Linux Kernel Race Condition Vulnerability

CVE-2026-23118 Overview

A data-race vulnerability has been identified and resolved in the Linux kernel's rxrpc subsystem. The issue exists within the keepalive mechanism, specifically in the rxrpc_peer_keepalive_worker and rxrpc_send_data_packet functions where concurrent read and write operations to the ->last_tx_at field can occur without proper synchronization.

The vulnerability was detected by KCSAN (Kernel Concurrency Sanitizer) which identified potential data-race conditions when updating and reading the last transmission timestamp. Additionally, because ->last_tx_at is a 64-bit value, load/store tearing can occur on 32-bit architectures where atomic 64-bit operations may not be available.

Critical Impact

Race condition in Linux kernel rxrpc subsystem could lead to memory corruption or unexpected behavior on 32-bit systems due to load/store tearing of 64-bit timestamp values.

Affected Products

• Linux Kernel (rxrpc subsystem)
• Systems running 32-bit Linux architectures with rxrpc enabled
• Linux systems utilizing AFS (Andrew File System) functionality

Discovery Timeline

• 2026-02-14 - CVE CVE-2026-23118 published to NVD
• 2026-02-18 - Last updated in NVD database

Technical Details for CVE-2026-23118

Vulnerability Analysis

This vulnerability is classified as a Race Condition affecting the Linux kernel's rxrpc networking subsystem. The issue occurs in the keepalive packet transmission logic where the ->last_tx_at timestamp is accessed concurrently by multiple kernel threads without proper synchronization primitives.

When rxrpc_send_data_packet executes, it updates the peer's last transmission timestamp with:
conn->peer->last_tx_at = ktime_get_seconds();

Concurrently, rxrpc_peer_keepalive_worker reads this value to determine if a keepalive packet should be sent:
keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;

While the lockless access pattern is functionally acceptable since only an approximate transmission time is needed for keepalive decisions, the use of a 64-bit time64_t value creates a tearing hazard on 32-bit architectures. Load/store tearing occurs when a multi-word value is read or written in multiple non-atomic operations, allowing a concurrent thread to observe a partially updated value.

Root Cause

The root cause of this vulnerability stems from two interrelated issues:

1. Missing Memory Barriers: The ->last_tx_at field was accessed without appropriate memory ordering annotations (such as READ_ONCE() and WRITE_ONCE()), which the kernel requires to inform both the compiler and CPU about intentional lockless access patterns.

2. Data Type Sizing Issue: Using a 64-bit time64_t for ->last_tx_at on 32-bit architectures creates the possibility of load/store tearing, where one thread may read half of a value while another thread is in the process of writing.

Attack Vector

The attack vector for this vulnerability is local, requiring execution within the kernel context. Exploitation would involve:

1. An attacker triggering concurrent rxrpc connection activity to induce race conditions between the keepalive worker and data packet transmission paths.

2. On 32-bit systems, the tearing issue could potentially be exploited to cause incorrect timestamp calculations, affecting keepalive timing decisions.

3. In a worst-case scenario, corrupted timestamp values could lead to unexpected keepalive behavior, potentially causing connection state inconsistencies.

The fix addresses these issues by changing ->last_tx_at to an unsigned int type and storing only the least significant word (LSW) of the time64_t value. This ensures atomic access on all architectures while still providing sufficient precision for keepalive timing decisions, as long as no more than 68 years elapses between transmissions.

Detection Methods for CVE-2026-23118

Indicators of Compromise

• KCSAN (Kernel Concurrency Sanitizer) warnings indicating data-race between rxrpc_peer_keepalive_worker and rxrpc_send_data_packet
• Unexpected rxrpc connection behavior or keepalive packet timing anomalies
• Kernel log messages reporting race condition warnings in the rxrpc subsystem

Detection Strategies

• Enable KCSAN in kernel builds to automatically detect data-race conditions in production or testing environments
• Monitor kernel logs for rxrpc-related warnings or errors using dmesg | grep -i rxrpc
• Review system logs for AFS connectivity issues that may indicate underlying rxrpc problems

Monitoring Recommendations

• Implement continuous kernel log monitoring with alerting for rxrpc subsystem anomalies
• Deploy kernel runtime verification tools capable of detecting race conditions
• Monitor AFS client stability metrics if AFS is in use

How to Mitigate CVE-2026-23118

Immediate Actions Required

• Update to a patched Linux kernel version that includes the rxrpc fix
• If running 32-bit systems with rxrpc enabled, prioritize patching to eliminate load/store tearing risk
• Review and audit any custom kernel modules interacting with the rxrpc subsystem

Patch Information

The Linux kernel developers have released patches to address this vulnerability. The fix modifies the ->last_tx_at field from a 64-bit time64_t to an unsigned int, storing only the LSW of the timestamp. This ensures atomic access on all architectures while maintaining functional accuracy for keepalive timing decisions.

Patch commits are available from the kernel git repository:

• Kernel Git Commit 5d5fe8bcd331
• Kernel Git Commit c08cf314191c
• Kernel Git Commit f8cf1368e0a5

Workarounds

• If immediate patching is not possible, consider disabling the rxrpc kernel module if AFS functionality is not required: modprobe -r rxrpc
• On affected 32-bit systems, evaluate migration to 64-bit kernels where atomic 64-bit operations are natively supported
• Implement network-level monitoring for rxrpc traffic to detect anomalous connection behavior