linux.git/drivers/crypto, branch v6.12.80

crypto: atmel-sha204a - Fix OOM ->tfm_count leak

2026-03-25T10:08:44+00:00

[ Upstream commit d240b079a37e90af03fd7dfec94930eb6c83936e ]

If memory allocation fails, decrement ->tfm_count to avoid blocking
future reads.

Cc: stable@vger.kernel.org
Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
Signed-off-by: Thorsten Blum 
Signed-off-by: Herbert Xu 
[ adapted kmalloc_obj() macro to kmalloc(sizeof()) ]
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

crypto: hisilicon/qm - move the barrier before writing to the mailbox register

2026-03-04T12:20:58+00:00

[ Upstream commit ebf35d8f9368816c930f5d70783a72716fab5e19 ]

Before sending the data via the mailbox to the hardware, to ensure
that the data accessed by the hardware is the most up-to-date,
a write barrier should be added before writing to the mailbox register.
The current memory barrier is placed after writing to the register,
the barrier order should be modified to be before writing to the register.

Signed-off-by: Chenghai Huang 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: ccp - Send PSP_CMD_TEE_RING_DESTROY when PSP_CMD_TEE_RING_INIT fails

2026-03-04T12:20:20+00:00

[ Upstream commit 7b85137caf110a09a4a18f00f730de4709f9afc8 ]

The hibernate resume sequence involves loading a resume kernel that is just
used for loading the hibernate image before shifting back to the existing
kernel.

During that hibernate resume sequence the resume kernel may have loaded
the ccp driver. If this happens the resume kernel will also have called
PSP_CMD_TEE_RING_INIT but it will never have called
PSP_CMD_TEE_RING_DESTROY.

This is problematic because the existing kernel needs to re-initialize the
ring. One could argue that the existing kernel should call destroy
as part of restore() but there is no guarantee that the resume kernel did
or didn't load the ccp driver. There is also no callback opportunity for
the resume kernel to destroy before handing back control to the existing
kernel.

Similar problems could potentially exist with the use of kdump and
crash handling. I actually reproduced this issue like this:

1) rmmod ccp
2) hibernate the system
3) resume the system
4) modprobe ccp

The resume kernel will have loaded ccp but never destroyed and then when
I try to modprobe it fails.

Because of these possible cases add a flow that checks the error code from
the PSP_CMD_TEE_RING_INIT call and tries to call PSP_CMD_TEE_RING_DESTROY
if it failed. If this succeeds then call PSP_CMD_TEE_RING_INIT again.

Fixes: f892a21f51162 ("crypto: ccp - use generic power management")
Reported-by: Lars Francke
Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/
Tested-by: Yijun Shen
Signed-off-by: Mario Limonciello (AMD)
Reviewed-by: Shyam Sundar S K
Acked-by: Tom Lendacky
Link: https://patch.msgid.link/20260116041132.153674-6-superm1@kernel.org
Signed-off-by: Ilpo Järvinen
Signed-off-by: Sasha Levin

crypto: ccp - Factor out ring destroy handling to a helper

2026-03-04T12:20:20+00:00

[ Upstream commit d95f87a65bce5f2f2a02ca6094ca4841d4073df3 ]

The ring destroy command needs to be used in multiple places. Split
out the code to a helper.

Tested-by: Yijun Shen 
Signed-off-by: Mario Limonciello (AMD) 
Acked-by: Tom Lendacky 
Reviewed-by: Shyam Sundar S K 
Link: https://patch.msgid.link/20260116041132.153674-5-superm1@kernel.org
Signed-off-by: Ilpo Järvinen 
Stable-dep-of: 7b85137caf11 ("crypto: ccp - Send PSP_CMD_TEE_RING_DESTROY when PSP_CMD_TEE_RING_INIT fails")
Signed-off-by: Sasha Levin

crypto: ccp - Add an S4 restore flow

2026-03-04T12:20:20+00:00

[ Upstream commit 0ba2035026d0ab6c7c7e65ad8b418dc73d5700d9 ]

The system will have lost power during S4.  The ring used for TEE
communications needs to be initialized before use.

Fixes: f892a21f51162 ("crypto: ccp - use generic power management")
Reported-by: Lars Francke 
Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/
Tested-by: Yijun Shen 
Signed-off-by: Mario Limonciello (AMD) 
Reviewed-by: Shyam Sundar S K 
Reviewed-by: Tom Lendacky 
Link: https://patch.msgid.link/20260116041132.153674-4-superm1@kernel.org
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin

crypto: ccp - Declare PSP dead if PSP_CMD_TEE_RING_INIT fails

2026-03-04T12:20:20+00:00

[ Upstream commit 5e599d7871bf852e94e8aa08b99724635f2cbf96 ]

tee_init_ring() only declares PSP dead if the command times out.
If there is any other failure it is still considered fatal though.
Set psp_dead for other failures as well.

Fixes: 949a0c8dd3c2 ("crypto: ccp - Move direct access to some PSP registers out of TEE")
Tested-by: Yijun Shen 
Signed-off-by: Mario Limonciello (AMD) 
Acked-by: Tom Lendacky 
Reviewed-by: Shyam Sundar S K 
Link: https://patch.msgid.link/20260116041132.153674-3-superm1@kernel.org
Signed-off-by: Ilpo Järvinen 
Signed-off-by: Sasha Levin

crypto: starfive - Fix memory leak in starfive_aes_aead_do_one_req()

2026-03-04T12:19:40+00:00

[ Upstream commit ccb679fdae2e62ed92fd9acb25ed809c0226fcc6 ]

The starfive_aes_aead_do_one_req() function allocates rctx->adata with
kzalloc() but fails to free it if sg_copy_to_buffer() or
starfive_aes_hw_init() fails, which lead to memory leaks.

Since rctx->adata is unconditionally freed after the write_adata
operations, ensure consistent cleanup by freeing the allocation in these
earlier error paths as well.

Compile tested only. Issue found using a prototype static analysis tool
and code review.

Fixes: 7467147ef9bf ("crypto: starfive - Use dma for aes requests")
Signed-off-by: Zilin Guan 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: caam - fix netdev memory leak in dpaa2_caam_probe

2026-03-04T12:19:38+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: hisilicon/trng - support tfms sharing the device

2026-03-04T12:19:38+00:00

[ Upstream commit 3d3135057ff567d5c09fff4c9ef6391a684e8042 ]

Since the number of devices is limited, and the number
of tfms may exceed the number of devices, to ensure that
tfms can be successfully allocated, support tfms
sharing the same device.

Fixes: e4d9d10ef4be ("crypto: hisilicon/trng - add support for PRNG")
Signed-off-by: Weili Qian 
Signed-off-by: Chenghai Huang 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin

crypto: ccp - narrow scope of snp_range_list

2026-03-04T12:19:35+00:00

[ Upstream commit dc8ccab15081efc4f2c5a9fc7b209cd641d29177 ]

snp_range_list is only used in __sev_snp_init_locked() in the SNP_INIT_EX
case, move the declaration there and add a __free() cleanup helper for it
instead of waiting until shutdown.

Fixes: 1ca5614b84ee ("crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP")
Reviewed-by: Alexey Kardashevskiy 
Signed-off-by: Tycho Andersen (AMD) 
Reviewed-by: Tom Lendacky 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin