Linux kernel - NVMe-oF target DH-HMAC-CHAP authentication, drivers/nvme/target/fabrics-cmd-auth.c: Nvmet_auth_reply()

Impact

Nvmet_auth_reply() reads the variable-length array using attacker-supplied hash-length and DH-value-length fields without checking they fit the allocated transfer length. A malicious initiator sends a DHCHAP_REPLY with a small transfer length but large hl/dhvlen and drives out-of-bounds heap reads of up to 526 bytes past the buffer, with the out-of-bounds pointer handed straight to the crypto layer. The bitter irony for operators: this is in the authentication code you were told to turn on to fix NQN spoofing, and it is exploitable pre-authentication - so enabling in-band auth opens this surface rather than closing it. Still worth enabling auth, but only on a patched kernel.

Who can reach it

Any peer that can reach an auth-enabled NVMe-oF target sends a crafted DHCHAP_REPLY during the authentication exchange. By definition this happens before authentication completes, so no credentials are required. Discovered by an automated vulnerability-discovery engine, which suggests more of this class is coming in the same file.

What to do

Host reboot / kernel upgrade on NVMe-oF targets before or at the same time as enabling DH-HMAC-CHAP. If you have already enabled in-band auth on an unpatched kernel, prioritise the upgrade; disabling auth is not a good trade because it reopens NQN spoofing. Network-level control in the interim: restrict target ports to known initiator addresses. Sequence the rollout as patch first, then enable auth.

References