GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel nvmet: unvalidated transfer length and halen/dhlen cause heap out-of-bounds read in CHAP negotiate

CVSS 9.1CVE-2026-90230Kernel, userspace & hypervisorcurated

Impact

nvmet_execute_auth_send() sizes the DH-HMAC-CHAP message buffer from the host-supplied transfer length but never passes that length down, so nvmet_auth_negotiate() walks halen hash ids and dhlen DH group ids - both u8, up to 255 - into a fixed 60-entry idlist and off the end of the allocation. A connecting initiator controls every one of those values, and the read happens during authentication, before the host has proved anything. On a storage node fronting an NVMe-oF fabric that is any machine allowed to connect to the target: a KASAN-visible heap over-read, usable to crash the target or to probe adjacent heap contents. Losing the target takes the fabric's clients with it, which is why this is scored for availability as well as confidentiality.

Who can reach it

Any host that can open an NVMe-oF connection to the nvmet target and begin DH-HMAC-CHAP authentication. No valid credentials needed - the flaw is reached before authentication completes. Nodes with no NVMe-oF target configured are not exposed.

What to do

Pick up a stable kernel containing the fix - it passes tl into nvmet_auth_negotiate(), rejects a tl that does not cover the negotiate data plus one full protocol descriptor, and rejects halen/dhlen above NVME_AUTH_DHCHAP_MAX_DH_IDS. That means drain and reboot each target node onto the patched kernel. Until then, limit which initiators can reach the target port; the commits are linked in the record for backporting.

References

Related entries

All Kernel, userspace & hypervisor entries

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.