CVE-2026-63980: Linux Kernel Race Condition Vulnerability

CVE-2026-63980 Overview

CVE-2026-63980 is a Linux kernel vulnerability in the net/handshake subsystem. The flaw allows a deadlock condition when handshake_req_cancel() acquires hn->hn_lock using plain spin_lock() while softirq context can enter the same lock path. The NVMe over TCP target callback nvmet_tcp_state_change() runs in bottom-half (BH) context and reaches handshake_req_cancel() through nvmet_tcp_schedule_release_queue() and tls_handshake_cancel(). When a process-context thread on the same CPU holds hn->hn_lock and a softirq invokes the cancel path, the lock attempt deadlocks the CPU.

Critical Impact
A network-reachable deadlock in the kernel handshake lock path can hang CPUs handling NVMe/TLS traffic, producing a denial-of-service condition on affected Linux systems.

Affected Products

Linux kernel builds containing the net/handshake subsystem with unpatched hn_lock usage
Systems running NVMe-oF TCP target (nvmet_tcp) with TLS handshake support
Distributions shipping kernels prior to the fix commits 06ab5978, 0866569f, 91898de9, and cc993e09

Discovery Timeline

2026-07-19 - CVE-2026-63980 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-63980

Vulnerability Analysis

The defect is a locking rule violation in the kernel handshake helper. handshake_req_cancel() protects handshake-net state with hn->hn_lock but acquires it using spin_lock() rather than the BH-safe variant. Every other caller of tls_handshake_cancel() runs in process context, so the unsafe acquisition was benign until NVMe-oF TCP began invoking it from a softirq.

The nvmet_tcp_state_change() socket callback runs in BH context. It calls nvmet_tcp_schedule_release_queue(), which invokes tls_handshake_cancel() and ultimately handshake_req_cancel(). If a process-context task on the same CPU already holds hn->hn_lock, the incoming softirq spins waiting for that lock while blocking the process context from releasing it, producing a hard CPU deadlock.

Root Cause

The root cause is inconsistent spinlock discipline. A spinlock shared between process context and softirq context must be acquired with spin_lock_bh() to disable local softirqs during the critical section. Using plain spin_lock() leaves softirqs enabled, allowing the reentrancy path described above. This is a classic kernel locking race condition rather than a memory-safety issue.

Attack Vector

The attack vector is network-adjacent. A remote client interacting with an NVMe-oF TCP target that uses TLS handshakes can trigger state transitions on the target socket. Repeated or well-timed connection teardowns under contention can drive the cancel path from BH context while another CPU thread holds hn->hn_lock, producing the deadlock. Exploitation does not require authentication to the target host itself. The fix converts every hn->hn_lock acquisition from spin_lock/spin_unlock to spin_lock_bh/spin_unlock_bh, ensuring the lock is never held with softirqs enabled. See the upstream fix commits for the exact source changes:

Detection Methods for CVE-2026-63980

Indicators of Compromise

Kernel soft lockup or hung task warnings referencing handshake_req_cancel, tls_handshake_cancel, or nvmet_tcp_schedule_release_queue in dmesg.
CPUs pinned at 100% system time on hosts running the NVMe-oF TCP target under TLS load.
Stalled or repeatedly reconnecting NVMe-oF TCP initiator sessions to an affected target.

Detection Strategies

Inspect /proc/lockdep and enable CONFIG_PROVE_LOCKING in test builds to surface unsafe softirq-vs-process lock ordering on hn_lock.
Correlate kernel stack traces from dmesg, journalctl -k, or kdump with the affected symbols listed above to identify triggered deadlocks.
Track kernel package versions across the fleet and flag hosts whose kernel does not include the four upstream fix commits.

Monitoring Recommendations

Alert on kernel hung_task and watchdog: BUG: soft lockup messages, especially on NVMe-oF TCP target nodes.
Monitor NVMe target queue release latency and TLS handshake failure rates as leading indicators of stuck cancel paths.
Capture and centralize kernel crash dumps to enable rapid symbol-based triage when a lockup occurs.

How to Mitigate CVE-2026-63980

Immediate Actions Required

Upgrade to a Linux kernel release that includes the fix commits 06ab5978, 0866569f, 91898de9, or cc993e09, whichever your distribution has backported.
On hosts that cannot be patched immediately, stop exposing the NVMe-oF TCP target with TLS to untrusted networks.
Reboot systems after kernel package updates so the corrected net/handshake code is loaded.

Patch Information

The upstream fix converts all hn->hn_lock acquisitions from spin_lock()/spin_unlock() to spin_lock_bh()/spin_unlock_bh(). This ensures softirqs are disabled while the lock is held, eliminating the reentrancy path through nvmet_tcp_state_change(). The patch is available in stable kernel commits 06ab597, 0866569, 91898de, and cc993e0. Apply the vendor kernel update from your distribution when available.

Workarounds

Disable the NVMe-oF TCP target service (nvmet-tcp) on affected hosts until a patched kernel is deployed.
Disable TLS on the NVMe-oF TCP target configuration so the vulnerable tls_handshake_cancel() path is not exercised.
Restrict target reachability with host firewall rules that only permit trusted initiator IP ranges to the NVMe-oF TCP port.

bash

# Temporarily stop the NVMe-oF TCP target and block the service port
systemctl stop nvmet.service
nvmetcli clear
iptables -A INPUT -p tcp --dport 4420 -j DROP