kernel/linux.git/drivers/crypto/caam, branch v6.18.21

crypto: caam - fix netdev memory leak in dpaa2_caam_probe

2026-02-26T22:59:05+00:00

[ Upstream commit 7d43252b3060b0ba4a192dce5dba85a3f39ffe39 ] When commit 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2") converted embedded net_device to dynamically allocated pointers, it added cleanup in dpaa2_dpseci_disable() but missed adding cleanup in dpaa2_dpseci_free() for error paths. This causes memory leaks when dpaa2_dpseci_dpio_setup() fails during probe due to DPIO devices not being ready yet. The kernel's deferred probe mechanism handles the retry successfully, but the netdevs allocated during the failed probe attempt are never freed, resulting in kmemleak reports showing multiple leaked netdev-related allocations all traced back to dpaa2_caam_probe(). Fix this by preserving the CPU mask of allocated netdevs during setup and using it for cleanup in dpaa2_dpseci_free(). This approach ensures that only the CPUs that actually had netdevs allocated will be cleaned up, avoiding potential issues with CPU hotplug scenarios. Fixes: 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2") Signed-off-by: Jianpeng Chang Reviewed-by: Breno Leitao Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: caam - Add check for kcalloc() in test_len()

2026-01-02T11:57:27+00:00

commit 7cf6e0b69b0d90ab042163e5bbddda0dfcf8b6a7 upstream. As kcalloc() may fail, check its return value to avoid a NULL pointer dereference when passing the buffer to rng->read(). On allocation failure, log the error and return since test_len() returns void. Fixes: 2be0d806e25e ("crypto: caam - add a test for the RNG") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: caam - double the entropy delay interval for retry

2025-09-13T04:11:06+00:00

during entropy evaluation, if the generated samples fail any statistical test, then, all of the bits will be discarded, and a second set of samples will be generated and tested. the entropy delay interval should be doubled before performing the retry. also, ctrlpriv->rng4_sh_init and inst_handles both reads RNG DRNG status register, but only inst_handles is updated before every retry. so only check inst_handles and removing ctrlpriv->rng4_sh_init Signed-off-by: Gaurav Jain Signed-off-by: Herbert Xu

crypto: caam - switch to use devm_kmemdup_array()

2025-09-06T07:57:23+00:00

Use devm_kmemdup_array() to avoid multiplication or possible overflows. Signed-off-by: Zhang Enpei Signed-off-by: Herbert Xu

crypto: engine - remove request batching support

2025-07-18T10:52:00+00:00

Remove request batching support from crypto_engine, as there are no drivers using this feature and it doesn't really work that well. Instead of doing batching based on backlog, a more optimal approach would be for the user to handle the batching (similar to how IPsec can hook into GSO to get 64K of data each time or how block encryption can use unit sizes much greater than 4K). Suggested-by: Herbert Xu Signed-off-by: Ovidiu Panait Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - avoid option aliasing with the CONFIG_CAAM_QI build option

2025-07-18T10:51:59+00:00

In the Makefile, the new build option CONFIG_CAAM_QI is defined conditioned on the existence of the CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI, which is properly defined in the Kconfig file. So, CONFIG_CAAM_QI is just a local alias for CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI. There is little benefit in the source code of having this slightly shorter alias for this configuration, but it complicates further maintenance, as searching for the impact of CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI requires to grep once, and then identify the option introduced and continue searching for that. Further, tools, such as cross referencers, and scripts to check Kconfig definitions and their use simply do not handle this situation. Given that this is the only incidence of such a config alias in the whole kernel tree, just prefer to avoid this pattern of aliasing here. Use CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI throughout the Freescale CAAM-Multicore platform driver backend source code. No functional change. Signed-off-by: Lukas Bulwahn Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - Support iMX8QXP and variants thereof

2025-06-23T08:59:38+00:00

The iMX8QXP (and variants such as the QX, DX, DXP) all identify as iMX8QXP. They have the exact same restrictions as the supported iMX8QM introduced at commit 61bb8db6f682 ("crypto: caam - Add support for i.MX8QM") Loosen the check a little bit with a wildcard to also match the iMX8QXP and its variants. Signed-off-by: John Ernberg Reviewed-by: Frank Li Reviewed-by: Peng Fan Signed-off-by: Herbert Xu

crypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULP

2025-06-23T08:59:38+00:00

Since the CAAM on these SoCs is managed by another ARM core, called the SECO (Security Controller) on iMX8QM and Secure Enclave on iMX8ULP, which also reserves access to register page 0 suspend operations cannot touch this page. This is similar to when running OPTEE, where OPTEE will reserve page 0. Track this situation using a new state variable no_page0, reflecting if page 0 is reserved elsewhere, either by other management cores in SoC or by OPTEE. Replace the optee_en check in suspend/resume with the new check. optee_en cannot go away as it's needed elsewhere to gate OPTEE specific situations. Fixes the following splat at suspend: Internal error: synchronous external abort: 0000000096000010 [#1] SMP Hardware name: Freescale i.MX8QXP ACU6C (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : readl+0x0/0x18 lr : rd_reg32+0x18/0x3c sp : ffffffc08192ba20 x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000 x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090 x23: 0000000000000000 x22: ffffffc080922000 x21: ffffff8020e89010 x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5 x17: 0000000030f35963 x16: 000000008f785f3f x15: 000000003b8ef57c x14: 00000000c418aef8 x13: 00000000f5fea526 x12: 0000000000000001 x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000 x8 : ffffff8025190870 x7 : ffffff8021726880 x6 : 0000000000000002 x5 : ffffff80217268f0 x4 : ffffff8021726880 x3 : ffffffc081200000 x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004 Call trace: readl+0x0/0x18 caam_ctrl_suspend+0x30/0xdc dpm_run_callback.constprop.0+0x24/0x5c device_suspend+0x170/0x2e8 dpm_suspend+0xa0/0x104 dpm_suspend_start+0x48/0x50 suspend_devices_and_enter+0x7c/0x45c pm_suspend+0x148/0x160 state_store+0xb4/0xf8 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x38/0x48 kernfs_fop_write_iter+0xb4/0x178 vfs_write+0x118/0x178 ksys_write+0x6c/0xd0 __arm64_sys_write+0x14/0x1c invoke_syscall.constprop.0+0x64/0xb0 do_el0_svc+0x90/0xb0 el0_svc+0x18/0x44 el0t_64_sync_handler+0x88/0x124 el0t_64_sync+0x150/0x154 Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000) Fixes: d2835701d93c ("crypto: caam - i.MX8ULP donot have CAAM page0 access") Cc: stable@kernel.org # v6.10+ Signed-off-by: John Ernberg Reviewed-by: Peng Fan Reviewed-by: Frank Li Signed-off-by: Herbert Xu

crypto: caam - Fix opencoded cpumask_next_wrap() in caam_drv_ctx_init()

2025-06-13T09:26:17+00:00

The dedicated cpumask_next_wrap() is more verbose and better optimized comparing to cpumask_next() followed by cpumask_first(). Signed-off-by: Yury Norov [NVIDIA] Signed-off-by: Herbert Xu

crypto: caam - Add support for i.MX8QM

2025-04-16T07:16:21+00:00

On i.MX8QM, caam clocks are turned on automatically and Linux does not have access to the caam controller's register page, so skip clocks initialization. Signed-off-by: Thomas Richard Reviewed-by: Gaurav Jain Signed-off-by: Herbert Xu