Re: [PATCH] nvmet-auth: validate reply message payload bounds against transfer length

[Christoph Hellwig <hch@lst.de>]

On Fri, May 29, 2026 at 02:18:39PM +0000, Tianchu Chen wrote:
> From: Tianchu Chen <flynnnchen@tencent.com>
> 
> nvmet_auth_reply() accesses the variable-length rval[] array using
> attacker-controlled hl (hash length) and dhvlen (DH value length) fields
> without verifying they fit within the allocated buffer of tl bytes.
> 
> A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a
> small transfer length but large hl/dhvlen values, causing out-of-bounds
> heap reads when the target processes the DH public key (rval + 2*hl) or
> performs the host response memcmp.
> 
> With DH authentication configured, the OOB pointer is passed directly to
> sg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching
> up to 526 bytes past the buffer. This is exploitable pre-authentication.
> 
> Add bounds validation ensuring sizeof(*data) + 2*hl + dhvlen <= tl before
> any access to the variable-length fields.
> 
> Discovered by Atuin - Automated Vulnerability Discovery Engine.
> 
> Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
> ---
>  drivers/nvme/target/fabrics-cmd-auth.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/nvme/target/fabrics-cmd-auth.c b/drivers/nvme/target/fabrics-cmd-auth.c
> index f1e613e7c..0a85acf1e 100644
> --- a/drivers/nvme/target/fabrics-cmd-auth.c
> +++ b/drivers/nvme/target/fabrics-cmd-auth.c
> @@ -132,13 +132,22 @@ static u8 nvmet_auth_negotiate(struct nvmet_req *req, void *d)
>  	return 0;
>  }
>  
> -static u8 nvmet_auth_reply(struct nvmet_req *req, void *d)
> +static u8 nvmet_auth_reply(struct nvmet_req *req, void *d, u32 tl)
>  {
>  	struct nvmet_ctrl *ctrl = req->sq->ctrl;
>  	struct nvmf_auth_dhchap_reply_data *data = d;
> -	u16 dhvlen = le16_to_cpu(data->dhvlen);
> +	u16 dhvlen;
>  	u8 *response;
>  
> +	if (tl < sizeof(*data))
> +		return NVME_AUTH_DHCHAP_FAILURE_INCORRECT_PAYLOAD;
> +
> +	dhvlen = le16_to_cpu(data->dhvlen);
> +
> +	/* Validate that hl and dhvlen fit within the transfer length */
> +	if (sizeof(*data) + 2 * (size_t)data->hl + dhvlen > tl)

Can't still still overflow?  This should probably use struct_size
to get the size up to and including the rval array, then
use use checked subtractions from tl.