CVE-2026-23179 Overview
A deadlock vulnerability has been identified in the Linux kernel's NVMe-oF TCP target subsystem (nvmet-tcp). The issue occurs in the nvmet_tcp_listen_data_ready() function when a socket is closed while in the TCP_LISTEN state. During socket closure, a callback is triggered to flush all outstanding packets, which calls nvmet_tcp_listen_data_ready() with the sk_callback_lock already held. Without proper state checking, the function attempts to acquire the same lock, resulting in a deadlock condition that can hang the system.
Critical Impact
This vulnerability can cause system hangs due to deadlock conditions in the NVMe-oF TCP target subsystem, potentially affecting storage availability in enterprise environments using NVMe over Fabrics.
Affected Products
- Linux kernel (versions with nvmet-tcp subsystem)
- Systems using NVMe-oF (NVMe over Fabrics) TCP target functionality
- Enterprise storage deployments leveraging NVMe-TCP protocol
Discovery Timeline
- 2026-02-14 - CVE CVE-2026-23179 published to NVD
- 2026-02-18 - Last updated in NVD database
Technical Details for CVE-2026-23179
Vulnerability Analysis
This vulnerability exists in the NVMe-oF TCP target implementation within the Linux kernel. The nvmet_tcp_listen_data_ready() function is a callback handler invoked when data becomes available on a listening TCP socket. The core issue stems from improper lock state management during socket teardown operations.
When a TCP socket in the TCP_LISTEN state is closed, the kernel initiates cleanup procedures that flush outstanding network packets. This cleanup operation invokes the nvmet_tcp_listen_data_ready() callback while already holding the sk_callback_lock. The vulnerable code path then attempts to acquire the same sk_callback_lock, which it cannot obtain since the lock is non-recursive. This creates a classic deadlock scenario where the calling thread waits indefinitely for a lock it already holds.
The impact of this vulnerability is a complete system hang affecting NVMe-oF TCP target operations. In enterprise storage environments where NVMe over Fabrics is deployed for high-performance storage networking, this could lead to denial of service conditions affecting storage availability.
Root Cause
The root cause is a missing state check before lock acquisition in the nvmet_tcp_listen_data_ready() function. The function should verify whether the socket is in TCP_LISTEN state before attempting to acquire sk_callback_lock. Without this check, the code path that handles socket closure can trigger a recursive lock acquisition attempt on the same non-recursive spinlock.
Attack Vector
The vulnerability is triggered through specific socket state transitions during connection teardown. An attacker or system condition that causes rapid socket close operations while the nvmet-tcp target is actively listening could potentially trigger this deadlock. The attack surface includes:
The deadlock condition can be triggered when network connections to the NVMe-oF TCP target are terminated abruptly or during high connection churn scenarios. The vulnerability manifests when the socket closure callback executes while the socket is still in TCP_LISTEN state, causing the data ready handler to be invoked with locks already held. For detailed technical analysis, see the kernel git commits referenced in the external references.
Detection Methods for CVE-2026-23179
Indicators of Compromise
- System hangs or unresponsive behavior specifically affecting NVMe-oF TCP target operations
- Kernel soft lockup warnings or hung task warnings in system logs related to nvmet_tcp threads
- Storage connectivity failures for clients connecting via NVMe-TCP protocol
Detection Strategies
- Monitor for kernel lockup warnings in /var/log/kern.log or dmesg output containing references to nvmet_tcp or sk_callback_lock
- Implement watchdog monitoring for NVMe-oF target services to detect unresponsive states
- Use kernel tracing tools (ftrace, bpftrace) to monitor lock acquisition patterns in nvmet-tcp code paths
Monitoring Recommendations
- Configure kernel lockup detection with appropriate timeouts using kernel.hung_task_timeout_secs
- Enable NMI watchdog for detecting hard lockups that may result from deadlock escalation
- Monitor NVMe-oF target connection statistics for abnormal connection failures or timeouts
How to Mitigate CVE-2026-23179
Immediate Actions Required
- Review deployed Linux kernel versions for affected nvmet-tcp implementations
- Plan maintenance windows to apply kernel patches addressing this deadlock condition
- Consider temporarily disabling NVMe-oF TCP target functionality if immediate patching is not possible
Patch Information
The Linux kernel maintainers have released patches to address this vulnerability. The fix involves adding a check for the TCP_LISTEN state before attempting to acquire sk_callback_lock() in the nvmet_tcp_listen_data_ready() function. Patches are available through the official kernel git repository:
Workarounds
- If NVMe-oF TCP target functionality is not required, unload the nvmet_tcp kernel module to eliminate the attack surface
- Implement network-level access controls to limit connections to NVMe-oF TCP target ports from trusted hosts only
- Monitor systems for signs of deadlock and implement automated recovery procedures
# Unload nvmet-tcp module if not in use
modprobe -r nvmet_tcp
# Check if module is loaded
lsmod | grep nvmet_tcp
# Block external access to NVMe-oF TCP port (typically 8009)
iptables -A INPUT -p tcp --dport 8009 -j DROP
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
