CVE-2026-63980

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/handshake: Use spin_lock_bh for hn_lock<br /> <br /> nvmet_tcp_state_change(), a socket callback that runs in BH context,<br /> can reach handshake_req_cancel() via nvmet_tcp_schedule_release_queue()<br /> and tls_handshake_cancel(). handshake_req_cancel() acquires<br /> hn-&gt;hn_lock with plain spin_lock(). If a process-context thread on<br /> the same CPU holds hn-&gt;hn_lock when a softirq invokes the cancel path,<br /> the lock attempt deadlocks. This is the only caller that invokes<br /> tls_handshake_cancel() from BH context; every other consumer calls it<br /> from process context.<br /> <br /> Deferring the cancel to process context in the NVMe target is not<br /> straightforward: nvmet_tcp_schedule_release_queue() must call<br /> tls_handshake_cancel() atomically with its state transition to<br /> DISCONNECTING. If the cancel were deferred, the handshake completion<br /> callback could fire in the window before the cancel runs, observe the<br /> unexpected state, and return without dropping its kref on the queue.<br /> Reworking that interlock is considerably more invasive than hardening<br /> the handshake lock. Convert all hn-&gt;hn_lock acquisitions from<br /> spin_lock/spin_unlock to spin_lock_bh/spin_unlock_bh so the lock is<br /> never taken with softirqs enabled.