CVE-2026-23419: Linux Kernel Race Condition Vulnerability

CVE-2026-23419 Overview

A circular locking dependency vulnerability has been identified in the Linux kernel's Reliable Datagram Sockets (RDS) TCP subsystem. The vulnerability exists in the rds_tcp_tune() function where sk_net_refcnt_upgrade() is called while holding the socket lock, creating a potential deadlock condition that could impact system availability.

Critical Impact

This kernel vulnerability can lead to system deadlocks when the RDS TCP module encounters specific locking conditions, potentially causing denial of service on affected Linux systems.

Affected Products

• Linux kernel with net/rds module enabled
• Systems utilizing RDS (Reliable Datagram Sockets) over TCP
• Linux kernel versions prior to the security patches

Discovery Timeline

• April 3, 2026 - CVE-2026-23419 published to NVD
• April 3, 2026 - Last updated in NVD database

Technical Details for CVE-2026-23419

Vulnerability Analysis

The vulnerability was identified by syzbot, an automated kernel fuzzing system. The issue occurs in the RDS (Reliable Datagram Sockets) TCP implementation, specifically within the rds_tcp_tune() function. When this function calls sk_net_refcnt_upgrade(), it triggers a memory allocation operation through the call chain get_net_track() → ref_tracker_alloc(). This memory allocation attempt occurs while the socket lock (k-sk_lock-AF_INET6) is already held by the current task.

The circular dependency manifests when the memory allocation subsystem needs to reclaim memory (indicated by acquiring fs_reclaim lock), but the task is already holding the socket lock. This creates a classic ABBA deadlock scenario where different code paths acquire locks in inconsistent orders, potentially causing the system to hang.

Root Cause

The root cause of this vulnerability is improper lock ordering in the rds_tcp_tune() function. The function performs memory allocation operations (which may trigger memory reclaim) while holding the socket lock. Since memory reclaim operations may need to acquire locks that could also be held by code paths that subsequently attempt to acquire socket locks, a circular dependency is created.

The kernel's lockdep subsystem detected this potential deadlock condition, warning that kworker/u10:8/15040 is attempting to acquire fs_reclaim lock at address ffffffff8e9aaf80 while already holding the socket lock at ffff88805a3c1ce0.

Attack Vector

This is a local kernel vulnerability that can be triggered through normal RDS TCP operations. While not directly exploitable for code execution, the deadlock condition can result in:

• System hangs requiring hard reboot
• Denial of service affecting all processes on the system
• Potential data corruption if the system becomes unresponsive during write operations

The vulnerability is triggered when the RDS TCP tuning code path executes under memory pressure conditions, making it potentially exploitable by local users who can influence memory allocation patterns.

Detection Methods for CVE-2026-23419

Indicators of Compromise

• Kernel warning messages containing "possible circular locking dependency detected"
• System logs showing lockdep warnings referencing rds_tcp_tune function
• Unexplained system hangs or freezes during RDS TCP operations
• Kernel traces showing fs_reclaim lock contention with socket locks

Detection Strategies

• Monitor kernel logs (dmesg or /var/log/kern.log) for lockdep warnings mentioning rds_tcp_tune
• Deploy SentinelOne kernel-level monitoring to detect anomalous lock acquisition patterns
• Configure kernel lockdep debugging to catch circular dependencies during testing
• Review system crash dumps for stack traces involving RDS TCP module functions

Monitoring Recommendations

• Enable kernel lockdep debugging on development and staging systems
• Configure alerting for kernel warning messages related to locking dependencies
• Monitor system responsiveness and set up watchdog timers to detect hangs
• Track RDS module usage and correlate with system stability metrics

How to Mitigate CVE-2026-23419

Immediate Actions Required

• Apply the kernel patches from the upstream Linux kernel git repository
• If patching is not immediately possible, consider disabling the RDS kernel module if not required
• Monitor affected systems for signs of system hangs or deadlock conditions
• Plan maintenance windows for kernel updates on production systems

Patch Information

The Linux kernel maintainers have released patches that fix this vulnerability by moving the sk_net_refcnt_upgrade() call outside of the socket lock critical section. This reordering is safe because the fields modified by sk_net_refcnt_upgrade() (sk_net_refcnt, ns_tracker) are not accessed by concurrent code paths at this point in execution.

Multiple kernel commit fixes are available:

• Kernel Git Commit 026bbaee
• Kernel Git Commit 6a877ece
• Kernel Git Commit 6ce948fa
• Kernel Git Commit 8519e688
• Kernel Git Commit 8babb271

Workarounds

• Disable the RDS kernel module if not required: modprobe -r rds_tcp rds
• Blacklist the RDS module to prevent automatic loading: add blacklist rds and blacklist rds_tcp to /etc/modprobe.d/blacklist.conf
• Implement system watchdog timers to automatically recover from potential hangs
• Reduce memory pressure on affected systems to minimize the likelihood of triggering the deadlock

# Disable RDS module temporarily
sudo modprobe -r rds_tcp rds

# Permanently blacklist RDS modules if not needed
echo "blacklist rds" | sudo tee -a /etc/modprobe.d/blacklist-rds.conf
echo "blacklist rds_tcp" | sudo tee -a /etc/modprobe.d/blacklist-rds.conf

# Verify modules are not loaded
lsmod | grep rds