| Message ID | 20260615091114.97190-1-pengpeng@iscas.ac.cn (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-23834-sunxi=pue.re@lists.linux.dev> X-Original-To: noreply@patchwork.local Delivered-To: noreply@patchwork.local Received: from sto.lore.kernel.org (sto.lore.kernel.org [172.232.135.74]) by mxe881.netcup.net (Postfix) with ESMTPS id 9C9461C0266 for <noreply@patchwork.local>; Mon, 15 Jun 2026 11:12:35 +0200 (CEST) Authentication-Results: mxe881; spf=pass (sender IP is 172.232.135.74) smtp.mailfrom=linux-sunxi+bounces-23834-noreply=patchwork.local@lists.linux.dev smtp.helo=sto.lore.kernel.org Received-SPF: pass (mxe881: domain of lists.linux.dev designates 172.232.135.74 as permitted sender) client-ip=172.232.135.74; envelope-from=linux-sunxi+bounces-23834-noreply=patchwork.local@lists.linux.dev; helo=sto.lore.kernel.org; Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sto.lore.kernel.org (Postfix) with ESMTP id 5DDE93009F6B for <noreply@patchwork.local>; Mon, 15 Jun 2026 09:12:00 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E17793D3333; Mon, 15 Jun 2026 09:11:27 +0000 (UTC) X-Original-To: linux-sunxi@lists.linux.dev Received: from cstnet.cn (smtp81.cstnet.cn [159.226.251.81]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 683A13D3D1C for <linux-sunxi@lists.linux.dev>; Mon, 15 Jun 2026 09:11:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.226.251.81 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781514687; cv=none; b=pB5yztAbCvIAXFasmyTe5E4dWVT0xgmsSc22M+j6Vc6IW8vVw/NwPIjdnEmyiHqgjpwEEsRh5qhduBlTk6eAbzse/CdyzX1ImlZdtuqn0lWQn9fjflFBhPFVzfs4JK02Q3DUaeg7MgPxYpBes//BF0moMAeoljle6LJ841Q5YnY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781514687; c=relaxed/simple; bh=NOZlCSEv3F8FwatBQ8BSA4difxWE5jFw5B7XM5Jh0/I=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=kxtkMcF+lTp6b5hNmSOHNKJZtF1bnEByLA95dtEQe2S00TXc0i1Fw1QfrpjewIWxqGBJqteKl1rigDAt+5VT0uq1/gUOkPAPnZTcUlWBYd/4BgghxJVcvbEM3GHuuvw1JG06M10AIzYExKGx14fr84PB7hoyeHOO/XGHb2Ozovc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iscas.ac.cn; spf=pass smtp.mailfrom=iscas.ac.cn; arc=none smtp.client-ip=159.226.251.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iscas.ac.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=iscas.ac.cn Received: from localhost.localdomain (unknown [111.196.245.140]) by APP-03 (Coremail) with SMTP id rQCowACXt96zwS9qdl7LFA--.28827S2; Mon, 15 Jun 2026 17:11:16 +0800 (CST) From: Pengpeng Hou <pengpeng@iscas.ac.cn> To: Corentin Labbe <clabbe.montjoie@gmail.com>, Herbert Xu <herbert@gondor.apana.org.au>, "David S. Miller" <davem@davemloft.net>, Chen-Yu Tsai <wens@kernel.org>, Jernej Skrabec <jernej.skrabec@gmail.com>, Samuel Holland <samuel@sholland.org>, linux-crypto@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org Cc: Pengpeng Hou <pengpeng@iscas.ac.cn> Subject: [PATCH] crypto: sun4i-ss: remove debugfs directory on teardown Date: Mon, 15 Jun 2026 17:11:13 +0800 Message-ID: <20260615091114.97190-1-pengpeng@iscas.ac.cn> X-Mailer: git-send-email 2.50.1 Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: <linux-sunxi.lists.linux.dev> List-Subscribe: <mailto:linux-sunxi+subscribe@lists.linux.dev> List-Unsubscribe: <mailto:linux-sunxi+unsubscribe@lists.linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: rQCowACXt96zwS9qdl7LFA--.28827S2 X-Coremail-Antispam: 1UD129KBjvdXoW7Xw4xCFW3Kry5WFWUCw1xZrb_yoWkWrc_ur WrWrn7JrW8Ar90va4fXry3ZFW0qrWrJry8u3WIvFW3ta47ZrWrWF1xur4ku345AF4DCF98 Z3yqvrsxZayj9jkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb3kFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8w A2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_ Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r106r15McIj6I8E87Iv67AKxVW8JVWxJwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8cxa n2IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4 AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE 17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMI IF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4l IxAIcVC2z280aVAFwI0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8Jr0_Cr1UYxBIda VFxhVjvjDU0xZFpf9x0JUQZ2fUUUUU= X-CM-SenderInfo: pshqw1xhqjqxpvfd2hldfou0/ X-MORS-Enabled: yes X-MORS-DOMAIN: patchwork.local X-MORS-HOSTING: hosting172546 X-MORS-USER: hosting172546 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= |
| Series |
crypto: sun4i-ss: remove debugfs directory on teardown
|
|
Commit Message
Pengpeng Hou
June 15, 2026, 9:11 a.m. UTC
sun4i_ss_probe() creates a debugfs directory and a stats file with struct
sun4i_ss_ctx as private data. The remove path unregisters the crypto
algorithms and tears down runtime PM but leaves the debugfs entries
published.
Remove the debugfs subtree before tearing down the driver state used by
the stats show callback.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c | 2 ++
1 file changed, 2 insertions(+)
Comments
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: Pre-existing issues: - [High] Device unbind frees the devm-managed driver context while active crypto TFMs remain, leading to a Use-After-Free. - [High] Global `ss_algs` array corruption upon multiple device probes or probe failures leaves dangling pointers, leading to a Use-After-Free. -- commit ca25dde45b1d1ec5234ada4c67bcfb9e055331e7 Author: Pengpeng Hou <pengpeng@iscas.ac.cn> crypto: sun4i-ss: remove debugfs directory on teardown This commit addresses a cleanup omission in the sun4i-ss driver where the debugfs directory and stats file were left published after the driver was unbound. It adds a recursive debugfs removal during driver teardown. > diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c > index 35ef0930e77f1..eadc5449b6807 100644 > --- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c > +++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c > @@ -479,6 +479,8 @@ static void sun4i_ss_remove(struct platform_device *pdev) > int i; > struct sun4i_ss_ctx *ss = platform_get_drvdata(pdev); > > + debugfs_remove_recursive(ss->dbgfs_dir); > + [Severity: High] This is a pre-existing issue, but does device unbind cause a use-after-free here? When the device is unbound via sysfs, sun4i_ss_remove() completes and devres automatically frees the devm-managed ss context and unmaps ss->base. However, unregistering the crypto algorithms only prevents new allocations. It does not destroy existing active TFMs. If an active TFM continues to operate, its context op->ss (which was copied from algt->ss during sun4i_ss_cipher_init()) becomes a dangling pointer. For example, a subsequent sun4i_ss_cipher_poll() call accessing the hardware: drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c:sun4i_ss_cipher_poll() ... writesl(ss->base + SS_RXFIFO, mi.addr + oi, todo); will access unmapped memory and the freed ss context. Additionally, when the TFM is eventually freed: drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c:sun4i_ss_cipher_exit() ... pm_runtime_put(op->ss->dev); it dereferences the already-freed op->ss. Can this be addressed by tracking active TFMs or ensuring they are quiesced before cleanup? > for (i = 0; i < ARRAY_SIZE(ss_algs); i++) { > switch (ss_algs[i].type) { > case CRYPTO_ALG_TYPE_SKCIPHER: [ ... ] [Severity: High] This is also a pre-existing issue, but is the driver context safely managed if probe fails or if multiple devices are probed? In sun4i_ss_probe(), the driver stores its per-device context pointer in the statically allocated global array ss_algs: drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c:sun4i_ss_probe() for (i = 0; i < ARRAY_SIZE(ss_algs); i++) { ss_algs[i].ss = ss; If a second device instance is probed, it overwrites ss_algs[0].ss with its newly allocated ss context. The registration then fails with -EEXIST because the first device already registered it, causing the second probe to abort and devres to free its ss context. However, ss_algs[0].ss remains pointing to this freed memory. When a new TFM is created for the still-active first device: drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c:sun4i_ss_cipher_init() op->ss = algt->ss; it copies the dangling pointer to op->ss, leading to a use-after-free when accessing op->ss->dev. Could this global array be changed to avoid storing per-device state?
diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c index 58a76e2ba64e..bcaddf1b83ca 100644 --- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c +++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c @@ -512,6 +512,8 @@ static void sun4i_ss_remove(struct platform_device *pdev) int i; struct sun4i_ss_ctx *ss = platform_get_drvdata(pdev); + debugfs_remove_recursive(ss->dbgfs_dir); + for (i = 0; i < ARRAY_SIZE(ss_algs); i++) { switch (ss_algs[i].type) { case CRYPTO_ALG_TYPE_SKCIPHER: