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

Greg Kroah-Hartman <[email protected]> Sat, 25 Jul 2026 10:48:57 +0200
Newsgroups org.kernel.vger.linux-cve-announce
Message-ID <2026072511-CVE-2026-64320-4b43@gregkh>
From: Greg Kroah-Hartman <[email protected]>

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.

The Linux kernel CVE team has assigned CVE-2026-64320 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.8 with commit a07b4970f464f13640e28e16dad6cfa33647cc99 and fixed in 6.12.96 with commit 33b974eb626154ae9348f2bac7de84cb2a3d9dd4
	Issue introduced in 4.8 with commit a07b4970f464f13640e28e16dad6cfa33647cc99 and fixed in 6.18.39 with commit 56c021a0869260d04c4b65d1471936aaf9177114
	Issue introduced in 4.8 with commit a07b4970f464f13640e28e16dad6cfa33647cc99 and fixed in 7.1.4 with commit a29b316b9bbfd269f323ab4ba9906a894025680f
	Issue introduced in 4.8 with commit a07b4970f464f13640e28e16dad6cfa33647cc99 and fixed in 7.2-rc1 with commit 53cd102a7a56079b11b897835bd9b94c14e6322c

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-64320
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/nvme/target/discovery.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/33b974eb626154ae9348f2bac7de84cb2a3d9dd4
	https://git.kernel.org/stable/c/56c021a0869260d04c4b65d1471936aaf9177114
	https://git.kernel.org/stable/c/a29b316b9bbfd269f323ab4ba9906a894025680f
	https://git.kernel.org/stable/c/53cd102a7a56079b11b897835bd9b94c14e6322c