[PATCH v2] crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path

[PATCH v2] crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path

[Thorsten Blum]

Unregister the hwrng to prevent new ->read() calls and flush the Atmel
I2C workqueue before teardown to prevent a potential UAF if a queued
callback runs while the device is being removed.

Drop the early return to ensure sysfs entries are removed and
->hwrng.priv is freed, preventing a memory leak.

Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
Cc: stable@vger.kernel.org
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Changes in v2:
- Unregister hwrng to avoid new ->read() calls and then flush the queue
- Drop the ->tfm_count check and error logging after flushing (Herbert)
- Link to v1: https://lore.kernel.org/lkml/20260221190424.85984-2-thorsten.blum@linux.dev/
---
 drivers/crypto/atmel-sha204a.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index 98d1023007e3..aeadbc9a2759 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -191,10 +191,8 @@ static void atmel_sha204a_remove(struct i2c_client *client)
 {
 	struct atmel_i2c_client_priv *i2c_priv = i2c_get_clientdata(client);
 
-	if (atomic_read(&i2c_priv->tfm_count)) {
-		dev_emerg(&client->dev, "Device is busy, will remove it anyhow\n");
-		return;
-	}
+	devm_hwrng_unregister(&client->dev, &i2c_priv->hwrng);
+	atmel_i2c_flush_queue();
 
 	sysfs_remove_group(&client->dev.kobj, &atmel_sha204a_groups);
 

Re: [PATCH v2] crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path

[Herbert Xu]

On Sat, Mar 14, 2026 at 08:36:29PM +0100, Thorsten Blum wrote:
>
> diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> index 98d1023007e3..aeadbc9a2759 100644
> --- a/drivers/crypto/atmel-sha204a.c
> +++ b/drivers/crypto/atmel-sha204a.c
> @@ -191,10 +191,8 @@ static void atmel_sha204a_remove(struct i2c_client *client)
>  {
>  	struct atmel_i2c_client_priv *i2c_priv = i2c_get_clientdata(client);
>  
> -	if (atomic_read(&i2c_priv->tfm_count)) {
> -		dev_emerg(&client->dev, "Device is busy, will remove it anyhow\n");
> -		return;
> -	}
> +	devm_hwrng_unregister(&client->dev, &i2c_priv->hwrng);

Is it OK to explicitly call devm_hwrng_unregister?

Perhaps it's best to remove the devm management?

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path

[Thorsten Blum]

On Sun, Mar 15, 2026 at 01:31:25PM +0900, Herbert Xu wrote:
> On Sat, Mar 14, 2026 at 08:36:29PM +0100, Thorsten Blum wrote:
> >
> > diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
> > index 98d1023007e3..aeadbc9a2759 100644
> > --- a/drivers/crypto/atmel-sha204a.c
> > +++ b/drivers/crypto/atmel-sha204a.c
> > @@ -191,10 +191,8 @@ static void atmel_sha204a_remove(struct i2c_client *client)
> >  {
> >  	struct atmel_i2c_client_priv *i2c_priv = i2c_get_clientdata(client);
> >  
> > -	if (atomic_read(&i2c_priv->tfm_count)) {
> > -		dev_emerg(&client->dev, "Device is busy, will remove it anyhow\n");
> > -		return;
> > -	}
> > +	devm_hwrng_unregister(&client->dev, &i2c_priv->hwrng);
> 
> Is it OK to explicitly call devm_hwrng_unregister?
> 
> Perhaps it's best to remove the devm management?

Yes, it should be safe since explicitly unregistering the hwrng removes
the devres entry, and the automatic devm cleanup later essentially
becomes a no-op.

Switching to hwrng_{register,unregister} is more explicit, but it would
require a bool hwrng_registered field in atmel_i2c_client_priv to keep
track of RNG registration success/failure.

Which approach do you prefer? Perhaps the smaller devm change for
backporting, and then switching to hwrng_{register,unregister} in a
separate cleanup patch?

Re: [PATCH v2] crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path

[Herbert Xu]

On Sun, Mar 15, 2026 at 08:45:15PM +0100, Thorsten Blum wrote:
>
> Yes, it should be safe since explicitly unregistering the hwrng removes
> the devres entry, and the automatic devm cleanup later essentially
> becomes a no-op.

If it's safe then let's just keep it this way.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2] crypto: atmel-sha204a - Fix potential UAF and memory leak in remove path

[Herbert Xu]

On Sat, Mar 14, 2026 at 08:36:29PM +0100, Thorsten Blum wrote:
> Unregister the hwrng to prevent new ->read() calls and flush the Atmel
> I2C workqueue before teardown to prevent a potential UAF if a queued
> callback runs while the device is being removed.
> 
> Drop the early return to ensure sysfs entries are removed and
> ->hwrng.priv is freed, preventing a memory leak.
> 
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
> Cc: stable@vger.kernel.org
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> Changes in v2:
> - Unregister hwrng to avoid new ->read() calls and then flush the queue
> - Drop the ->tfm_count check and error logging after flushing (Herbert)
> - Link to v1: https://lore.kernel.org/lkml/20260221190424.85984-2-thorsten.blum@linux.dev/
> ---
>  drivers/crypto/atmel-sha204a.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt