Re: [PATCH] crypto: omap-aes - fix NULL pointer dereference in omap_aes_remove()

[Herbert Xu <herbert@gondor.apana.org.au>]

On Fri, Oct 16, 2026 at 04:30:04PM +0800, ZhaoJinming wrote:
> omap_aes_remove() unconditionally dereferences dd->pdata->aead_algs_info,
> but only omap_aes_pdata_omap4 initializes that field:
> 
> 	static const struct omap_aes_pdata omap_aes_pdata_omap2 = {
> 		.algs_info	= omap_aes_algs_info_ecb_cbc,
> 		...
> 	};
> 
> 	static const struct omap_aes_pdata omap_aes_pdata_omap3 = {
> 		.algs_info	= omap_aes_algs_info_ecb_cbc_ctr,
> 		...
> 	};
> 
> 	static const struct omap_aes_pdata omap_aes_pdata_omap4 = {
> 		...
> 		.aead_algs_info	= &omap_aes_aead_info,
> 		...
> 	};
> 
> For omap2 and omap3 the field stays NULL, so on those SoCs unbinding
> the bound device (e.g. via sysfs unbind) or unloading the module (rmmod)
> dereferences a NULL pointer:
> 
> 	crypto_engine_unregister_aeads(dd->pdata->aead_algs_info->algs_list,
> 				       dd->pdata->aead_algs_info->registered);
> 	dd->pdata->aead_algs_info->registered = 0;
> 
> This is a hard crash, reachable from the teardown path only; probe
> errors do not get here.  The asymmetry dates back to the commit that
> introduced GCM support, which guarded the registration of the AEAD
> algorithms but not their unregistration.  The registration path in
> omap_aes_probe() already guards the same access with
> "if (dd->pdata->aead_algs_info && ...)", so add the matching check to
> the remove path.
> 
> Fixes: ad18cc9d0f91 ("crypto: omap-aes - Add support for GCM mode")
> Cc: stable@vger.kernel.org
> Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
> ---
>  drivers/crypto/omap-aes.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 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