CVE-2026-64319

What it actually does

This flaw is a pre-authentication out-of-bounds heap read in the Linux kernel NVMe over Fabrics target authentication path. When DH-HMAC-CHAP authentication is enabled, nvmet_auth_reply() trusts attacker-controlled hash-length and Diffie-Hellman value-length fields in a DHCHAP_REPLY message without first confirming that those variable-length fields fit inside the received transfer buffer. A malicious NVMe-oF initiator can send a short transfer with oversized length fields, causing the kernel to read beyond the allocated message buffer while processing the DH public key or comparing the host response. The impact is primarily information disclosure from kernel heap memory and potential denial of service through invalid memory access or kernel fault conditions.

Why it matters to the business

Organizations exposing Linux-based NVMe-oF targets with DHCHAP authentication may face unauthorized disclosure of sensitive kernel memory or storage-service instability before an initiator is authenticated. Because exploitation is network-reachable, requires no credentials, and affects kernel code, vulnerable storage infrastructure could experience crashes, degraded availability, or leakage of information that helps an attacker advance later attacks. The issue is not currently listed in CISA KEV and the provided EPSS score is low, but the high CVSS score and pre-authentication attack surface make it important for environments using NVMe-oF targets.

How an attack unfolds

An attacker first identifies a reachable Linux NVMe-oF target that has authentication enabled. The attacker then behaves like an NVMe-oF initiator and begins the DHCHAP authentication exchange. During the reply phase, instead of sending a well-formed DHCHAP_REPLY payload, the attacker sends a message with a small transfer length but inflated hash-length or Diffie-Hellman value-length fields. The vulnerable kernel code calculates offsets into the variable-length response array using those attacker-controlled values and reads beyond the end of the received buffer. Depending on memory layout and kernel hardening, this can expose adjacent heap data during cryptographic processing or comparison operations, or trigger a kernel warning, fault, or service disruption. Exploitation occurs before successful authentication, so blocking untrusted initiators from reaching NVMe-oF target ports is an important compensating control.

How to fix it

Apply a Linux kernel update from the relevant OS or appliance vendor that includes the nvmet-auth bounds validation fix for DHCHAP_REPLY parsing. The corrected logic validates that sizeof(*data) + 2*hl + dhvlen is less than or equal to the received transfer length before accessing variable-length fields. If building kernels from source, apply or backport the upstream patch that adds this bounds check in the NVMe target authentication code. Where immediate patching is not possible, restrict NVMe-oF target access to trusted initiator IPs or fabrics, isolate storage networks, block untrusted access to NVMe-oF ports such as TCP 4420 where applicable, and consider disabling DHCHAP authentication only if doing so does not create a larger security exposure and access is otherwise tightly controlled.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix by checking the installed kernel package changelog, vendor advisory, or source tree for the added DHCHAP_REPLY payload bounds validation in the nvmet authentication code. Verify that vulnerable NVMe-oF targets are no longer exposed to untrusted networks and that fabric access controls only allow expected initiators. On systems with test authorization, run a controlled negative test using malformed DHCHAP_REPLY traffic and confirm the target rejects the message without kernel warnings, crashes, KASAN reports, or authentication-path faults. Review kernel logs after validation for absence of out-of-bounds read reports, general protection faults, slab errors, or nvmet-auth warnings.

Typical attack path

1. Scan for reachable NVMe-oF target services, commonly over TCP or RDMA.
2. Confirm that the target supports or requires DHCHAP authentication.
3. Initiate an NVMe-oF connection as an unauthenticated initiator.
4. Send a crafted DHCHAP_REPLY message with inconsistent transfer length and oversized hl and/or dhvlen fields.
5. Trigger out-of-bounds heap reads in the kernel nvmet-auth handling path.
6. Use the resulting behavior for kernel memory disclosure, target instability, or denial of service.

How to detect it

Look for signs of attempted malformed NVMe-oF authentication and kernel memory-safety failures. Useful sources include kernel ring buffer logs, persistent system journal logs, storage target logs, NVMe target tracepoints if enabled, firewall or flow logs for NVMe-oF ports, and crash dumps. Search for kernel warnings or faults involving nvmet_auth_reply, nvmet-auth, DHCHAP, sg_init_one, crypto_kpp_compute_shared_secret, KASAN out-of-bounds reads, slab out-of-bounds reads, or general protection faults around failed NVMe authentication attempts. Network telemetry may show unauthenticated hosts repeatedly connecting to NVMe-oF target endpoints, especially TCP port 4420, followed by failed authentication or abrupt disconnects. Because this bug may not produce a clean application-level log entry, absence of logs does not prove non-exploitation; prioritize correlation of unusual initiator activity with kernel warnings, target resets, service interruptions, or crash dumps.

• nvmet_auth_reply
• nvmet-auth
• DHCHAP_REPLY
• DHCHAP
• crypto_kpp_compute_shared_secret
• sg_init_one
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: KASAN
• general protection fault
• nvmet
• nvme target
• port 4420

What your security team should do

• Inventory Linux systems acting as NVMe-oF targets and identify those with DHCHAP authentication enabled.
• Prioritize kernel updates for internet-exposed, cross-zone, multi-tenant, or otherwise untrusted NVMe-oF target deployments.
• Restrict NVMe-oF target reachability to approved initiators using network ACLs, firewalls, storage-fabric zoning, or host-based filtering.
• Monitor kernel logs and storage authentication logs for crashes, warnings, repeated failed DHCHAP negotiation, or malformed initiator behavior.
• If patching is delayed, isolate the storage fabric and block untrusted traffic to NVMe-oF target ports, especially TCP 4420 where NVMe/TCP is used.
• Coordinate patch windows carefully because kernel updates usually require rebooting storage hosts or failing workloads over to redundant paths.
• Track vendor advisories for exact fixed kernel package versions for the distributions and appliances in use.