CVE-2026-64320: Linux Kernel Information Disclosure Bug

CVE-2026-64320 Overview

CVE-2026-64320 is an out-of-bounds heap read vulnerability in the Linux kernel's NVMe-oF target (nvmet) subsystem. The flaw resides in nvmet_execute_disc_get_log_page(), which validates only dword alignment of the host-supplied Log Page Offset (lpo) before adding the 64-bit offset to a small kzalloc'd buffer. The result is passed to nvmet_copy_to_sgl() without any source-side bounds check. The Discovery controller is unauthenticated, so any TCP, RDMA, or Fibre Channel peer that can reach the target can trigger the read pre-authentication.

Critical Impact
An unauthenticated remote attacker can leak adjacent kernel heap memory, including canonical kernel pointers, or crash the target host by pointing the offset at unmapped memory.

Affected Products

Linux kernel nvmet (NVMe-oF target) subsystem
NVMe-oF transports: TCP, RDMA, Fibre Channel
Systems exposing an nvmet Discovery controller to untrusted peers

Discovery Timeline

2026-07-25 - CVE-2026-64320 published to NVD
2026-07-27 - Last updated in NVD database

Technical Details for CVE-2026-64320

Vulnerability Analysis

The vulnerability lives in the NVMe-oF Discovery Get Log Page handler. nvmet_execute_disc_get_log_page() reads a 64-bit offset from nvmet_get_log_page_offset(req->cmd) and a 32-bit data_len from nvmet_get_log_page_len(req->cmd). The only check performed on offset is if (offset & 0x3), which verifies dword alignment.

The handler then allocates a small buffer sized to hold the discovery log page: alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req). It calls nvmet_copy_to_sgl(req, 0, buffer + offset, data_len), which invokes memcpy() on buffer + offset for data_len bytes with no upper bound. According to the commit message, a discovery log page of roughly 1 KiB combined with a 4 KiB read starting at offset == alloc_len leaked 81 canonical kernel pointers from the adjacent slab page in a single response on a default nvmet-tcp loopback target.

Root Cause

The root cause is missing validation of an attacker-controlled offset against the source buffer length. Every other Get Log Page handler in admin-cmd.c either ignores lpo or tracks a local destination offset with a fixed source pointer. Only nvmet_execute_disc_get_log_page() applied the untrusted offset directly to the source pointer of a memcpy().

Attack Vector

The attack is network-reachable and pre-authentication. nvmet_host_allowed() returns true unconditionally for the discovery subsystem, so any peer able to establish an NVMe-oF connection to the target can issue a crafted Get Log Page command. Setting lpo beyond the allocated buffer length triggers an out-of-bounds read that streams adjacent kernel heap contents back to the attacker over the fabric. Pointing the offset at unmapped kernel memory faults the in-kernel memcpy() and causes an oops, or a full panic when panic_on_oops=1 is set.

The vulnerability mechanism is described in the upstream commit message. See the kernel git commit reference for the applied fix.

Detection Methods for CVE-2026-64320

Indicators of Compromise

Unexpected NVMe-oF Get Log Page (opcode 0x02) requests targeting the Discovery Log Page (LID 0x70) with large lpo values approaching or exceeding the advertised log page size.
Kernel oops or panic entries in dmesg originating from nvmet_copy_to_sgl or nvmet_execute_disc_get_log_page.
NVMe-oF responses to discovery clients that exceed the expected discovery log page length.

Detection Strategies

Inspect NVMe-oF TCP traffic (default port 4420) for Get Log Page admin commands with non-zero Log Page Offset fields against the Discovery controller.
Alert on kernel crashes referencing nvmet modules, particularly on hosts acting as NVMe-oF targets.
Baseline discovery traffic; legitimate initiators typically request the full log page starting at offset 0.

Monitoring Recommendations

Enable kernel audit and crash reporting on nvmet target hosts and forward dmesg to a central log store.
Monitor exposure of TCP 4420 and RDMA endpoints to networks outside the storage fabric.
Track loaded kernel modules (nvmet, nvmet_tcp, nvmet_rdma, nvmet_fc) across the fleet to identify systems in scope.

How to Mitigate CVE-2026-64320

Immediate Actions Required

Apply the upstream kernel patch or the stable-tree backport from your distribution as soon as vendor packages are available.
Restrict network reachability to nvmet Discovery controllers to trusted storage-fabric peers only using firewall or VLAN segmentation.
If nvmet is not required, unload the nvmet, nvmet_tcp, nvmet_rdma, and nvmet_fc modules and blacklist them.

Patch Information

The fix validates the host-supplied offset against the log page size, caps the copy length to what is actually available, and zero-fills any remainder of the host transfer buffer. The zero-fill matches the existing short-response pattern in nvmet_execute_get_log_changed_ns(). Stable-tree commits include 33b974eb6261, 53cd102a7a56, 56c021a08692, and a29b316b9bbf.

Workarounds

Limit NVMe-oF target exposure to a dedicated, isolated storage network and drop discovery traffic from untrusted sources at the perimeter.
Disable the NVMe-oF Discovery subsystem on hosts that do not require dynamic discovery by removing the discovery configfs entries.
Set panic_on_oops=0 to prevent an attacker-triggered fault from producing a full host panic while patches are staged.

bash

# Disable and blacklist nvmet modules where NVMe-oF target is not required
sudo modprobe -r nvmet_tcp nvmet_rdma nvmet_fc nvmet
echo 'blacklist nvmet'      | sudo tee /etc/modprobe.d/blacklist-nvmet.conf
echo 'blacklist nvmet_tcp'  | sudo tee -a /etc/modprobe.d/blacklist-nvmet.conf
echo 'blacklist nvmet_rdma' | sudo tee -a /etc/modprobe.d/blacklist-nvmet.conf
echo 'blacklist nvmet_fc'   | sudo tee -a /etc/modprobe.d/blacklist-nvmet.conf

# Restrict NVMe-oF TCP discovery to trusted storage subnets only
sudo iptables -A INPUT -p tcp --dport 4420 -s 10.20.30.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 4420 -j DROP