CVE-2026-72130

In the Linux kernel, the following vulnerability has been resolved:

nvmet-auth: reject short AUTH_RECEIVE buffers

nvmetexecuteauthreceive() trusts the AUTHRECEIVE allocation length

after checking only that it is nonzero and matches the transfer length.

In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF

initiator reach the fixed-size DH-HMAC-CHAP response builders with a

kmalloc() buffer shorter than the response, so nvmetauthsuccess1() and

nvmetauthfailure1() write past the allocation; both only WARN_ON the

short length and then format the message anyway.

Impact: A remote NVMe-oF initiator with access to an auth-enabled target

can trigger a 16-byte heap out-of-bounds write via a one-byte

AUTH_RECEIVE allocation length.

Compute the minimum response length for the current DH-HMAC-CHAP step in

nvmetauthreceivedatalen() and report a zero data length when the

host-supplied allocation length is shorter, so the existing zero-length

check in nvmetexecuteauth_receive() rejects the command before any

builder runs. The SUCCESS1 minimum is sizeof(struct

nvmfauthdhchapsuccess1data) plus the HMAC hash length, because the

response hash is written into the rval[] flexible-array tail, so the

minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its

existing variable-length guard in nvmetauthchallenge().

This is reachable only when in-band DH-HMAC-CHAP authentication is

configured on the target.