[PATCH v2] nvmet-auth: reject short AUTH_RECEIVE buffers

[PATCH v2] nvmet-auth: reject short AUTH_RECEIVE buffers

[Michael Bommarito]

nvmet_execute_auth_receive() trusts the AUTH_RECEIVE 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 nvmet_auth_success1() and
nvmet_auth_failure1() 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
nvmet_auth_receive_data_len() and report a zero data length when the
host-supplied allocation length is shorter, so the existing zero-length
check in nvmet_execute_auth_receive() rejects the command before any
builder runs. The SUCCESS1 minimum is sizeof(struct
nvmf_auth_dhchap_success1_data) 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 nvmet_auth_challenge().

This is reachable only when in-band DH-HMAC-CHAP authentication is
configured on the target.

Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5-5-xhigh
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
v2:
  - Move the length check into nvmet_auth_receive_data_len() and reject
    via the existing zero-length guard in nvmet_execute_auth_receive(),
    per Hannes Reinecke's review. No separate helper, and
    nvmet_execute_auth_receive() itself is unchanged.

With CONFIG_FORTIFY_SOURCE and KASAN enabled, a short al (for example
al=1) on the SUCCESS1 path aborts in the sizeof(*data)=16 header memset
in nvmet_auth_success1() with "memset: detected buffer overflow: 16 byte
write of buffer size 1". After this change the same input is rejected
before allocation and the abort no longer occurs. Validated with a
KUnit/KASAN harness under UML: the stock kernel crashed and the patched
kernel passed; the in-tree nvme-auth KUnit suite still passes.
---
 drivers/nvme/target/fabrics-cmd-auth.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/target/fabrics-cmd-auth.c b/drivers/nvme/target/fabrics-cmd-auth.c
index f1e613e7c63e5..d4271fc43a95c 100644
--- a/drivers/nvme/target/fabrics-cmd-auth.c
+++ b/drivers/nvme/target/fabrics-cmd-auth.c
@@ -484,7 +484,31 @@ static void nvmet_auth_failure1(struct nvmet_req *req, void *d, int al)
 
 u32 nvmet_auth_receive_data_len(struct nvmet_req *req)
 {
-	return le32_to_cpu(req->cmd->auth_receive.al);
+	struct nvmet_ctrl *ctrl = req->sq->ctrl;
+	u32 al = le32_to_cpu(req->cmd->auth_receive.al);
+	u32 min_len;
+
+	/*
+	 * Reject too-short al before kmalloc(al), since the SUCCESS1 and
+	 * FAILURE1/default builders write fixed response headers into it.
+	 */
+	switch (req->sq->dhchap_step) {
+	case NVME_AUTH_DHCHAP_MESSAGE_CHALLENGE:
+		return al;
+	case NVME_AUTH_DHCHAP_MESSAGE_SUCCESS1:
+		min_len = sizeof(struct nvmf_auth_dhchap_success1_data);
+		if (req->sq->dhchap_c2)
+			min_len += nvme_auth_hmac_hash_len(ctrl->shash_id);
+		break;
+	default:
+		min_len = sizeof(struct nvmf_auth_dhchap_failure_data);
+		break;
+	}
+
+	if (al < min_len)
+		return 0;
+
+	return al;
 }
 
 void nvmet_execute_auth_receive(struct nvmet_req *req)
-- 
2.53.0

Re: [PATCH v2] nvmet-auth: reject short AUTH_RECEIVE buffers

[Hannes Reinecke]

On 6/9/26 20:24, Michael Bommarito wrote:
> nvmet_execute_auth_receive() trusts the AUTH_RECEIVE 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 nvmet_auth_success1() and
> nvmet_auth_failure1() 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
> nvmet_auth_receive_data_len() and report a zero data length when the
> host-supplied allocation length is shorter, so the existing zero-length
> check in nvmet_execute_auth_receive() rejects the command before any
> builder runs. The SUCCESS1 minimum is sizeof(struct
> nvmf_auth_dhchap_success1_data) 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 nvmet_auth_challenge().
> 
> This is reachable only when in-band DH-HMAC-CHAP authentication is
> configured on the target.
> 
> Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication")
> Cc: stable@vger.kernel.org
> Assisted-by: Codex:gpt-5-5-xhigh
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> ---
> v2:
>    - Move the length check into nvmet_auth_receive_data_len() and reject
>      via the existing zero-length guard in nvmet_execute_auth_receive(),
>      per Hannes Reinecke's review. No separate helper, and
>      nvmet_execute_auth_receive() itself is unchanged.
> 
> With CONFIG_FORTIFY_SOURCE and KASAN enabled, a short al (for example
> al=1) on the SUCCESS1 path aborts in the sizeof(*data)=16 header memset
> in nvmet_auth_success1() with "memset: detected buffer overflow: 16 byte
> write of buffer size 1". After this change the same input is rejected
> before allocation and the abort no longer occurs. Validated with a
> KUnit/KASAN harness under UML: the stock kernel crashed and the patched
> kernel passed; the in-tree nvme-auth KUnit suite still passes.
> ---
>   drivers/nvme/target/fabrics-cmd-auth.c | 26 +++++++++++++++++++++++++-
>   1 file changed, 25 insertions(+), 1 deletion(-)
> 
Reviewed-by: Hannes Reinecke <hare@kernel.org>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

Re: [PATCH v2] nvmet-auth: reject short AUTH_RECEIVE buffers

[Keith Busch]

On Tue, Jun 09, 2026 at 02:24:31PM -0400, Michael Bommarito wrote:
> nvmet_execute_auth_receive() trusts the AUTH_RECEIVE 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 nvmet_auth_success1() and
> nvmet_auth_failure1() write past the allocation; both only WARN_ON the
> short length and then format the message anyway.

Thanks, applied to nvme-7.2.