CVE-2026-63980: net/handshake: Use spin_lock_bh for hn_lock

In the Linux kernel, the following vulnerability has been resolved:

net/handshake: Use spinlockbh for hnlock

nvmettcpstatechange(), a socket callback that runs in BH context, can reach handshakereqcancel() via nvmettcpschedulereleasequeue() and tlshandshakecancel(). handshakereqcancel() acquires hn->hnlock with plain spinlock(). If a process-context thread on the same CPU holds hn->hnlock when a softirq invokes the cancel path, the lock attempt deadlocks. This is the only caller that invokes tlshandshakecancel() from BH context; every other consumer calls it from process context.

Deferring the cancel to process context in the NVMe target is not straightforward: nvmettcpschedulereleasequeue() must call tlshandshakecancel() 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->hnlock acquisitions from spinlock/spinunlock to spinlockbh/spinunlockbh so the lock is never taken with softirqs enabled.