CVE-2026-64534

What it actually does

The flaw is in the Linux kernel NVMe-over-TCP target implementation, specifically the nvmet-tcp receive path for data digest errors. When a malformed or inconsistent NVMe/TCP command reaches an error path where request initialization already failed, the kernel can still call nvmet_req_uninit() as if initialization succeeded. That causes an unmatched percpu_ref_put(), refcount underflow, use-after-free diagnostics, and can ultimately deadlock a kernel workqueue. In practical terms, a remote unauthenticated network peer able to reach an exposed NVMe/TCP target service may be able to crash, hang, or destabilize the host. Although the assigned CVSS indicates high confidentiality, integrity, and availability impact, the described bug most directly supports denial of service and kernel memory-safety instability; code execution or data compromise should be treated as theoretical unless additional exploit details become available.

Why it matters to the business

Systems acting as Linux NVMe-over-TCP storage targets can become unavailable or unstable if reachable by an attacker, potentially interrupting storage access for dependent workloads, hypervisors, databases, or clustered services. Because NVMe/TCP is often used in performance-sensitive storage environments, a kernel workqueue deadlock or host hang can cause cascading application outages, failovers, degraded storage performance, or manual recovery actions. The vulnerability is recent, has low current EPSS, is not listed in CISA KEV, and has no known public exploit maturity in the provided data, but its network-reachable, unauthenticated attack surface and high CVSS warrant prompt patching for any exposed NVMe/TCP targets.

How an attack unfolds

An attacker first identifies a Linux host exposing an NVMe-over-TCP target, typically on TCP port 4420 or another configured NVMe/TCP service port. The attacker establishes or attempts to establish an NVMe/TCP session and sends command traffic crafted to enter the request failure path where nvmet_req_init() does not complete successfully. The attacker then triggers a data digest mismatch so that nvmet_tcp_try_recv_ddgst() follows the digest error handling path. On vulnerable kernels, that path calls nvmet_req_uninit() even though the request was not fully initialized, causing an invalid reference decrement. Repeated or successful triggering can produce kernel warnings, use-after-free diagnostics, refcount underflow messages, and eventually a permanent workqueue deadlock or host instability, disrupting storage service availability.

How to fix it

Apply a Linux kernel update from the operating system, appliance, or storage platform vendor that includes the nvmet-tcp fix to check NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit() in the digest error path. No exact fixed package versions were provided, so remediation should be based on vendor advisories for the specific distribution kernel or storage product in use. If immediate patching is not possible, restrict access to NVMe/TCP target ports to trusted initiator IP addresses only, block exposure from untrusted networks, disable the nvmet_tcp module or NVMe/TCP target service where not required, and consider disabling data digest features if vendor guidance confirms that as a safe mitigation. Reboot into the patched kernel after installation, because kernel fixes are not effective while still running the vulnerable kernel image.

How to confirm the fix worked

Confirm whether the system is acting as an NVMe/TCP target by checking for the nvmet_tcp module, NVMe target configuration, and listening NVMe/TCP ports such as TCP/4420. Validate that the running kernel, not merely the installed kernel package, is at a vendor-fixed level. Check `uname -r`, package manager kernel versions, and vendor security advisory references. Confirm the vulnerable module is not loaded on systems that do not need NVMe/TCP target functionality. Network-validate that NVMe/TCP target ports are reachable only from authorized initiators. After patching and rebooting, monitor kernel logs during NVMe/TCP traffic and error handling for absence of refcount underflow, use-after-free, nvmet-tcp digest error crashes, or workqueue lockup messages.

Typical attack path

1. Scan for Linux systems exposing NVMe-over-TCP target services, commonly TCP/4420.
2. Confirm that the service is an NVMe/TCP target rather than an initiator-only system.
3. Open an NVMe/TCP connection and send crafted or malformed command traffic that causes request initialization to fail.
4. Trigger a data digest mismatch in the affected receive path.
5. Cause the vulnerable kernel to call request cleanup on a request that was never fully initialized.
6. Repeat as needed until kernel warnings, refcount underflow, use-after-free diagnostics, workqueue deadlock, or service outage occurs.

How to detect it

Look for evidence of attempted or successful exploitation in kernel logs and system journals on Linux hosts running NVMe-over-TCP target services. Relevant sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `dmesg`, crash dump directories, kdump/vmcore records, audit or EDR telemetry for module loading, and network flow logs for TCP/4420 or custom NVMe/TCP ports. Investigate kernel messages mentioning nvmet-tcp receive digest errors, data digest mismatches, refcount underflow, percpu_ref warnings, use-after-free diagnostics, RCU warnings, hung workqueues, or blocked kernel worker threads. Correlate timestamps with inbound NVMe/TCP connections from unknown or unauthorized IP addresses, bursts of failed NVMe/TCP sessions, or repeated short-lived connections. Successful exploitation may leave no user-space process artifact beyond kernel warnings, storage service interruption, hung I/O, soft lockup messages, or the need for a reboot.

• nvmet_tcp_try_recv_ddgst
• nvmet_req_uninit
• nvmet_tcp_handle_req_failure
• NVMET_TCP_F_INIT_FAILED
• percpu_ref_switch_to_atomic_rcu
• percpu_ref_put
• refcount underflow
• use-after-free
• WARNING: CPU
• workqueue deadlock
• hung task
• blocked for more than
• soft lockup
• hard lockup
• nvmet-tcp
• nvmet_tcp
• data digest mismatch
• ddgst
• TCP/4420

What your security team should do

• Identify all Linux systems running NVMe-over-TCP target services and prioritize internet-facing or broadly reachable storage targets.
• Patch affected systems using vendor kernel updates and reboot into the fixed kernel as soon as operationally feasible.
• Until patched, restrict TCP/4420 and any custom NVMe/TCP target ports to known trusted initiators with host firewalls, network ACLs, or storage fabric segmentation.
• Disable the nvmet_tcp module or NVMe/TCP target service on systems where it is not required.
• Review kernel logs for refcount underflow, use-after-free, workqueue deadlock, and nvmet-tcp digest error messages since the vulnerability publication date.
• Add monitoring for unexpected NVMe/TCP connection attempts, malformed sessions, digest mismatch errors, and repeated connects from unknown sources.
• Ensure storage failover and recovery procedures are tested for systems that provide critical NVMe/TCP-backed services.