kernel/linux.git/drivers/crypto, branch v6.6.134

crypto: caam - fix overflow on long hmac keys

2026-04-11T12:19:19+00:00

[ Upstream commit 80688afb9c35b3934ce2d6be9973758915e2e0ef ] When a key longer than block size is supplied, it is copied and then hashed into the real key. The memory allocated for the copy needs to be rounded to DMA cache alignment, as otherwise the hashed key may corrupt neighbouring memory. The copying is performed using kmemdup, however this leads to an overflow: reading more bytes (aligned_len - keylen) from the keylen source buffer. Fix this by replacing kmemdup with kmalloc, followed by memcpy. Fixes: 199354d7fb6e ("crypto: caam - Remove GFP_DMA and add DMA alignment padding") Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: caam - fix DMA corruption on long hmac keys

2026-04-11T12:19:19+00:00

[ Upstream commit 5ddfdcbe10dc5f97afc4e46ca22be2be717e8caf ] When a key longer than block size is supplied, it is copied and then hashed into the real key. The memory allocated for the copy needs to be rounded to DMA cache alignment, as otherwise the hashed key may corrupt neighbouring memory. The rounding was performed, but never actually used for the allocation. Fix this by replacing kmemdup with kmalloc for a larger buffer, followed by memcpy. Fixes: 199354d7fb6e ("crypto: caam - Remove GFP_DMA and add DMA alignment padding") Reported-by: Paul Bunyan Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

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

2026-03-25T10:05:57+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:36+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:00+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:00+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 - Move direct access to some PSP registers out of TEE

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

[ Upstream commit 949a0c8dd3c257730ef7205be759e4bc6cf49cea ] With the PSP mailbox registers supporting more than just TEE, access to them must be maintained and serialized by the PSP device support. Remove TEE support direct access and create an interface in the PSP support where the register access can be controlled/serialized. Signed-off-by: Tom Lendacky Signed-off-by: Mario Limonciello Reviewed-by: Rijo Thomas Tested-by: Rijo Thomas Signed-off-by: Herbert Xu 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:00+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: hisilicon/trng - support tfms sharing the device

2026-03-04T12:19:33+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: hisilicon/trng - modifying the order of header files

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

[ Upstream commit f5dd7c43022799ac5c4e3a0d445f9c293a198413 ] Header files is included Order-ref: standard library headers, OS library headers, and project-specific headers. This patch modifies the order of header files according to suggestions. In addition, use %u to print unsigned int variables to prevent overflow. Signed-off-by: Chenghai Huang Signed-off-by: Herbert Xu Stable-dep-of: 3d3135057ff5 ("crypto: hisilicon/trng - support tfms sharing the device") Signed-off-by: Sasha Levin