Linux kernel - NVMe-oF target discovery controller, drivers/nvme/target/discovery.c: TENANT ISOLATION: The discovery

Impact

TENANT ISOLATION: 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