Database/Kernel, userspace & hypervisor
Linux kernel - NVMe-oF target discovery controller, drivers/nvme/target/discovery.c: The discovery controller validated
Impact
The discovery controller validated only the dword alignment of the host-supplied 64-bit Log Page Offset before adding it to a small heap buffer and memcpy'ing data straight back over the fabric. The discovery subsystem accepts every Host NQN and explicitly skips DH-HMAC-CHAP, so this is reachable pre-authentication by any TCP, RDMA, or FC peer that can see the target. The kernel CNA's own writeup reports an empirical run on a default nvmet-tcp target leaking 81 canonical kernel pointers in a single Get Log Page response; pointing the offset at unmapped memory panics the target instead. For a neocloud running disaggregated NVMe, one unauthenticated request from any tenant reads the storage node's kernel heap - and repeated requests crash the node serving everyone.
Who can reach it
Connect to the discovery controller (nvme discover, or a raw fabrics command) with any Host NQN and issue Get Log Page with an offset at or beyond the allocated discovery log length. No authentication, no valid identity, no prior connection. Works over NVMe/TCP on port 4420, over NVMe/RDMA, and over Fibre Channel. Purely a read primitive plus a crash primitive, but the leaked kernel pointers defeat KASLR and set up heavier exploitation.
What to do
Host reboot / kernel upgrade on every nvmet target - urgent, given pre-auth reachability and a 9.1 score. Immediate stopgaps while you schedule it: firewall NVMe/TCP 4420 and the RDMA discovery path to known initiator addresses, and move the discovery controller off any tenant-reachable interface onto a management network (nvmet configfs change, runtime, no reboot, but initiators need reconfiguring). Enabling DH-HMAC-CHAP does not help here because the discovery subsystem bypasses it by design - only the kernel fix or network isolation closes it.
References
Related entries
- perf tools: out-of-bounds heap read parsing a crafted perf.data CPU indexCVE-2026-80670 · Linux kernel perf tools (machine__resolve() CPU index from perf.data samples)Critical
- Linux NFSD: NFSv2 SETATTR reaches notify_change without a mount write referenceCVE-2026-89697 · Linux kernel NFSD (nfsd_proc_setattr, NFSv2 BOTH_TIME_SET path)Critical
- Linux NFSD: TOCTOU lets a SETATTR truncate an append-only fileCVE-2026-89713 · Linux kernel NFSD (nfsd_setattr ATTR_SIZE truncate permission check)Critical
- Linux kernel qla2xxx: unbounded rsp_info_len underflows sense length and leaks adjacent kernel memoryCVE-2026-89846 · Linux kernel scsi qla2xxx (FCP response rsp_info_len bound)Critical
- Linux kernel iSCSI target: login payload can fill the buffer with no NUL, so CHAP parsing reads past the slabCVE-2026-90011 · Linux kernel iSCSI target (login payload buffer, MAX_KEY_VALUE_PAIRS)Critical
- QEMU VGA device model (hw/display/vga.c) - banked access to video memory: 'Dark Portal' - the guest sets the VGA bankCVE-2016-3710 · QEMU VGA device model (hw/display/vga.c) - banked access to video memoryHigh
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.