Linux Kernel EUVD-2026-59532

Exploitation requires two explicit configuration prerequisites: (1) the nvmet-tcp kernel module must be loaded and an NVMe-oF target must be actively configured and listening - this is not present in default Linux installations and requires deliberate storage administrator setup; (2) TLS must be the configured transport security mode on that target, since the vulnerable function nvmet_tcp_tls_handshake_done() is only invoked in TLS code paths - a plain-TCP nvmet-tcp target is not affected. The attacker requires network reachability to the NVMe-oF listening port (TCP 4420 by default); no NVMe credentials or authentication are needed since the bug triggers during the pre-auth TLS phase. Limiting factors include: nvmet-tcp is not loaded on most Linux systems; storage fabrics are typically on isolated VLANs or InfiniBand segments not reachable from untrusted networks; and achieving meaningful denial of service likely requires sustained repeated connections rather than a single packet, which is detectable by connection-rate monitoring on the target host.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5) is credible and consistent with the description: the TLS handshake phase precedes NVMe authentication, so any TCP-reachable client can attempt to trigger the resource leak without credentials. However, real-world risk is substantially bounded by deployment context. EPSS is 0.17% (6th percentile), indicating minimal automated exploitation probability assessed by the community. The vulnerability is absent from CISA KEV, confirming no known active exploitation. Two structural factors limit exposure: (1) nvmet-tcp with TLS is a non-default, explicitly configured storage feature - the vast majority of Linux systems are unaffected; (2) NVMe-oF targets are routinely deployed on dedicated storage fabric networks isolated from untrusted clients. The availability impact rating (A:H) is appropriate for a resource-exhaustion bug that can be triggered repeatedly with low per-connection cost, but actually achieving denial of service likely requires sustained flooding rather than a single connection. No conflicting signals between CVSS and description were identified. This is a legitimate patch-priority item for storage infrastructure operators running nvmet-tcp TLS, but irrelevant for general-purpose Linux deployments.

An attacker with network access to TCP port 4420 on a storage server running nvmet-tcp with TLS connects and initiates a TLS handshake, then abruptly resets the TCP connection at a point that leaves the socket in a non-ESTABLISHED state precisely when the kernel fires the handshake-done callback. This causes nvmet_tcp_set_queue_sock() to fail, its error is ignored, and the kernel queue and socket structures are leaked without cleanup. By scripting this connection-abort sequence in a tight loop, the attacker can steadily exhaust kernel socket structures or memory, ultimately degrading or denying storage service. No public proof-of-concept is known at the time of analysis.