In the Linux kernel, the following vulnerability has been resolved: nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page… (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 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.
AI Analysis
Technical Summary
The Linux kernel's nvmet_execute_disc_get_log_page() function improperly validates the host-supplied 64-bit Log Page Offset, only checking for dword alignment but not ensuring it is within the allocated buffer size. This leads to an out-of-bounds heap read when the offset plus requested data length exceeds the discovery log page buffer. Since the discovery controller is unauthenticated, any remote peer with network access to the nvmet target can trigger this pre-authentication. An attacker can leak kernel memory contents, including kernel pointers, or cause kernel crashes by referencing unmapped memory. The fix involves validating the offset against the log page size, limiting the copy length to available data, and zero-filling any remaining bytes to prevent leakage of transport scatter-gather list contents.
Potential Impact
An unauthenticated remote attacker with network access to the nvmet target can exploit this vulnerability to read out-of-bounds kernel memory, potentially leaking sensitive kernel pointers and other data. Additionally, crafted requests can cause kernel crashes or panics, leading to denial of service. There is no indication of code execution or privilege escalation from the provided data.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vulnerability has been resolved in the Linux kernel by validating the host-supplied offset against the log page size, capping the copy length, and zero-filling the remainder of the transfer buffer. Users should apply the official Linux kernel updates once available to address this issue. Until patched, restricting network access to nvmet targets and disabling the discovery controller if not needed may reduce exposure.
In the Linux kernel, the following vulnerability has been resolved: nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page… (CVE-2026-64320)
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.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel's nvmet_execute_disc_get_log_page() function improperly validates the host-supplied 64-bit Log Page Offset, only checking for dword alignment but not ensuring it is within the allocated buffer size. This leads to an out-of-bounds heap read when the offset plus requested data length exceeds the discovery log page buffer. Since the discovery controller is unauthenticated, any remote peer with network access to the nvmet target can trigger this pre-authentication. An attacker can leak kernel memory contents, including kernel pointers, or cause kernel crashes by referencing unmapped memory. The fix involves validating the offset against the log page size, limiting the copy length to available data, and zero-filling any remaining bytes to prevent leakage of transport scatter-gather list contents.
Potential Impact
An unauthenticated remote attacker with network access to the nvmet target can exploit this vulnerability to read out-of-bounds kernel memory, potentially leaking sensitive kernel pointers and other data. Additionally, crafted requests can cause kernel crashes or panics, leading to denial of service. There is no indication of code execution or privilege escalation from the provided data.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vulnerability has been resolved in the Linux kernel by validating the host-supplied offset against the log page size, capping the copy length, and zero-filling the remainder of the transfer buffer. Users should apply the official Linux kernel updates once available to address this issue. Until patched, restricting network access to nvmet targets and disabling the discovery controller if not needed may reduce exposure.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-qw96-j6m6-f3qh
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64320"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a65420d9c2644c7f80856b6
Added to database: 07/25/2026, 23:09:01 UTC
Last enriched: 07/25/2026, 23:34:32 UTC
Last updated: 09/07/2026, 10:52:10 UTC
Views: 51
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.