kernel/drivers/crypto, branch linux-6.12.y

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

2026-03-04T12:20:58Z

[ 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:20Z

[ 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:20Z

[ 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:20Z

[ 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:20Z

[ 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:40Z

[ 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:38Z

[ 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:38Z

[ 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:35Z

[ 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

crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls

2026-03-04T12:19:35Z

[ Upstream commit ceac7fb89e8da465aec3ac3c20477f912f5c3a6c ] Modify the behavior of implicit SEV initialization in some of the SEV ioctls to do both SEV initialization and shutdown and add implicit SNP initialization and shutdown to some of the SNP ioctls so that the change of SEV/SNP platform initialization not being done during PSP driver probe time does not break userspace tools such as sevtool, etc. Prior to this patch, SEV has always been initialized before these ioctls as SEV initialization is done as part of PSP module probe, but now with SEV initialization being moved to KVM module load instead of PSP driver probe, the implied SEV INIT actually makes sense and gets used and additionally to maintain SEV platform state consistency before and after the ioctl SEV shutdown needs to be done after the firmware call. It is important to do SEV Shutdown here with the SEV/SNP initialization moving to KVM, an implicit SEV INIT here as part of the SEV ioctls not followed with SEV Shutdown will cause SEV to remain in INIT state and then a future SNP INIT in KVM module load will fail. Also ensure that for these SEV ioctls both implicit SNP and SEV INIT is done followed by both SEV and SNP shutdown as RMP table must be initialized before calling SEV INIT if SNP host support is enabled. Similarly, prior to this patch, SNP has always been initialized before these ioctls as SNP initialization is done as part of PSP module probe, therefore, to keep a consistent behavior, SNP init needs to be done here implicitly as part of these ioctls followed with SNP shutdown before returning from the ioctl to maintain the consistent platform state before and after the ioctl. Suggested-by: Tom Lendacky Reviewed-by: Tom Lendacky Signed-off-by: Ashish Kalra Signed-off-by: Herbert Xu Stable-dep-of: dc8ccab15081 ("crypto: ccp - narrow scope of snp_range_list") Signed-off-by: Sasha Levin