CVE-2026-64321

What it actually does

This vulnerability is a reference-count leak in the Linux kernel NVMe over Fabrics RDMA target path. When nvmet_rdma_queue_connect() obtains an NVMe target RDMA device reference via nvmet_rdma_find_get_device(), and the connection is rejected because the host queue backlog is exceeded, the error path returns NVME_SC_CONNECT_CTRL_BUSY without releasing the device reference. Repeated triggering can leak kernel object references, preventing cleanup of the affected nvmet_rdma device object and potentially causing kernel memory/resource exhaustion over time. This is best characterized as a denial-of-service condition rather than memory corruption enabling code execution.

Why it matters to the business

Systems exposing Linux NVMe-oF RDMA target functionality could become unstable or consume increasing kernel resources if repeatedly hit with connection attempts that exceed the queue backlog. The likely operational consequence is degraded storage service availability, failed NVMe/RDMA connections, or a need to reboot/reload kernel components to recover leaked resources. The currently reported EPSS is very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so broad Internet-scale exploitation is not currently indicated; however, storage infrastructure outages can be high impact where NVMe-oF RDMA is used for critical workloads.

How an attack unfolds

An attacker must be able to reach an NVMe-oF RDMA target service and initiate RDMA-based NVMe connection attempts. By repeatedly opening queue connections in a way that causes the target-side host queue backlog limit to be exceeded, the vulnerable kernel path returns a busy status before releasing the device reference acquired during lookup. Each failed connection on this path leaks a reference. Over many attempts, this can accumulate unreleased kernel references and associated resources, eventually degrading the target host’s ability to clean up devices or maintain service availability. There is no indication from the provided data that this flaw allows privilege escalation, data theft, or arbitrary code execution.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the NVMe target RDMA reference leak in nvmet_rdma_queue_connect(). The fix ensures the ndev reference obtained by nvmet_rdma_find_get_device() is released on the NVME_SC_CONNECT_CTRL_BUSY path. Because no specific affected product list or fixed package versions were provided, use the kernel packages supplied by the relevant Linux distribution or vendor advisory and confirm that the patch for this CVE or the corresponding nvmet RDMA refcount-leak commit is included. If immediate patching is not possible, reduce exposure by disabling NVMe-oF RDMA target functionality where not required, restricting RDMA/NVMe target access to trusted hosts only, applying network ACLs or fabric-level controls, and monitoring or rate-limiting excessive connection attempts where supported.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version includes the vendor fix for this CVE or the upstream change that routes the backlog-exceeded path through the existing device-release cleanup label. Operationally, validate that NVMe-oF RDMA targets continue to accept expected connections and that repeated rejected connection attempts no longer cause persistent reference/resource growth. Check whether the nvmet_rdma module is loaded, whether NVMe target RDMA ports/subsystems are configured, and whether RDMA-facing services are reachable only from intended initiators. If a patched test environment is available, reproduce high connection churn against the NVMe/RDMA target and monitor kernel memory, nvmet_rdma object lifecycle behavior, and system logs for sustained resource growth or instability.

Typical attack path

1. Identify a Linux system exposing NVMe over Fabrics using the RDMA transport as a target.
2. Establish network/RDMA reachability to the NVMe-oF target service.
3. Generate repeated NVMe/RDMA queue connection attempts against the target.
4. Drive the target into the host queue backlog exceeded condition so connection attempts return controller busy.
5. Repeat the condition to accumulate leaked nvmet RDMA device references.
6. Cause resource exhaustion, degraded NVMe target behavior, failed connections, or operational instability.

How to detect it

To assess possible prior exploitation or abuse, review Linux kernel logs, system journals, NVMe target logs, RDMA subsystem logs, and network/RDMA telemetry for repeated connection failures or busy responses involving NVMe-oF RDMA targets. Focus on unusual volumes of connection attempts from a small set of initiators, bursts of failed queue connections, increasing kernel memory or unreclaimable resources over time, and service degradation without corresponding legitimate workload growth. Useful log sources include journalctl/kern.log/messages, dmesg, audit logs if module or config changes are audited, RDMA fabric telemetry, switch logs, host firewall logs, and NVMe target configuration/activity records under configfs. There are no unique attacker payload strings for this flaw; detection is primarily behavioral, based on repeated NVMe/RDMA connect attempts and resource growth on vulnerable targets.

• nvmet_rdma
• nvmet
• NVME_SC_CONNECT_CTRL_BUSY
• CONNECT_CTRL_BUSY
• controller busy
• queue connect
• host queue backlog
• rdma_cm
• ib_cm
• nvme-rdma
• /sys/kernel/config/nvmet
• /sys/module/nvmet_rdma
• kernel: nvmet_rdma
• kernel: nvmet

What your security team should do

• Prioritize patching Linux hosts that act as NVMe-oF RDMA targets, especially storage nodes supporting production or latency-sensitive workloads.
• Inventory systems with the nvmet_rdma kernel module loaded or NVMe target RDMA subsystems configured.
• Restrict NVMe/RDMA target reachability to authorized initiators using network segmentation, RDMA fabric controls, host firewalls, and switch ACLs.
• Monitor for abnormal spikes in NVMe/RDMA connection attempts, controller-busy responses, or repeated queue connection failures.
• Because this is not currently in CISA KEV and has low EPSS, handle through normal kernel patch cycles unless the organization exposes NVMe-oF RDMA to untrusted or high-churn networks.
• Prepare operational recovery procedures for affected storage targets, including controlled service restart, module reload where safe, or host reboot if resource leakage causes instability.