Linux kernel - NVMe-oF target configfs, drivers/nvme/target/configfs.c: Nvmet_root_discovery_nqn_store() treated the

CVSS 6.7CVE-2024-53681Kernel, userspace & hypervisornvmet subsysnqn overflowNVMe-oF discovery NQN buffer handlingcurated

Impact

Nvmet_root_discovery_nqn_store() treated the subsystem NQN string as a fixed-size buffer even though it is dynamically allocated to the length of the existing string, so writing a longer discovery NQN overflows the allocation. The direct exposure is local to whoever administers the target's configfs, but in an operator context that includes storage orchestration and CSI drivers running with elevated privileges - so a compromised control-plane component turns a configuration write into kernel memory corruption on the node holding every tenant's namespaces. It also matters because NQN handling is exactly the surface an attacker probes when attempting NQN spoofing.

Who can reach it

Write an over-long NQN string to the discovery subsystem's configfs attribute on the target. Requires privileged access to the target host's configfs, which orchestration and storage-management agents routinely have. Not remotely reachable on its own, but a natural second stage after compromising a storage control-plane component.

What to do

Host reboot / kernel upgrade on nvmet target nodes; fold into the same window as the other nvmet findings rather than scheduling separately. Config-side hardening that pays off regardless: keep the target's configfs off any path an untrusted orchestration component can reach, and audit which service accounts can write nvmet configuration.

References

https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-53681.json https://nvd.nist.gov/vuln/detail/CVE-2024-53681

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.