CVE-2026-64535

What it actually does

This is a Linux kernel memory-safety flaw in the NVMe/TCP target implementation, specifically the nvmet-tcp handling of data-digest failures during R2T-based host-to-controller data transfers. When data digest is enabled and a digest mismatch occurs on a non-final H2C_DATA PDU, the error path can call nvmet_req_uninit() without marking the command as completed. During later queue teardown, the same request can be treated as still active and uninitialized a second time, causing a double percpu_ref_put against a single reference acquisition. The practical result is kernel reference-count corruption that can lead to use-after-free conditions, kernel memory corruption, service crash, or potentially broader compromise of the kernel depending on exploitability and runtime protections.

Why it matters to the business

Organizations exposing Linux NVMe/TCP target services may be vulnerable to unauthenticated network-triggered kernel instability or compromise. A successful attack could crash storage targets, interrupt block-storage access for dependent systems, corrupt I/O operations, or in a worst case enable attacker control at kernel privilege. Although current exploit maturity is reported as none, the issue has a critical CVSS score, requires no credentials or user interaction, and affects a kernel network storage path, so exposed NVMe/TCP targets should be treated as high-priority assets for patching or isolation.

How an attack unfolds

An attacker first identifies a Linux system acting as an NVMe/TCP target, typically reachable on the NVMe/TCP service port, and determines that data digest support is enabled or negotiable. The attacker establishes an NVMe/TCP connection and initiates an R2T-based data transfer that causes the target to expect H2C_DATA PDUs from the host. During a non-final data PDU, the attacker deliberately sends payload data with an invalid data digest. The target’s digest mismatch handler tears down part of the request state by calling nvmet_req_uninit(), but the command is not marked as completed or failed. The connection then enters fatal error handling and queue teardown. During teardown, the kernel scans outstanding commands, sees the partially uninitialized command as still needing data, and calls nvmet_req_uninit() again. That second release corrupts the underlying per-CPU reference accounting and can trigger a use-after-free or related kernel memory corruption condition. The most likely observable outcome is a kernel warning, oops, panic, or storage target outage, though kernel memory corruption bugs may have higher impact if an attacker can reliably shape memory state.

How to fix it

Apply the Linux kernel fix from the relevant upstream stable branch or distribution vendor as soon as it is available for the affected kernel line. Because no exact fixed package versions were provided, remediation should be tracked through the operating system or appliance vendor’s kernel advisory for this issue. Prioritize systems running the NVMe/TCP target stack, especially those with the nvmet-tcp module loaded and reachable from untrusted or broad networks. If immediate patching is not possible, reduce exposure by disabling the NVMe/TCP target service where not required, unloading or preventing use of the nvmet-tcp module, restricting access to NVMe/TCP listener ports to trusted initiators only, and disabling NVMe/TCP data digest if operationally acceptable and confirmed to avoid the vulnerable path. Network segmentation and strict allow-listing should be used as compensating controls, but they do not replace patching.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version includes the vendor’s fix for the nvmet-tcp digest mismatch request-lifecycle bug, not merely that an updated package is installed but not booted. Check whether the system is acting as an NVMe/TCP target by reviewing loaded modules, kernel config, nvmet configfs entries, active listeners, and exposure of the NVMe/TCP service port. Validate that nvmet-tcp is no longer reachable from untrusted networks, or that only approved initiator addresses can connect. Where a vendor-provided test or kernel selftest is available, use it in a non-production environment to confirm that malformed data-digest failures no longer produce kernel warnings, reference-count anomalies, oopses, or target-service disruption. Avoid reproducing malformed NVMe/TCP traffic against production storage targets because testing may crash the kernel or interrupt I/O.

Typical attack path

1. Discover an exposed Linux NVMe/TCP target service, commonly associated with TCP port 4420.
2. Establish an NVMe/TCP session with the target without needing local access or user interaction.
3. Negotiate or use a configuration where NVMe/TCP data digest is enabled.
4. Start an R2T-based host-to-controller data transfer that requires one or more H2C_DATA PDUs.
5. Send a non-final H2C_DATA PDU with an intentionally incorrect data digest.
6. Trigger the digest error path that uninitializes the request without marking it completed.
7. Allow or force fatal connection teardown so outstanding commands are processed again.
8. Cause a second uninitialization of the same request, leading to reference-count corruption, use-after-free, kernel crash, or possible further exploitation.

How to detect it

Look for evidence in kernel logs, system journals, crash dumps, and network telemetry from Linux systems acting as NVMe/TCP targets. Relevant log sources include journald, /var/log/kern.log, /var/log/messages, dmesg output, kdump/vmcore analysis, storage service monitoring, firewall logs, and packet captures for NVMe/TCP traffic. Investigate unexpected kernel oopses, panics, soft lockups, KASAN/KFENCE reports, refcount warnings, or storage target resets that occur shortly after NVMe/TCP connection errors or data digest mismatches. Network-level signs include repeated NVMe/TCP connections followed by malformed H2C_DATA PDUs, invalid data digest failures, abrupt queue teardown, or bursts of connections from unusual initiator addresses. Because exploit maturity is currently reported as none and no public exploit indicators are provided, detection should focus on behavioral evidence: malformed NVMe/TCP sessions, digest mismatch errors, and kernel crash artifacts containing nvmet-tcp request teardown functions. For confirmed or suspected incidents, preserve kernel logs, vmcore/kdump artifacts, module lists, active nvmet configuration, firewall connection records, and any packet capture around TCP port 4420.

• nvmet_tcp_try_recv_ddgst
• nvmet_tcp_uninit_data_in_cmds
• nvmet_req_uninit
• percpu_ref_put
• nvmet_tcp
• H2C_DATA
• data digest mismatch
• digest mismatch
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• kernel BUG
• Oops:
• general protection fault
• refcount_t: underflow
• TCP port 4420

What your security team should do

• Inventory Linux systems and appliances that provide NVMe/TCP target functionality, including systems with the nvmet-tcp kernel module loaded or NVMe target configfs entries configured.
• Prioritize patching internet-exposed, cross-zone, or broadly reachable NVMe/TCP targets before internal-only lab or isolated systems.
• If a fixed kernel is not yet available, restrict TCP access to NVMe/TCP services, commonly port 4420, to explicitly trusted initiators only.
• Disable unused NVMe/TCP target services and remove unnecessary nvmet-tcp module loading from boot configuration.
• Review whether NVMe/TCP data digest is enabled and consider disabling it as a temporary mitigation if supported and acceptable for the environment.
• Monitor kernel logs for nvmet-tcp errors, digest mismatch messages, refcount warnings, use-after-free reports, kernel oopses, and unexpected reboots on storage targets.
• Treat crashes of NVMe/TCP targets following malformed or unusual initiator activity as potential exploitation attempts, not only reliability incidents.
• Track vendor advisories for exact fixed kernel versions and ensure systems are rebooted into the fixed kernel after package installation.