CVE-2026-72130: nvmet-auth: reject short AUTH_RECEIVE buffers

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

nvmet-auth: reject short AUTHRECEIVE 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 WARNON 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 AUTHRECEIVE 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 nvmetexecuteauthreceive() 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.