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.

An update of the linux package has been released.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-63980)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
340681	Ubuntu 24.04 LTS / 26.04 LTS / Pro Realtime 24.04 LTS : Linux kernel (NVIDIA) vulnerabilities (USN-8663-1)	Nessus	Ubuntu Local Security Checks	Local	high
340045	Ubuntu 26.04 LTS : Linux kernel (NVIDIA BaseOS) vulnerabilities (USN-8664-1)	Nessus	Ubuntu Local Security Checks	Local	high
333762	Photon OS 5.0: Linux PHSA-2026-5.0-92-0895	Nessus	PhotonOS Local Security Checks	Local	high
328493	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-1968)	Nessus	Amazon Linux Local Security Checks	Local	high
328218	Linux Distros Unpatched Vulnerability : CVE-2026-63980	Nessus	Misc.	Local	high
322944	Photon OS 5.0: Linux PHSA-2026-5.0-0895	Nessus	PhotonOS Local Security Checks	Local	high
322087	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-1881)	Nessus	Amazon Linux Local Security Checks	Local	high

Detections

Analytics

CVE-2026-63980

high

Tenable Plugins

high

high

high

high

high

high

high