From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Tudor Ambarus <tudor.ambarus@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
linux-crypto@vger.kernel.org, kernel@pengutronix.de,
Claudiu Beznea <claudiu.beznea@microchip.com>,
linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org
Subject: Bug in atmel-ecc driver
Date: Fri, 13 May 2022 15:59:54 +0200 [thread overview]
Message-ID: <20220513135954.exewihnibnhdckkn@pengutronix.de> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 1416 bytes --]
Hello,
TL;DR: when a device bound to the drivers/crypto/atmel-ecc.c driver is
unbound while tfm_count isn't zero, this probably results in a
use-after-free.
The .remove function has:
if (atomic_read(&i2c_priv->tfm_count)) {
dev_err(&client->dev, "Device is busy\n");
return -EBUSY;
}
before actually calling the cleanup stuff. If this branch is hit the
result is likely:
- "Device is busy" from drivers/crypto/atmel-ecc.c
- "remove failed (EBUSY), will be ignored" from the i2c core
- the devm cleanup callbacks are called, including the one kfreeing
*i2c_priv
- at a later time atmel_ecc_i2c_client_free() is called which does
atomic_dec(&i2c_priv->tfm_count);
- *boom*
I think to fix that you need to call get_device for the i2c device
before increasing tfm_count (and a matching put_device when decreasing
it). Having said that the architecture of this driver looks strange to
me, so there might be nicer fixes (probably with more effort).
I noticed this issue while working on my quest to make i2c-remove
callbacks return void. So if you address this, it would be great if you
did that in a way that makes atmel_ecc_remove always return 0.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2022-05-13 14:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-13 13:59 Uwe Kleine-König [this message]
2022-05-17 10:24 ` Bug in atmel-ecc driver Uwe Kleine-König
2022-05-17 13:11 ` Tudor.Ambarus
2022-05-17 14:33 ` Uwe Kleine-König
2022-05-18 10:07 ` Tudor.Ambarus
2022-05-18 21:36 ` Uwe Kleine-König
2022-05-20 17:21 ` [PATCH] crypto: atmel-ecc - Remove duplicated error reporting in .remove() Uwe Kleine-König
2022-06-07 6:48 ` Uwe Kleine-König
2022-06-08 4:33 ` Tudor.Ambarus
2022-06-08 7:04 ` Uwe Kleine-König
2022-06-08 8:35 ` Tudor.Ambarus
2022-06-10 9:14 ` 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=20220513135954.exewihnibnhdckkn@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=alexandre.belloni@bootlin.com \
--cc=claudiu.beznea@microchip.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=tudor.ambarus@microchip.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).