[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?