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

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

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

nvmetexecutediscgetlogpage() 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 nvmetcopytosgl(), which memcpy()s datalen bytes out to the host with no source-side bound check:

u64 offset = nvmetgetlogpageoffset(req->cmd); / 64-bit host / sizet datalen = nvmetgetlogpagelen(req->cmd); / 32-bit host / ... if (offset & 0x3) { ... } / only check / ... alloclen = sizeof(hdr) + entrysize discoverylogentries(req); buffer = kzalloc(alloclen, GFPKERNEL); ... status = nvmetcopytosgl(req, 0, buffer + offset, datalen);

The Discovery controller is unauthenticated -- nvmethostallowed() 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 == alloclen 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 paniconoops=1) the target host instead.

The attacker-controlled source-side offset pattern "nvmetcopytosgl(req, 0, buffer + ATTACKEROFFSET, ...)" is unique to nvmetexecutediscgetlogpage 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 nvmetexecutegetlogchangedns() (admin-cmd.c) and prevents leaking transport SGL contents when the host asks for more bytes than the log page contains.