| Message ID | 20260808090121.2718855-1-lgs201920130244@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-25071-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 DFBD11C1486
for <noreply@patchwork.local>; Sat, 8 Aug 2026 11:01:48 +0200 (CEST)
Authentication-Results: mxe881;
dkim=pass header.d=gmail.com;
spf=pass (sender IP is 172.232.135.74)
smtp.mailfrom=linux-sunxi+bounces-25071-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-25071-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 70986300D78A
for <noreply@patchwork.local>; Sat, 8 Aug 2026 09:01:38 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 86F363B961F;
Sat, 8 Aug 2026 09:01:35 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.b="Py0+0CTA"
X-Original-To: linux-sunxi@lists.linux.dev
Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com
[209.85.216.45])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id C8BD530DD2F
for <linux-sunxi@lists.linux.dev>; Sat, 8 Aug 2026 09:01:33 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
arc=none smtp.client-ip=209.85.216.45
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1786179695; cv=none;
b=WiwuAYSfmR/NuFYhKqTek/5AXHcrURsKrpsL7vLS/GCaLB6JPtE/t+ix72pl4OiM8d51BAfoxoxGbIeyr30G6o2ZH0wnR9bsNaxWUCmg7Jiy2YK9EbtNXU2VjL58JehO8AqrVHig8QGfC9esOwngUr5SJI649he/Q1a7/34NObE=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1786179695; c=relaxed/simple;
bh=k2o7RLdEaMQf8liSnLShdk2zw3dk1hd297iCbzakkMc=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version;
b=V0enV5p+v6o23QOgJ/oyRBQ5aEvByy9Ah0/LeACvaxmjzzGH8z8gBvXcapZ+McqT832sipE1FmneOHMMffjYh5SU082ZwH8k0tl4tEc9FvhB26OPjbdnCtgC+VSX5vvRtVUxdaCXH/4Tou+vKFNvJcu8BS4IlxxdD0YStMXfG1c=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=gmail.com;
spf=pass smtp.mailfrom=gmail.com;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.b=Py0+0CTA; arc=none smtp.client-ip=209.85.216.45
Authentication-Results: smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: smtp.subspace.kernel.org;
spf=pass smtp.mailfrom=gmail.com
Received: by mail-pj1-f45.google.com with SMTP id
98e67ed59e1d1-38e7109321dso175703a91.3
for <linux-sunxi@lists.linux.dev>;
Sat, 08 Aug 2026 02:01:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20251104; t=1786179693; x=1786784493;
darn=lists.linux.dev;
h=content-transfer-encoding:mime-version:message-id:date:subject:cc
:to:from:from:to:cc:subject:date:message-id:reply-to:content-type;
bh=Z8XEbNxmFITtGAeV3qoLd7HeCqmH9Ffgh8sG2RD/33I=;
b=Py0+0CTAF+5lNd7OWBXOF0i3ihZBw+YXw6dF9AO7p+IUjZgrKSR/HqCl13nd9YGap4
jop9Ah+eZezN7D52hBJz3OA4412crusBUZrz4/ZRHjCRxlc7I32e7tuf80tk4VpXuQfZ
9iBuXy4gJcUH/eundeiEz4M1HZwlNmJWSUnFoEG8F7zSASycEcuYgk2dK4g0V98UEUO1
hIVc7yQjwvuk52vpuQFl3qACNn5sPoNi8+sM7CJTqQ2krR6trbWkBBuJoZ2Xg/ZefH8h
ye6oiK1XsSSi1iHpfnAnKt/LflF4nUUOA1EPPW344pkOQEnaAeIRMnedI3h0+3Yr1C8S
kXPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1786179693; x=1786784493;
h=content-transfer-encoding:mime-version:message-id:date:subject:cc
:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to:content-type;
bh=Z8XEbNxmFITtGAeV3qoLd7HeCqmH9Ffgh8sG2RD/33I=;
b=esdgYaiD9xcK6SCljRvDL/xwTSZD5AgRjyYqJqNVwWkV19dYS9CFJnwWahDjDUL5Lb
CH/gxyyFonVcDacHEh6ZlBXvZ4P+f8mbW7pRLIzxah5Sn1lWMAmoN7KjvxvgJdDGYZQr
SfRH6hOYFbfxhn1K4A+3M0LJ4CkaqY5BWuyqzv3uFalC4794/jkY/rOKse+ErkkSN99Y
ASUMAthnJefsE3gQexgGRpDv6uOl9Buud7Fab9aezcUnJKTCnxKucKfdMuTxCqXBV84a
g/jiJA6rslN3UrN+jYAVeo4w/+v9uq1/zlsYu4WWcQMheEoGRAf09tW393SYuG5G4vjv
cv5g==
X-Forwarded-Encrypted: i=1;
AHgh+RpH/+v0U0Q7eyP+e31PU4AOjQR5n+DS1v6J/3mAUe07TWfVCJd8ojejbMNjGFAwtxlR3SXVAGMpLxONkQ==@lists.linux.dev
X-Gm-Message-State: AOJu0YyRiOieJiSaY/afdxETc56JB7Zfgv5sA0jQMl3AHert8Wc3BlzO
eGysyuaT8zD6lYF028Uwe7GRu7tz3wygHkt/khnl/lqeMo2evL9i0wAW
X-Gm-Gg: AR+sD12SyJbgkTOYgnrx8GK26+6SDp6yosMg5NX/3/vMJloMcck6qXKg9BvBmrBRl2t
Inao7pwhY9Wfa8kNGw0+vOEFPnogWY/6WZziKDpldfwOuXZ20OKhTWB8NU+p8BW3CRg0X5uMi8k
oB2sqzPZAZT/8BKzdROCb3NjyPKytbyw/TEFaFI0LrljUbBUS7xRu3OKJBzVzqpBar6DFHEDKe9
RlchNFlZPZT+mtPNKaI/628Fhm6D4wG909+Npyio9DZX5xgCtFxaXNBUOHngc9kaWfkUkcJyz1N
u7Y8f1y3kK1cHRqx6q2AcVZ6KweZkhy4DiEX0AMpesfAlHAb07M2AwnZoKjE7R8qv79mg04p1RH
iH923BM8757uDgX5pSOCzVTOhIf2uF2lK8XoxWz3/RBL5kTpKrSIdeLCe//TK/GMbCjz+y6cN38
BJ7Tjv672G51p8+mjTkRmSIkGINt3UxPxC7mKiE5IddAVwIy2apu9DksyncXB8ESY/5f4E
X-Received: by 2002:a17:90b:582e:b0:38e:485c:ebd3 with SMTP id
98e67ed59e1d1-392823d97aamr5991393a91.15.1786179692981;
Sat, 08 Aug 2026 02:01:32 -0700 (PDT)
Received: from lgs.. ([101.76.249.46])
by smtp.gmail.com with ESMTPSA id
98e67ed59e1d1-3925ff24b91sm5349083a91.9.2026.08.08.02.01.29
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 08 Aug 2026 02:01:32 -0700 (PDT)
From: Guangshuo Li <lgs201920130244@gmail.com>
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>,
Arnd Bergmann <arnd@arndb.de>,
Guangshuo Li <lgs201920130244@gmail.com>,
Maxime Ripard <mripard@kernel.org>,
linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev,
linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Subject: [PATCH] crypto: sun8i-ss: fix autosuspend cleanup during teardown
Date: Sat, 8 Aug 2026 17:01:21 +0800
Message-ID: <20260808090121.2718855-1-lgs201920130244@gmail.com>
X-Mailer: git-send-email 2.43.0
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-Rspamd-Server: rspamd-worker-8404
X-Spamd-Result: default: False [0.34 / 15.00];
BAYES_HAM(-5.50)[100.00%];
RBL_SENDERSCORE(2.00)[172.232.135.74:from];
SUSPICIOUS_RECIPS(1.50)[];
MID_CONTAINS_FROM(1.00)[];
DMARC_POLICY_SOFTFAIL(1.00)[gmail.com : SPF not aligned (relaxed),
No valid DKIM,none];
R_MISSING_CHARSET(0.50)[];
MAILLIST(-0.15)[generic];
BAD_REP_POLICIES(0.10)[];
MIME_GOOD(-0.10)[text/plain];
HAS_LIST_UNSUB(-0.01)[];
FROM_HAS_DN(0.00)[];
FORGED_SENDER_MAILLIST(0.00)[];
PRECEDENCE_BULK(0.00)[];
DBL_BLOCKED_OPENRESOLVER(0.00)[sto.lore.kernel.org:rdns,sto.lore.kernel.org:helo];
TAGGED_RCPT(0.00)[];
RCPT_COUNT_TWELVE(0.00)[14];
RCVD_COUNT_FIVE(0.00)[6];
ARC_ALLOW(0.00)[subspace.kernel.org:s=arc-20240116:i=1];
R_SPF_ALLOW(0.00)[+ip4:172.232.135.74];
FREEMAIL_TO(0.00)[gmail.com,gondor.apana.org.au,davemloft.net,kernel.org,sholland.org,arndb.de,vger.kernel.org,lists.infradead.org,lists.linux.dev];
FREEMAIL_FROM(0.00)[gmail.com];
TO_DN_SOME(0.00)[];
FROM_NEQ_ENVFROM(0.00)[lgs201920130244@gmail.com,linux-sunxi@lists.linux.dev];
FORGED_RECIPIENTS_MAILLIST(0.00)[];
RCVD_TLS_LAST(0.00)[];
MIME_TRACE(0.00)[0:+];
TAGGED_FROM(0.00)[bounces-25071-noreply=patchwork.local];
ASN(0.00)[asn:63949, ipnet:172.232.128.0/19, country:SG];
RCVD_VIA_SMTP_AUTH(0.00)[]
X-Rspamd-Queue-Id: DFBD11C1486
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: sun8i-ss: fix autosuspend cleanup during teardown
|
|
Commit Message
Guangshuo Li
Aug. 8, 2026, 9:01 a.m. UTC
sun8i_ss_pm_init() calls pm_runtime_use_autosuspend(), but the
autosuspend setting is not undone if pm_runtime_set_suspended() fails
or when runtime PM is later torn down by sun8i_ss_pm_exit().
If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during cleanup, this reference is not dropped and usage_count remains
unbalanced.
Undo the autosuspend setting when pm_runtime_set_suspended() fails and
in sun8i_ss_pm_exit() before disabling runtime PM.
This issue was found by manual code inspection.
Fixes: f08fcced6d00 ("crypto: allwinner - Add sun8i-ss cryptographic offloader")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
Comments
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider: Pre-existing issues: - [High] This problem wasn't introduced by this patch, but a kernel panic occurs due to a NULL pointer dereference when tearing down uninitialized flows on memory allocation failure. - [High] This problem wasn't introduced by this patch, but a Use-After-Free of the device struct occurs on asynchronous sysfs device unbind when TFMs remain active. - [High] This problem wasn't introduced by this patch, but the interrupt handler reads hardware registers without checking if the device is active, violating PM subsystem guidelines and risking a bus fault. -- --- Patch [1]: [PATCH] crypto: sun8i-ss: fix autosuspend cleanup during teardown --- commit 75226cf213617a07b13c36d7aa3f2f0e09bc4f0f Author: Guangshuo Li <lgs201920130244@gmail.com> crypto: sun8i-ss: fix autosuspend cleanup during teardown sun8i_ss_pm_init() calls pm_runtime_use_autosuspend(), but the autosuspend setting is not undone if pm_runtime_set_suspended() fails or when runtime PM is later torn down by sun8i_ss_pm_exit(). This patch ensures the autosuspend setting is correctly cleaned up by calling pm_runtime_dont_use_autosuspend(). > diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c > index 59c9bc45ec0f2..775355ac9f9e2 100644 > --- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c > +++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c > @@ -664,14 +664,18 @@ static int sun8i_ss_pm_init(struct sun8i_ss_dev *ss) > pm_runtime_set_autosuspend_delay(ss->dev, 2000); > > err = pm_runtime_set_suspended(ss->dev); > - if (err) > + if (err) { > + pm_runtime_dont_use_autosuspend(ss->dev); > return err; > + } > + > pm_runtime_enable(ss->dev); > return err; > } > > static void sun8i_ss_pm_exit(struct sun8i_ss_dev *ss) > { > + pm_runtime_dont_use_autosuspend(ss->dev); > pm_runtime_disable(ss->dev); > } [Severity: High] This isn't a bug introduced by this patch, but a kernel panic occurs due to a NULL pointer dereference when tearing down uninitialized flows on memory allocation failure. If a memory allocation fails inside allocate_flows(), the code jumps to error_engine without decrementing the loop index i: drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c:allocate_flows() { ... ss->flows[i].biv = devm_kmalloc(ss->dev, AES_BLOCK_SIZE, GFP_KERNEL); if (!ss->flows[i].biv) { err = -ENOMEM; goto error_engine; } ... } It then executes sun8i_ss_free_flows(ss, i). Because ss->flows was allocated with devm_kcalloc (zero-initialized), ss->flows[i].engine is still NULL: drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c:sun8i_ss_free_flows() { static void sun8i_ss_free_flows(struct sun8i_ss_dev *ss, int i) { while (i >= 0) { crypto_engine_exit(ss->flows[i].engine); i--; } } Will this pass the NULL engine pointer to crypto_engine_exit() and cause a crash when it is dereferenced? [Severity: High] This isn't a bug introduced by this patch, but a use-after-free of the device struct occurs on asynchronous sysfs device unbind when TFMs remain active. During device unbind, sun8i_ss_remove() initiates the teardown without waiting for active TFMs to be released, allowing devres to free the device structure early: drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c:sun8i_ss_remove() { static void sun8i_ss_remove(struct platform_device *pdev) { struct sun8i_ss_dev *ss = platform_get_drvdata(pdev); sun8i_ss_unregister_algs(ss); ... } When the user process later closes its socket, does sun8i_ss_cipher_exit() dereference the already freed op->ss structure? drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c:sun8i_ss_cipher_exit() { void sun8i_ss_cipher_exit(struct crypto_tfm *tfm) { struct sun8i_cipher_tfm_ctx *op = crypto_tfm_ctx(tfm); kfree_sensitive(op->key); crypto_free_skcipher(op->fallback_tfm); pm_runtime_put_sync(op->ss->dev); } [Severity: High] This isn't a bug introduced by this patch, but the interrupt handler reads hardware registers without checking if the device is active, violating PM subsystem guidelines and risking a bus fault. The interrupt handler immediately reads SS_INT_STA_REG upon entry: drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c:ss_irq_handler() { static irqreturn_t ss_irq_handler(int irq, void *data) { struct sun8i_ss_dev *ss = (struct sun8i_ss_dev *)data; int flow = 0; u32 p; p = readl(ss->base + SS_INT_STA_REG); ... } If a late or spurious interrupt fires while the device is in the RPM_SUSPENDED state (with hardware clocks disabled), will this register read fault? Could pm_runtime_get_if_active() be used before accessing hardware registers to guarantee power is applied?
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c index 59c9bc45ec0f..775355ac9f9e 100644 --- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c +++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c @@ -664,14 +664,18 @@ static int sun8i_ss_pm_init(struct sun8i_ss_dev *ss) pm_runtime_set_autosuspend_delay(ss->dev, 2000); err = pm_runtime_set_suspended(ss->dev); - if (err) + if (err) { + pm_runtime_dont_use_autosuspend(ss->dev); return err; + } + pm_runtime_enable(ss->dev); return err; } static void sun8i_ss_pm_exit(struct sun8i_ss_dev *ss) { + pm_runtime_dont_use_autosuspend(ss->dev); pm_runtime_disable(ss->dev); }