From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA8EC34B437 for ; Mon, 1 Jun 2026 07:19:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780298366; cv=none; b=mY4crSwusYCpCRmJwwuMO9oJQC2MZDXoeqY0X6E2mDMUtErBOx7/PcFLB8LtuobVLK3ld3mJ1tHdleo6doqa28EMyNIVc4SK6sYeCJda/6ZPLAQ9MV0FHgXCA1g9+NNQ7CjRKWjntEP/aVYV3RxcSIb3/cxOJjJcQyVIO7obzz4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780298366; c=relaxed/simple; bh=aTem+/xlx22j+EE1S/nVXXZyFkm03lZDox44i/QkLj8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YFjPhwoxHv2o6Bdh0sPy0pTBK88jKvanB0x6ZjvHZsfCn7+Hj+RiEe9n39UYp/BwCcNbZ39/QQNbxHusPQkBHSvWsw3eyKPqqf5bR3MRdd92DMLLqNPaQ8/J4GsimpvihzxwQyeZA5zrrWDpKMJKQ4M4sg/F3zokWf3uL5o4VwA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de Received: by verein.lst.de (Postfix, from userid 2407) id 0F5DF68B05; Mon, 1 Jun 2026 09:19:22 +0200 (CEST) Date: Mon, 1 Jun 2026 09:19:21 +0200 From: Christoph Hellwig To: Tianchu Chen Cc: hare@suse.de, hch@lst.de, sagi@grimberg.me, kch@nvidia.com, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org Subject: Re: [PATCH] nvmet-auth: validate reply message payload bounds against transfer length Message-ID: <20260601071921.GB7582@lst.de> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) On Fri, May 29, 2026 at 02:18:39PM +0000, Tianchu Chen wrote: > From: Tianchu Chen > > 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 > --- > 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.