Description
In the Linux kernel, the following vulnerability has been resolved:

nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page

nvmet_execute_disc_get_log_page() validates only the dword alignment
of the host-supplied Log Page Offset (lpo). The 64-bit offset is then
added to a small kzalloc'd buffer that holds the discovery log page
and the result is passed straight to nvmet_copy_to_sgl(), which
memcpy()s data_len bytes out to the host with no source-side bound
check:

u64 offset = nvmet_get_log_page_offset(req->cmd); /* 64-bit host */
size_t data_len = nvmet_get_log_page_len(req->cmd); /* 32-bit host */
...
if (offset & 0x3) { ... } /* only check */
...
alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);
buffer = kzalloc(alloc_len, GFP_KERNEL);
...
status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);

The Discovery controller is unauthenticated -- nvmet_host_allowed()
returns true unconditionally for the discovery subsystem -- so the call
is reachable pre-authentication by any TCP/RDMA/FC peer that can reach
the nvmet target. With a discovery log page of ~1 KiB, an attacker
requesting up to 4 KiB starting at offset == alloc_len reads the next
slab page out and gets its content returned over the fabric (an
empirical run on a default nvmet-tcp loopback target leaked 81
canonical kernel pointers in one Get Log Page response). Pointing the
offset at unmapped kernel memory faults the in-kernel memcpy and
crashes (or panics, on panic_on_oops=1) the target host instead.

The attacker-controlled source-side offset pattern
"nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique
to nvmet_execute_disc_get_log_page in the entire nvmet codebase: every
other Get Log Page handler in admin-cmd.c either ignores lpo (and
silently starts every response at offset 0) or tracks a local
destination offset with a fixed source pointer.

Validate the host-supplied offset against the log page size, cap the
copy length to what is actually available, and zero-fill any remainder
of the host transfer buffer. The zero-fill matches the existing
short-response pattern in nvmet_execute_get_log_changed_ns()
(admin-cmd.c) and prevents leaking transport SGL contents when the
host asks for more bytes than the log page contains.
Published: 2026-07-25
Score: 9.1 Critical
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The flaw lies in the nvmet discovery subsystem of the Linux kernel, where the command that fetches a log page does not fully validate the offset supplied by the host. Only a basic dword alignment check is performed; the offset is added to a small buffer and then copied to a scatter‑gather list without ensuring the copy stays within the allocated heap. An unauthenticated client can therefore instruct the target to read bytes beyond the buffer, leaking kernel addresses and, if the offset points outside mapped memory, causing a kernel panic or crash. The immediate consequence is loss of confidentiality for kernel state and a denial‑of‑service by crashing the nvmet target.

Affected Systems

All Linux kernel builds that contain the nvmet discovery feature and have not applied the patch referenced in the linked commit list are affected. No specific version range is enumerated, so any kernel—including the default packaging in most distributions—might be vulnerable until the fix is integrated.

Risk and Exploitability

The attack can be carried out over any traffic that can reach the nvmet target (TCP, RDMA, or Fibre Channel) and does not require prior authentication; the discovery subsystem allows all hosts by default. The attacker sends a Get Log Page request with a crafted offset and length to read kernel memory or crash the target. The CVSS score of 9.1 classifies the flaw as critical, reflecting the high potential impact. The EPSS score is below 1 % and the vulnerability is not currently listed in the CISA KEV catalog, indicating low observed exploit activity, but the potential impact of exposing kernel pointers or causing a crash warrants immediate remediation.

Generated by OpenCVE AI on August 3, 2026 at 19:15 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest kernel patch that incorporates the nvmet discovery fix from the commit links (e.g., upgrade to a recent kernel version or back‑port the changes).
  • Disable or limit exposure of the nvmet discovery service so that only trusted hosts can issue Get Log Page requests (for example, block or firewall the default discovery port 6650/tcp from untrusted networks).
  • Monitor network traffic for unusual Get Log Page requests with out‑of‑bounds offsets and set alerts for potential exploitation attempts.

Generated by OpenCVE AI on August 3, 2026 at 19:15 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4724-1 linux-6.12 new package
History

Sat, 01 Aug 2026 02:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119

Thu, 30 Jul 2026 12:15:00 +0000


Mon, 27 Jul 2026 06:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119
CWE-125

Mon, 27 Jul 2026 05:15:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 9.1, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H'}


Sat, 25 Jul 2026 09:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page nvmet_execute_disc_get_log_page() validates only the dword alignment of the host-supplied Log Page Offset (lpo). The 64-bit offset is then added to a small kzalloc'd buffer that holds the discovery log page and the result is passed straight to nvmet_copy_to_sgl(), which memcpy()s data_len bytes out to the host with no source-side bound check: u64 offset = nvmet_get_log_page_offset(req->cmd); /* 64-bit host */ size_t data_len = nvmet_get_log_page_len(req->cmd); /* 32-bit host */ ... if (offset & 0x3) { ... } /* only check */ ... alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req); buffer = kzalloc(alloc_len, GFP_KERNEL); ... status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len); The Discovery controller is unauthenticated -- nvmet_host_allowed() returns true unconditionally for the discovery subsystem -- so the call is reachable pre-authentication by any TCP/RDMA/FC peer that can reach the nvmet target. With a discovery log page of ~1 KiB, an attacker requesting up to 4 KiB starting at offset == alloc_len reads the next slab page out and gets its content returned over the fabric (an empirical run on a default nvmet-tcp loopback target leaked 81 canonical kernel pointers in one Get Log Page response). Pointing the offset at unmapped kernel memory faults the in-kernel memcpy and crashes (or panics, on panic_on_oops=1) the target host instead. The attacker-controlled source-side offset pattern "nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique to nvmet_execute_disc_get_log_page in the entire nvmet codebase: every other Get Log Page handler in admin-cmd.c either ignores lpo (and silently starts every response at offset 0) or tracks a local destination offset with a fixed source pointer. Validate the host-supplied offset against the log page size, cap the copy length to what is actually available, and zero-fill any remainder of the host transfer buffer. The zero-fill matches the existing short-response pattern in nvmet_execute_get_log_changed_ns() (admin-cmd.c) and prevents leaking transport SGL contents when the host asks for more bytes than the log page contains.
Title nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-05T12:40:57.930Z

Reserved: 2026-07-19T15:36:31.780Z

Link: CVE-2026-64320

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-07-25T10:17:13.407

Modified: 2026-08-11T15:00:57.447

Link: CVE-2026-64320

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-07-25T00:00:00Z

Links: CVE-2026-64320 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-03T19:30:04Z

Weaknesses