DEBIAN-CVE-2026-64320

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.