From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 28F95378D9B for ; Sun, 12 Jul 2026 22:11:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783894272; cv=none; b=Cp+2Wek5YWb0NeJ8oB91GYmmxCBhoIpu84EowScHm2y8Zwa2wFcLN99ou7C3HPOk4kgmuVr1RHUhzudW6NwAha3wpta3HLhSqTOniDzHUCb0h7YLOdQl6c3667mlbR4DTxUUKrsE0sY0DHMFLg5JhhiKtPyxPG9CKSC0snI4XIw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783894272; c=relaxed/simple; bh=mSHhgudUQjIkYcPrOKVqo5OpwMNYZVu7ci9DPWYMnvk=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=YsxUS4/tPpIiQATCkswqPRtAabWXR3bKQKsw+BRiXs893IUI9q1fZK/UE90Tu5Frc0t4FV5Z1wJZ/KnUmHghN0jKwraTgJB6HEKAWVzvCDxcRvGPz42LkYI1470UZu2edS2jCs+FMHodpsoHVnp6F7SQ8jkz6tuAmYyGujV4JHs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BThuzO7s; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BThuzO7s" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7A0531F000E9; Sun, 12 Jul 2026 22:11:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783894270; bh=qnmJVIEOTFrWPGMd2cyWkD9DwcXDnFOaazp0NRQ+wTk=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=BThuzO7sU+m4Pw96+6x2ezkaGfFCGcXfnWUoZCNEG9UIHFKD7IYZLzHKHk0KFXlNT 2M9hPGGViSbQf4qVmJmz2utpw2M5sEVNmkgR/Lw/taXy6ti0Dwj36LVEwrLPMAu7jt iZZrZptMS1uiV2TzBtY8zaHu9S3Mr1zck2cdnuSJzlicEHSK2dkTtL9fzVUexWqGf4 WLHj6GEh0ygHaq+vaPtwX9z5LU3dHXKybpcV3E+VgGVFblYBfLYtJaHekL3633nC5m YglcpCAvooFjLkxG3l/r5UsyUc6KcCxGMBwhKe/8JMEB3p9vSqIDDMmj89j//06na+ 7KnBjFeK2TSjg== From: sashiko-bot@kernel.org Subject: Re: [PATCHv2 1/2] dmaengine: idma64: use kzalloc_flex Reply-To: sashiko-reviews@lists.linux.dev To: "Rosen Penev" Cc: Frank.Li@kernel.org, vkoul@kernel.org, dmaengine@vger.kernel.org In-Reply-To: <20260712220039.924958-2-rosenp@gmail.com> References: <20260712220039.924958-1-rosenp@gmail.com> <20260712220039.924958-2-rosenp@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Jul 2026 22:11:10 +0000 Message-Id: <20260712221110.7A0531F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: dmaengine@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: Pre-existing issues: - [High] If `idma64_prep_slave_sg()` is called with `sg_len =3D=3D 0`, it e= ventually calls `idma64_desc_fill()` which accesses `desc->hw[UINT_MAX]`, c= ausing a kernel panic. -- --- Patch [1]: [PATCHv2 1/2] dmaengine: idma64: use kzalloc_flex --- commit 54aec29a1bbe69497782adf915ba6169fd73e345 Author: Rosen Penev dmaengine: idma64: use kzalloc_flex This commit refactors the idma64_desc and idma64 structures to use flexible array members. It simplifies allocations by using kzalloc_flex and adds __counted_by annotations for runtime bounds checking. > diff --git a/drivers/dma/idma64.c b/drivers/dma/idma64.c > index 5fcd1befc92da..d914f50ec3096 100644 > --- a/drivers/dma/idma64.c > +++ b/drivers/dma/idma64.c [ ... ] > @@ -307,10 +289,12 @@ static struct dma_async_tx_descriptor *idma64_prep_= slave_sg( > struct scatterlist *sg; > unsigned int i; > =20 > - desc =3D idma64_alloc_desc(sg_len); > + desc =3D kzalloc_flex(*desc, hw, sg_len, GFP_NOWAIT); > if (!desc) > return NULL; > =20 > + desc->ndesc =3D sg_len; > + [Severity: High] This is a pre-existing issue, but can this lead to an out-of-bounds access if idma64_prep_slave_sg() is called with sg_len =3D=3D 0? If sg_len is 0, desc->ndesc is set to 0 and the for_each_sg() loop is bypassed. The function then calls idma64_desc_fill() which does the following: drivers/dma/idma64.c:idma64_desc_fill() { ... unsigned int i =3D desc->ndesc; struct idma64_hw_desc *hw =3D &desc->hw[i - 1]; ... } Since i is 0, i - 1 underflows to UINT_MAX, causing an out-of-bounds access on the hw flex array. With the new __counted_by bounds check, this will likely trigger a panic immediately. > for_each_sg(sgl, sg, sg_len, i) { > struct idma64_hw_desc *hw =3D &desc->hw[i]; > --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260712220039.9249= 58-2-rosenp@gmail.com?part=3D1