This is a defensive coding failure, not a missing feature. The cleanup function nvmet_tcp_schedule_release_queue() already exists and works — the bug is that during TLS handshake completion, when nvmet_tcp_set_queue_sock() returns an error because the socket is no longer in TCP_ESTABLISHED state, the error path falls through without invoking cleanup. The queue and socket leak silently.
The root cause is that TLS handshakes are asynchronous and can take time. During that window, the TCP connection state can change (reset, close, migration). When the TLS completion callback fires but finds the socket in an unexpected state, the NVMe-TCP queue ends up in a liminal condition: not properly initialized for use, but not scheduled for cleanup either. That's a state machine contradiction, not just a missing function call.
The CVSS 7.5 rating reflects High severity with Moderate likelihood — but the likelihood assessment assumes a single attacker exploiting a single instance. In practice, NVMe-TCP targets serve multiple initiators simultaneously, and each failed TLS handshake compounds. In a busy storage node handling dozens of VMs, transient network turbulence (retransmits, path failover, migration events) hitting enough connections can gradually exhaust available sockets without any malicious peer involvement. The blast radius of a mundane network hiccup is potential storage unavailability propagating to every dependent workload.
Beyond resource exhaustion, there's a more immediate hazard: a dangling reference. The socket remains visible to the network while the NVMe-TCP state machine has moved on, creating a window where the socket might accept or transmit data while the storage target's internal bookkeeping has abandoned it. That's the exploitation surface, not the slow accumulation scenario.
For defenders: check your NVMe-TCP targets for leaked queues and sockets, particularly around TLS handshake completion. The fix is straightforward — ensure cleanup is invoked on error — but the architectural question is whether this exact pattern exists in other TLS handshake completion paths across the kernel tree. This bug class follows a predictable lineage (similar to block layer async completion bugs circa 2019-2021), suggesting systematic audit of TLS integration points is warranted.