From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 C2C363859FF for ; Mon, 2 Feb 2026 17:18:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770052694; cv=none; b=VndEZGgynI2hOvCN/ScvHhPljU/90V3XXWVCx+BD8jvTrbo9DAkQn89jOgqKpIig/FB9Lnhj68THgvssEVxYgx4hIWxrWVulHzHENUYwbVm3LXEfPMeZSXgf7IJxi64DppiNcWTri+HrQTV2v3tejPoZzneeTt2NZ2pMEAXbRI8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770052694; c=relaxed/simple; bh=5ypc+EGOhkIew2b/AMpI7KYgHTEpZ4E9pgp6HK8Z4zI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AAKoTLubpIsK1zLYpQgL+nJ6+z/9Cx5ISyCI/LruGv6QaZ/1n4ATCmSVpGDJsrBoYXXLSPfbZRFzXxwygyLNQK9UzwGtMQa+0thGDFXy33zW8ji0IVoEeuTnWECZXSl3rifxukKv52VIic8Xyr1DHW37bn2OHkSL+c+4ziaBl5s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=drzNCPc9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="drzNCPc9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A003C116C6; Mon, 2 Feb 2026 17:18:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770052694; bh=5ypc+EGOhkIew2b/AMpI7KYgHTEpZ4E9pgp6HK8Z4zI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=drzNCPc9jZYc2bKVefwV/w98z5xfh8eUyMeV79r/hr4AC2/YYeW6KfUeS+ZGDI3w0 lPaaJIwfNxb1FqLXPliA8nfR35MdHgVJnvkSApk3xKsneF5q6JVBbiOgaNWwBs610N 1843qP+UgGjATvRt7HEDWLADWcf3l+ZMMA++cyi++B7/oYQyHdNu+DgNSmQL9FA4EC GPnV8hSvV/LZg0ID32nBOtFeP7JGd5PwUt/F9Clz8pvGPmqZC35hSxfhmeHrJBe1cP ti8ZLqTi2DpEh6wS0b/oIcqIU/bXHkPqnD5V1+PayPCjS4ieEq53MCr1yaQBZk62Am GfC/9KNAAcsXw== Date: Mon, 2 Feb 2026 10:18:12 -0700 From: Keith Busch To: Pradeep P V K Cc: axboe@kernel.dk, hch@lst.de, sagi@grimberg.me, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, nitin.rawat@oss.qualcomm.com Subject: Re: [PATCH V1] nvme-pci: Fix NULL pointer dereference in nvme_pci_prp_iter_next Message-ID: References: <20260202125738.1194899-1-pradeep.pragallapati@oss.qualcomm.com> 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: <20260202125738.1194899-1-pradeep.pragallapati@oss.qualcomm.com> On Mon, Feb 02, 2026 at 06:27:38PM +0530, Pradeep P V K wrote: > @@ -720,6 +720,7 @@ static void nvme_free_prps(struct request *req, unsigned int attrs) > dma_unmap_phys(nvmeq->dev->dev, iod->dma_vecs[i].addr, > iod->dma_vecs[i].len, rq_dma_dir(req), attrs); > mempool_free(iod->dma_vecs, nvmeq->dev->dmavec_mempool); > + iod->dma_vecs = NULL; > } > > static void nvme_free_sgls(struct request *req, struct nvme_sgl_desc *sge, > @@ -825,7 +826,7 @@ static bool nvme_pci_prp_iter_next(struct request *req, struct device *dma_dev, > return true; > if (!blk_rq_dma_map_iter_next(req, dma_dev, iter)) > return false; > - if (!dma_use_iova(&iod->dma_state) && dma_need_unmap(dma_dev)) { > + if (iod->dma_vecs && !dma_use_iova(&iod->dma_state) && dma_need_unmap(dma_dev)) { So the return of dma_need_unmap() may change after any call to dma_map_*? Does it only go from false -> true, and never back to false? Since we didn't allocate the dma_vecs here, doesn't that mean the completion side is leaking the mapping?