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… (CVE-2026-63980)
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.
AI Analysis
Technical Summary
CVE-2026-63980 addresses a deadlock condition in the Linux kernel's NVMe over TCP handshake implementation. The vulnerability arises when nvmet_tcp_state_change(), a socket callback executing in BH context, calls handshake_req_cancel() through a chain of functions. handshake_req_cancel() acquires hn->hn_lock using spin_lock(), which can deadlock if a process-context thread on the same CPU already holds this lock when a softirq invokes the cancel path. The resolution converts all hn->hn_lock acquisitions to spin_lock_bh/spin_unlock_bh, preventing the lock from being taken with softirqs enabled and thus avoiding the deadlock.
Potential Impact
The vulnerability can cause a deadlock in the Linux kernel's NVMe over TCP handshake code, potentially leading to kernel hangs or denial of service conditions on affected systems. There is no indication of code execution or privilege escalation from the provided data.
Mitigation Recommendations
A fix has been implemented that changes the locking mechanism to use spin_lock_bh/spin_unlock_bh for hn->hn_lock, preventing deadlocks caused by lock acquisition in BH context. Since this vulnerability has been resolved in the Linux kernel, users should apply the official kernel updates containing this fix. Patch status is not explicitly confirmed in the provided data; therefore, check the vendor or Linux kernel advisory for the exact fixed versions and apply updates accordingly.
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… (CVE-2026-63980)
Description
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.
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
CVE-2026-63980 addresses a deadlock condition in the Linux kernel's NVMe over TCP handshake implementation. The vulnerability arises when nvmet_tcp_state_change(), a socket callback executing in BH context, calls handshake_req_cancel() through a chain of functions. handshake_req_cancel() acquires hn->hn_lock using spin_lock(), which can deadlock if a process-context thread on the same CPU already holds this lock when a softirq invokes the cancel path. The resolution converts all hn->hn_lock acquisitions to spin_lock_bh/spin_unlock_bh, preventing the lock from being taken with softirqs enabled and thus avoiding the deadlock.
Potential Impact
The vulnerability can cause a deadlock in the Linux kernel's NVMe over TCP handshake code, potentially leading to kernel hangs or denial of service conditions on affected systems. There is no indication of code execution or privilege escalation from the provided data.
Mitigation Recommendations
A fix has been implemented that changes the locking mechanism to use spin_lock_bh/spin_unlock_bh for hn->hn_lock, preventing deadlocks caused by lock acquisition in BH context. Since this vulnerability has been resolved in the Linux kernel, users should apply the official kernel updates containing this fix. Patch status is not explicitly confirmed in the provided data; therefore, check the vendor or Linux kernel advisory for the exact fixed versions and apply updates accordingly.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-pf6j-pgmp-5g96
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-63980"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27aa2a4a8d598912dbd8
Added to database: 07/19/2026, 19:38:18 UTC
Last enriched: 07/19/2026, 20:00:53 UTC
Last updated: 07/20/2026, 21:51:34 UTC
Views: 13
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.