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

["Tianchu Chen" <tianchu.chen@linux.dev>]

June 1, 2026 at 3:19 PM, "Christoph Hellwig" <hch@lst.de mailto:hch@lst.de?to=%22Christoph%20Hellwig%22%20%3Chch%40lst.de%3E > wrote:


> 
> 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.
>

Thanks for the review.

I think the current patch doesn't actually allows overflow.

hl is a __u8 and dhvlen is a __le16. So the maximum value of
sizeof(*data) + 2 * (size_t)data->hl + dhvlen
is 66061, which is far below SIZE_MAX. It can't wrap.

About rewritting using struct_size: we still need to check
tl >= struct_size(data, rval, 0) first, which is exactly the same
as just using sizeof(*data) in current patch. Because we have to
confirm the header is fully present before we can even read
hl / dhvlen, which are the values that determine the minimum
required rval[] length.

So I believe the current patch already achieves the intended
goal of validating the payload against the buffer size,
using struct_size won't change the behavior.

That said, I'm happy to send a v2 that uses struct_size(data, rval, 0)
as the header anchor and then peels off the variable parts 
with checked subtractions, if you prefer that style:

size_t size = struct_size(data, rval, 0); /* check the header is fully present */
if (tl < size)
	return NVME_AUTH_DHCHAP_FAILURE_INCORRECT_PAYLOAD;
tl -= size;
/* rval[] carries: response (hl) + challenge (hl) + DH value (dhvlen) */
if (tl < 2 * (u32)data->hl)
	return NVME_AUTH_DHCHAP_FAILURE_INCORRECT_PAYLOAD;
tl -= 2 * (u32)data->hl;
dhvlen = le16_to_cpu(data->dhvlen);
if (tl < dhvlen)
	return NVME_AUTH_DHCHAP_FAILURE_INCORRECT_PAYLOAD;

Which one do you prefer? Just let me know which you'd prefer and I can send 
a v2 if needed.


Best regards,
Tianchu