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 E7F67288520; Wed, 26 Nov 2025 07:18:15 +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=1764141496; cv=none; b=WSdf23T23y0nOFOVnH4RJLfWqinibqImc1m0smhjG+Md7JZ0+loE4pv1SBIRPeiZL2SNnjZEy8YSDUiE0yaZww11IKRNnH0KPWVMxM2Ibv6HkWeQZMx9IuPFNCEPBlN8B/SHX3PhlkTZJEYNALhzm8rEAypmQSsZJISXzk0eH+Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764141496; c=relaxed/simple; bh=J54BQzE98MnLEmIufEMpAJUCEWke/kqnYm1g3RjsywA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=N/9JyKlZoHb9TsL+jgCtAR8gVeP294zxYVuLIMI9Zqi53DMujIAhqgFqC/jPdcwrs2UPXgfr5nSXw6FIeiRZu1HEoAfgN7mS9d1X2/nmaYos8jTkP+bj9dQFwx2OdWBZVF8RQEudTXzQw485RmQZVoM30ms2lFmcma0xo4De49c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CEIH1fQ+; 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="CEIH1fQ+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F3AFC113D0; Wed, 26 Nov 2025 07:18:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764141495; bh=J54BQzE98MnLEmIufEMpAJUCEWke/kqnYm1g3RjsywA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CEIH1fQ+ckjTqqcxiqglnl5IKzNcGbjRaLe4CTHvzENXvhzB85inuGiTMqk/X69M8 aHOb5kqCN12pqzddIJGfE0O0ujFznYma5w7QqAMwEPAjgqNMu8UcRn/Ketobwd48q0 8uqN2OoJv+thDRULWMny0kS504gyhFki8qeXoP1aXRRiU9Dz6ro9XTKIXnYZ9WL463 D9JeIdZT2cMFWsi7DYdUUN2OLkN2tsz1Dm5+6h2sCwrP7U3+KmjrdqiDUzdW+Q3n0b 2eQWFuoNPrs1jWBpt/ipKqhBABnIZ/E30cx+3yGshUz6/bV7qme5G227l42d0prK5l XHBESUpn/IPEw== Date: Wed, 26 Nov 2025 09:18:10 +0200 From: Leon Romanovsky To: Alex Mastro Cc: Sumit Semwal , Christian =?iso-8859-1?Q?K=F6nig?= , Alex Williamson , Jason Gunthorpe , Kevin Tian , Nicolin Chen , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Ankit Agrawal Subject: Re: [PATCH] dma-buf: fix integer overflow in fill_sg_entry() for buffers >= 8GiB Message-ID: <20251126071810.GF12483@unreal> References: <20251125-dma-buf-overflow-v1-1-b70ea1e6c4ba@fb.com> Precedence: bulk X-Mailing-List: linux-media@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: <20251125-dma-buf-overflow-v1-1-b70ea1e6c4ba@fb.com> On Tue, Nov 25, 2025 at 05:11:18PM -0800, Alex Mastro wrote: > fill_sg_entry() splits large DMA buffers into multiple scatter-gather > entries, each holding up to UINT_MAX bytes. When calculating the DMA > address for entries beyond the second one, the expression (i * UINT_MAX) > causes integer overflow due to 32-bit arithmetic. > > This manifests when the input arg length >= 8 GiB results in looping for > i >= 2. > > Fix by casting i to dma_addr_t before multiplication. > > Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") > Signed-off-by: Alex Mastro > --- > More color about how I discovered this in [1] for the commit at [2]: > > [1] https://lore.kernel.org/all/aSZHO6otK0Heh+Qj@devgpu015.cco6.facebook.com > [2] https://lore.kernel.org/all/20251120-dmabuf-vfio-v9-6-d7f71607f371@nvidia.com > --- > drivers/dma-buf/dma-buf-mapping.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Thanks, Reviewed-by: Leon Romanovsky