CVE-2026-63980
High · 7.5CVSS
7.5
EPSS
0.3%
Published
Jul 19, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's network connection handling can make systems freeze when certain network storage traffic arrives.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Deadlock in hn_lock when tls_handshake_cancel() is invoked from BH/softirq context by nvmet_tcp_state_change() while a process-context thread holds the lock with plain spin_lock, violating BH-safety rules.
Why it matters to the business
Networked Linux systems using NVMe-over-TCP with TLS handshakes can hang or become unresponsive, disrupting storage services and availability for dependent applications.
How an attack unfolds
An attacker triggers network events that cause nvmet_tcp_state_change() to run in softirq context and call into the handshake cancel path while process-context code holds hn_lock, resulting in deadlock on the same CPU.
How to fix it
Apply the upstream kernel patch that converts all hn_lock acquisitions from spin_lock/spin_unlock to spin_lock_bh/spin_unlock_bh; rebuild and deploy updated kernel images across affected hosts.
How to confirm the fix worked
Inspect net/handshake source for spin_lock_bh usage on hn_lock; run stress tests exercising nvmet_tcp_schedule_release_queue under concurrent handshake load to confirm absence of deadlock.
Typical attack path
- Establish NVMe/TCP connection requiring TLS handshake
- Force state transition to DISCONNECTING from BH context
- Invoke tls_handshake_cancel() which acquires hn_lock without disabling softirqs
- Contend with process-context holder of the same lock causing deadlock
How to detect it
Search kernel logs for spinlock deadlock warnings or softirq contention involving handshake or nvmet_tcp; monitor for hung NVMe/TCP queues and TLS handshake callbacks that fail to release references.
What your security team should do
- Expedite kernel updates for systems exposing NVMe/TCP with TLS
- Add kernel deadlock and softirq contention monitoring for handshake paths
- Review and test NVMe target configurations that rely on atomic state transitions
The record
In the Linux kernel, the following vulnerability has been resolved: net/handshake: Use spin_lock_bh for hn_lock nvmet_tcp_state_change(), a socket callback that runs in BH context, can reach handshake_req_cancel() via nvmet_tcp_schedule_release_queue() and tls_handshake_cancel(). handshake_req_cancel() acquires hn->hn_lock with plain spin_lock(). If a process-context thread on the same CPU holds hn->hn_lock when a softirq invokes the cancel path, the lock attempt deadlocks. This is the only caller that invokes tls_handshake_cancel() from BH context; every other consumer calls it from process context. Deferring the cancel to process context in the NVMe target is not straightforward: nvmet_tcp_schedule_release_queue() must call tls_handshake_cancel() atomically with its state transition to DISCONNECTING. If the cancel were deferred, the handshake completion callback could fire in the window before the cancel runs, observe the unexpected state, and return without dropping its kref on the queue. Reworking that interlock is considerably more invasive than hardening the handshake lock. Convert all hn->hn_lock acquisitions from spin_lock/spin_unlock to spin_lock_bh/spin_unlock_bh so the lock is never taken with softirqs enabled.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|