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@xxxxxxxxxxxxxxx
> Assisted-by: Codex:gpt-5-5-xhigh
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Michael Bommarito <michael.bommarito@xxxxxxxxx>
> ---
> 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@xxxxxxxxxx>

Cheers,

Hannes
--
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@xxxxxxx                                +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