From: sashiko-bot@kernel.org
To: "Thorsten Blum" <blum@kernel.org>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/2] crypto: atmel-ecc - add support for atecc608a
Date: Sun, 30 Aug 2026 22:10:30 +0000 [thread overview]
Message-ID: <20260830221031.3F3831F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260830220151.21469-4-blum@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Use-After-Free due to early return in `atmel_ecc_remove()` missing list deletion.
--
commit da00b1f7ab58791bf49d80087ba781e30c9433d0
Author: Thorsten Blum <blum@kernel.org>
crypto: atmel-ecc - add support for atecc608a
The driver already supports the ATECC508A and ATECC608B and uses only
commands shared by these devices.
Microchip documents the ATECC608B as a backwards-compatible, functional
drop-in replacement for the ATECC608A, with the same device structure
and command interface [1]. Therefore, add support for the ATECC608A.
ATECC608A hardware was not available for testing.
Link: https://ww1.microchip.com/downloads/en/Appnotes/Migrating-from-the-ATECC608A-to-the-ATECC608B-DS40002237A.pdf [1]
> diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
> index 075f38a67935c..0904bb47fd0a9 100644
> --- a/drivers/crypto/atmel-ecc.c
> +++ b/drivers/crypto/atmel-ecc.c
> @@ -348,6 +348,7 @@ static void atmel_ecc_remove(struct i2c_client *client)
[Severity: High]
This is a pre-existing issue, but can the early return in atmel_ecc_remove()
cause a use-after-free?
If a user unbinds the ATECC device via sysfs while a crypto operation is in
flight (tfm_count > 0):
drivers/crypto/atmel-ecc.c:atmel_ecc_remove() {
...
if (atomic_read(&i2c_priv->tfm_count)) {
dev_emerg(&client->dev, "Device is busy, expect memory corruption.\n");
return;
}
...
list_del(&i2c_priv->i2c_client_list_node);
...
}
The early return bypasses list_del(&i2c_priv->i2c_client_list_node). The
driver core then frees the devm_kmalloc-allocated i2c_priv, leaving a freed
node on the global driver_data.i2c_client_list.
The next time any crypto operation is requested, atmel_ecc_i2c_client_alloc()
will iterate over the list and access the freed i2c_priv node, causing a
use-after-free.
Does it make sense to always remove the node from the list before returning?
>
> static const struct of_device_id atmel_ecc_dt_ids[] = {
> { .compatible = "atmel,atecc508a", },
> + { .compatible = "atmel,atecc608a", },
> { .compatible = "atmel,atecc608b", },
> { }
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260830220151.21469-3-blum@kernel.org?part=2
next prev parent reply other threads:[~2026-08-30 22:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 22:01 [PATCH 1/2] dt-bindings: trivial-devices: add atmel,atecc608a Thorsten Blum
2026-08-30 22:01 ` [PATCH 2/2] crypto: atmel-ecc - add support for atecc608a Thorsten Blum
2026-08-30 22:10 ` sashiko-bot [this message]
2026-08-31 16:19 ` [PATCH 1/2] dt-bindings: trivial-devices: add atmel,atecc608a Conor Dooley
2026-09-11 5:33 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260830221031.3F3831F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=blum@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.