← All Advisories
Reported from OT-Advisories.com as of

CVE-2026-64320

Last refreshed2026-10-17

Status: UPDATED  |  Advisory ID: CVE-2026-64320

Key Details

CVECVE-2026-64320
CVSS Score / Version
9.1 (Critical) / CVSS v3.1
Updated2026-10-16
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
CVSS Prose
attack vector is network; attack complexity is low; privileges required is none; user interaction is none; scope is unchanged; confidentiality impact is high; integrity impact is none; availability impact is high.
Affected products
Linux Kernel
Classified as
CWE-125 (Out-of-bounds Read)

Affected Products, Subsystems & Sectors

VendorProductAffected VersionsPatch Status
LinuxLinux Kernel
SubsystemsOT Supporting Infrastructure
SectorsAll Sectors

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References

SourceReference
NVDhttps://nvd.nist.gov/vuln/detail/CVE-2026-64320
CVEhttps://www.cve.org/CVERecord?id=CVE-2026-64320
Report compilation © 2026 OT-Advisories.com  ·  CC BY 4.0  ·  Source materials remain the property of their respective publishers as cited.