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 624AA39D6DD for ; Tue, 19 May 2026 13:48:43 +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=1779198523; cv=none; b=qittxYUoOMafelq4BE16B277vVcREyna1WmDVT/Yc5eWC1LzDW0u9aLA6hFz8he5Fpyt+FSSqAar4OgJeNmbpl4WmPKseR7YE780oG09vQktg7dwnOFAOckQpwy08/Ee8/sbs09LoAPn52aNcGRebp+7dXWnrzOGYrS0PTV/zGI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779198523; c=relaxed/simple; bh=3mTAX3gg7xWAAELRKrnbF7uZS0riBSLTv+e0FZknT68=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=Bxs1aTtvRi8JAZwE3bBks1PoQFeJj1pgfzNeHQMvBlnu7NaGjqR4Oi9mhTXADQofp57Ovy+DGm3iBduSFQBdLMkc2Y/wn82mL9UaqQsP5jxBgB/rD1+gQAO9uPIE/7saxNU1sJ5O70BzqMXBVUFYXe6VDKaG6VbhnfRoQ4V9uL0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Iylfxz3i; 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="Iylfxz3i" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7A6AC2BCB8; Tue, 19 May 2026 13:48:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779198523; bh=3mTAX3gg7xWAAELRKrnbF7uZS0riBSLTv+e0FZknT68=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From; b=Iylfxz3itJIAP69aqju9wKrPYpvcX+Ri1TpxalWbMu8O9OAOZhMrpiSp4b9DwT9Zi OiEkRrS9/9pvdmVzig3gFiEorSxCAnLOzqbBD8xvblmhOUDqOCNtx9ZC8iihLgzDuv UwEijRPHn3WIxYNKcftME0jh8xzVjrjlRUNFFVVgim9u006Myp72gAoqTK15/+EGji D+lILdiWv1NKKenOxJjP2hMjPLXfyGOEUkQgMhlIAt/PENEwcQmDVCjWLkaPsxeHO2 kDq07ElUl78ql5J+9Jh8Ej+wC35qh6wR10xVzzEdS9A8YtaKpnz5zrscJWcm6Iqi1/ h8Fn54ryi/EzA== From: sashiko-bot@kernel.org Subject: Re: [PATCH v17 09/14] crypto: qce - Remove unused ignore_buf Reply-To: sashiko-reviews@lists.linux.dev To: "Bartosz Golaszewski" Cc: dmaengine@vger.kernel.org, vkoul@kernel.org, Frank.Li@kernel.org In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-9-53a595414b79@oss.qualcomm.com> References: <20260519-qcom-qce-cmd-descr-v17-9-53a595414b79@oss.qualcomm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 19 May 2026 13:48:42 +0000 Message-Id: <20260519134842.D7A6AC2BCB8@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 2 potential issue(= s) to consider: - [Critical] qce_dma_release() frees the DMA channels and result buffer wit= hout explicitly terminating in-flight background DMA operations. - [Critical] The surrounding error rollback loop in devm_qce_register_algs(= ) uses the wrong loop variable, leaking registered algorithms and causing s= ubsequent UAF. -- commit 86b6706b62fa03437f8e5e0bdb45e4e4d945b1d3 Author: Bartosz Golaszewski crypto: qce - Remove unused ignore_buf This commit removes the ignore_buf field from struct qce_dma_data and the assignment in devm_qce_dma_request() because it was unused. It also moves t= he QCE_IGNORE_BUF_SZ macro definition into dma.c since it is only used locally. > diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c > index 68cafd4741ad3..08bf3e8ec1243 100644 > --- a/drivers/crypto/qce/dma.c > +++ b/drivers/crypto/qce/dma.c > @@ -9,6 +9,8 @@ > =20 > #include "dma.h" > =20 > +#define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE) > + > static void qce_dma_release(void *data) > { > struct qce_dma_data *dma =3D data; While reviewing this code, I noticed a pre-existing regression in qce_dma_release(). When the driver is unbound, devres cleanup calls qce_dma_release(), which drops the DMA channel references via dma_release_channel() and then frees dma->result_buf. Since dma_release_channel() does not stop active DMA transfers, could the B= AM DMA engine continue to write data to the newly freed result_buf if a crypto request is in-flight? Would this lead to a use-after-free and memory corruption? Should the driver explicitly call dmaengine_terminate_sync() before releasi= ng the channels? [ ... ] I also noticed another pre-existing regression in devm_qce_register_algs() regarding the error rollback loop. When ops->register_algs(qce) fails at index i, the rollback loop correctly counts backward with j =3D i - 1, but it appears to fail to update the ops pointer to qce_ops[j]. Does this result in repeatedly calling unregister_algs() for the failed qce_ops[i] instead of the successfully registered algorithms? If probe fails and devres frees the device memory, is it possible these leaked algorithms pointing to freed memory cause a use-after-free when accessed by the crypto subsystem? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260519-qcom-qce-c= md-descr-v17-0-53a595414b79@oss.qualcomm.com?part=3D9