CVE-2026-64320

What it actually does

This is a pre-authentication out-of-bounds heap read in the Linux kernel NVMe-oF target discovery path. The vulnerable Discovery Get Log Page handler accepts a host-controlled 64-bit Log Page Offset and host-controlled transfer length, validates only 4-byte alignment, and then copies from `buffer + offset` back to the remote peer without verifying that the source range is inside the allocated discovery log buffer. A remote peer that can reach an NVMe target over TCP, RDMA, or Fibre Channel can read adjacent kernel heap memory, potentially exposing kernel pointers or sensitive in-kernel data. If the supplied offset points into unmapped kernel memory, the in-kernel copy can fault and crash or panic the target host.

Why it matters to the business

Systems acting as Linux NVMe-oF targets may expose kernel memory to any network or fabric peer that can reach the discovery controller, even before authentication or host authorization. The most likely business impacts are storage service disruption from kernel crashes and increased risk of follow-on exploitation if leaked kernel addresses or memory contents help bypass kernel hardening. The CVSS score is critical at 9.1 because exploitation is network-reachable, unauthenticated, low-complexity, and can affect both confidentiality and availability. EPSS is currently low and there is no known KEV listing or reported ransomware use, but the issue is only 16 days old and affects a high-value infrastructure role, so exposed NVMe-oF targets should still be prioritized.

How an attack unfolds

An attacker first identifies a Linux host exposing an NVMe-oF target discovery service over NVMe/TCP, NVMe/RDMA, or NVMe/FC. Because the discovery subsystem allows access before authentication, the attacker does not need valid credentials or an authorized host identity. The attacker connects as an NVMe host and sends a Discovery Get Log Page command with a Log Page Offset that is aligned but outside the allocated discovery log page buffer, along with a transfer length large enough to copy data beyond the end of that buffer. The kernel target code constructs the discovery log in a small heap allocation and then copies from the attacker-selected out-of-bounds source address into the response SGL, returning adjacent kernel heap contents to the attacker. By varying offsets and lengths, the attacker may collect kernel pointers or other memory fragments. If the attacker chooses an offset that resolves to invalid kernel memory, the copy path can trigger an oops or panic, causing denial of service on the storage target.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the fix for the NVMe target Discovery Get Log Page bounds check. Where exact package versions are not available, track vendor advisories for this CVE and update to the first fixed kernel release or later. The corrected implementation should validate the host-supplied offset against the discovery log page size, cap the copy length to available data, and zero-fill any remainder instead of copying from memory beyond the allocated buffer. Until patched, restrict access to NVMe-oF target fabrics: firewall or ACL NVMe/TCP exposure, especially port 4420; isolate RDMA storage networks; enforce Fibre Channel zoning; limit discovery access to trusted initiators; and disable the NVMe target service or discovery subsystem on systems that do not require it. Because exploitation can crash the kernel, schedule remediation with storage failover and maintenance procedures in mind.

How to confirm the fix worked

Confirm exposure by identifying systems with the Linux NVMe target stack enabled, such as loaded `nvmet`, `nvmet_tcp`, `nvmet_rdma`, or `nvmet_fc` modules and configured NVMe target subsystems under configfs. Confirm remediation by checking the installed kernel package against the vendor advisory for this vulnerability, or by verifying that the kernel source for `nvmet_execute_disc_get_log_page()` validates `lpo` against the allocated discovery log size and limits or zero-fills overlong responses. In a non-production lab, a patched target should safely handle an oversized but aligned Discovery Get Log Page offset without returning adjacent heap data and without triggering an oops or panic. For NVMe/TCP, also validate that untrusted networks cannot connect to the target discovery listener, commonly on TCP port 4420.

Typical attack path

1. Discover NVMe-oF target exposure over TCP, RDMA, or Fibre Channel; for NVMe/TCP, the default service port is commonly 4420.
2. Connect to the NVMe discovery subsystem as an unauthenticated NVMe host.
3. Issue a Discovery Get Log Page request with a 4-byte-aligned but out-of-range Log Page Offset.
4. Set a response length that causes the target to copy memory beyond the allocated discovery log page buffer.
5. Receive leaked kernel heap contents in the Get Log Page response, or intentionally choose invalid offsets to crash the target.
6. Use leaked kernel addresses or memory contents to aid further kernel exploitation, or repeat requests to create storage service instability.

How to detect it

Successful memory disclosure may not produce an application-level log entry, so detection should combine exposure review, network/fabric telemetry, and kernel crash analysis. Review kernel logs from `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, and crash dumps for oops, panic, page fault, or general protection fault traces containing NVMe target functions such as `nvmet_execute_disc_get_log_page` or `nvmet_copy_to_sgl`. For NVMe/TCP, inspect firewall, NetFlow, packet capture, and load balancer records for unexpected connections to the NVMe discovery service, commonly TCP/4420, especially from non-storage networks. For RDMA and Fibre Channel, review fabric controller, switch, zoning, and initiator login records for unfamiliar peers accessing discovery. If protocol-aware telemetry is available, alert on Discovery Get Log Page commands with a nonzero or unusually large Log Page Offset, offsets greater than the expected discovery log size, or repeated discovery log requests with varying offsets and large transfer lengths. Treat unexplained target kernel crashes temporally correlated with NVMe discovery traffic as suspicious. Because leaked data is returned inside normal NVMe command responses, packet captures or NVMe protocol logs are the most reliable way to confirm exploitation when no crash occurred.

• nvmet_execute_disc_get_log_page
• nvmet_copy_to_sgl
• nvmet_tcp
• nvmet_rdma
• nvmet_fc
• Discovery Get Log Page
• Log Page Offset
• Get Log Page
• TCP/4420
• port 4420
• BUG: kernel NULL pointer dereference
• Oops:
• general protection fault
• unable to handle page fault
• kernel panic
• /sys/kernel/config/nvmet
• /sys/kernel/config/nvmet/subsystems/nqn.2014-08.org.nvmexpress.discovery

What your security team should do

• Inventory Linux systems acting as NVMe-oF targets and prioritize any reachable over TCP, RDMA, or Fibre Channel from non-storage or less trusted networks.
• Patch affected Linux kernels as soon as vendor-fixed builds are available; treat internet- or enterprise-network-reachable NVMe/TCP targets as urgent despite currently low EPSS.
• Immediately restrict NVMe-oF discovery access to trusted initiators using firewalls, storage-network segmentation, RDMA isolation, and Fibre Channel zoning.
• Review kernel logs for oops, panic, page fault, or general protection fault events involving `nvmet_execute_disc_get_log_page` or `nvmet_copy_to_sgl`.
• Monitor NVMe/TCP connections, especially to port 4420, for unfamiliar initiator addresses or spikes in discovery commands.
• If suspicious access or crashes are observed, preserve kernel logs, storage fabric logs, packet captures if available, and volatile incident-response data before rebooting where operationally feasible.
• Disable NVMe target functionality on systems that do not explicitly require it.