CVE-2026-89975: nvme-fabrics: fix DHCHAP secret leak on parse failure
In the Linux kernel, the following vulnerability has been resolved:
nvme-fabrics: fix DHCHAP secret leak on parse failure
nvmfparseoptions() duplicates dhchapsecret and dhchapctrlsecret with matchstrdup() before validating the DHHC-1: representation.
If validation fails, the parser returns -EINVAL before the temporary string in p is assigned to opts->dhchapsecret or opts->dhchapctrlsecret. nvmfcreatectrl() subsequently frees opts, but nvmffreeoptions() cannot release the unassigned temporary string. Each rejected option therefore leaks one allocation.
This is easy to miss because valid secrets transfer ownership to opts and are freed normally, while the malformed-secret path still returns the expected -EINVAL to userspace.
With CONFIGNVMEHOSTAUTH enabled, the leak is reachable before the required-option checks and transport lookup. No NVMe-oF target or working transport connection is required; for example, repeatedly writing
dhchapsecret=BAD
or
dhchapctrlsecret=BAD
to /dev/nvme-fabrics deterministically takes the leaking parse path.
Free the temporary string before leaving both validation error paths. Use kfreesensitive() because the copied option may contain secret material even when its representation is rejected, matching the sensitive cleanup used for stored DHCHAP secrets.
Event History
Frequently Asked Questions
What systems are exposed to this leak?
Systems with CONFIG_NVME_HOST_AUTH enabled are exposed through the NVMe fabrics option parser. A reachable NVMe-oF target or a functioning transport connection is not required.
What does an attacker or local user need to trigger it?
They need to repeatedly submit malformed DHCHAP secret options, such as dhchap_secret=BAD or dhchap_ctrl_secret=BAD, to /dev/nvme-fabrics. Each rejected malformed option takes the leaking parse path while still returning -EINVAL.
How can administrators identify attempted or active exploitation?
Look for repeated failed writes to /dev/nvme-fabrics containing malformed dhchap_secret or dhchap_ctrl_secret values and returning -EINVAL. Repeated attempts can cause allocation growth because each rejected option leaks one temporary secret allocation.
What can be done before applying the fix?
Restrict access to /dev/nvme-fabrics and prevent untrusted users or processes from submitting NVMe fabrics connection options. In particular, block or avoid malformed DHCHAP secret inputs on systems built with CONFIG_NVME_HOST_AUTH enabled.