In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.

A use-after-free flaw was found in the Linux kernel's NVMe-over-Fabrics TCP target (nvmet-tcp) driver. When NVMe/TCP data digest is enabled and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based write transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit(), which drops a percpu_ref reference on the submission queue without marking the command as completed. During the subsequent queue teardown, the same command is treated as still needing data and nvmet_req_uninit() is called a second time, resulting in a double percpu_ref_put against a single percpu_ref_get. This use-after-free and reference-count underflow can crash the kernel (denial of service) when a remote NVMe/TCP initiator triggers a digest mismatch against a host configured as an NVMe/TCP target.

This flaw is a use-after-free and reference-count underflow in the Linux kernel's NVMe-over-Fabrics TCP target driver (nvmet-tcp). When NVMe/TCP data digest is enabled and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based write transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit(), which drops a percpu_ref reference on the submission queue without marking the command as completed. During the subsequent queue teardown, the same command is still treated as needing data and nvmet_req_uninit() is called a second time, causing a double percpu_ref_put against a single percpu_ref_get. This can lead to a use-after-free and crash the kernel (denial of service). This flaw is only reachable on systems that have been explicitly and manually configured to act as an NVMe-over-Fabrics TCP target (nvmet-tcp), for example by using the nvmetcli tool to export local block devices as an NVMe subsystem over a TCP network. Red Hat does not support the NVMe Target (nvmet) functionality in Red Hat Enterprise Linux; nvmet-tcp shipped as Technology Preview starting in RHEL 7.6 and continues to ship as Unmaintained in RHEL 8 and RHEL 9 and later. The NVMe/TCP host/initiator driver (nvme_tcp), which is fully supported for connecting to external NVMe/TCP storage, does not contain the affected code path and is not impacted by this issue. Systems that have not explicitly configured themselves as an NVMe/TCP target are not exposed to this vulnerability. Red Hat Enterprise Linux 6 does not ship any NVMe-over-Fabrics support (host or target) and is not affected. Red Hat Enterprise Linux 7's Technology Preview nvmet-tcp module is frozen at an older upstream baseline that predates the vulnerable code path introduced by this flaw, so RHEL 7 is also not affected, consistent with Red Hat's disposition on two prior nvmet-tcp vulnerabilities (CVE-2026-22998, CVE-2026-46135). Exploitation requires the attacking NVMe/TCP initiator to already have network access to a deliberately configured, unsupported NVMe/TCP target, which is typically reachable only from the same storage or data-center network segment rather than from the public Internet. Accordingly, the attack vector has been scored as Adjacent (AV:A) rather than Network (AV:N), consistent with Red Hat's CVSS treatment of the two prior nvmet-tcp CVEs referenced above. There is no mitigation for this issue other than applying the kernel update once available. Because Red Hat does not support and does not enable the nvmet-tcp target functionality by default, systems that have not been explicitly configured with nvmetcli to act as an NVMe-over-Fabrics TCP target are not exposed and require no immediate action. Administrators who have deliberately configured an NVMe/TCP target using this unsupported functionality should restrict network access to the target port to trusted initiators on the same storage network only, and should consider disabling NVMe/TCP data digest or migrating off nvmet-tcp given its unmaintained status, until the fix is applied. Red Hat Enterprise Linux 10 Fix deferred kernel Red Hat Enterprise Linux 10 Not affected libkrun Red Hat Enterprise Linux 6 Not affected kernel Red Hat Enterprise Linux 7 Not affected kernel Red Hat Enterprise Linux 7 Not affected kernel-rt Red Hat Enterprise Linux 8 Fix deferred kernel Red Hat Enterprise Linux 8 Fix deferred kernel-rt Red Hat Enterprise Linux 9 Fix deferred kernel Red Hat Enterprise Linux 9 Fix deferred kernel-rt Red Hat Enterprise Linux for NVIDIA 26 Fix deferred kernel Red Hat Hardened Images Not affected erlang27 Red Hat OpenShift Container Platform 4 Fix deferred openshift/ose-rhel-coreos-8 Red Hat OpenShift Container Platform 4 Fix deferred openshift/ose-rhel-coreos-9 https://www.cve.org/CVERecord?id=CVE-2026-64535 https://nvd.nist.gov/vuln/detail/CVE-2026-64535 https://git.kernel.org/stable/c/088ee46c18d99baef453afd74181dd40ade044ad https://git.kernel.org/stable/c/6f9442983a3e4227afd1c83a5251ddbca585ea21 https://git.kernel.org/stable/c/96fe2513df590e74b04253a45089cae75569570e https://git.kernel.org/stable/c/dbbd07d0a7020b80f6a7028e561908f7b83b3d5a https://git.kernel.org/stable/c/e091ff83d962f9ed00d9bd70443676de9fe98bdc