kernel/drivers/crypto/caam, branch master

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51Z

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28Z

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

crypto: caam - fix netdev memory leak in dpaa2_caam_probe

2026-01-31T02:52:31Z

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

crypto: caam - Add support of paes algorithm

2025-10-20T04:10:28Z

PAES algorithm uses protected key for encryption/decryption operations. Signed-off-by: Gaurav Jain Signed-off-by: Meenakshi Aggarwal Signed-off-by: Herbert Xu

KEYS: trusted: caam based protected key

2025-10-20T04:10:28Z

- CAAM supports two types of protected keys: -- Plain key encrypted with ECB -- Plain key encrypted with CCM Due to robustness, default encryption used for protected key is CCM. - Generate protected key blob and add it to trusted key payload. This is done as part of sealing operation, which is triggered when below two operations are requested: -- new key generation -- load key, Signed-off-by: Pankaj Gupta Signed-off-by: Meenakshi Aggarwal Signed-off-by: Herbert Xu

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

2025-10-17T08:03:57Z

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

crypto: caam - double the entropy delay interval for retry

2025-09-13T04:11:06Z

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:23Z

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:00Z

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:59Z

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