summaryrefslogtreecommitdiff
path: root/drivers/crypto
AgeCommit message (Collapse)AuthorFilesLines
2026-07-24crypto: qat - validate RSA CRT component lengthsGiovanni Cabiddu1-5/+5
[ Upstream commit b3ac78756588059729b9195fcc9f4b37d54057a5 ] The generic RSA key parser (rsa_helper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt() allocates half-size DMA buffers (key_sz / 2) and right-aligns each component with: memcpy(dst + half_key_sz - len, src, len) When a CRT component is larger than half_key_sz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption. Add a len > half_key_sz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds. Fixes: 879f77e9071f ("crypto: qat - Add RSA CRT mode") Cc: stable@vger.kernel.org Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Ahsan Atta <ahsan.atta@intel.com> Reviewed-by: Laurent M Coquerel <laurent.m.coquerel@intel.com> Tested-by: Laurent M Coquerel <laurent.m.coquerel@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24crypto: qat - fix restarting state leak on allocation failureAhsan Atta1-3/+4
[ Upstream commit 7d3ed20f7e46b3e991936fedd7a28f3ff4aec8d2 ] In adf_dev_aer_schedule_reset(), ADF_STATUS_RESTARTING is set before allocating reset_data. If the allocation fails, the function returns -ENOMEM without queuing reset work, so nothing ever clears the bit. This leaves the device permanently stuck in the restarting state, causing all subsequent reset attempts to be silently skipped. Fix this by using test_and_set_bit() to atomically claim the RESTARTING state, preventing duplicate reset scheduling races under concurrent fatal error reporting. If the subsequent allocation fails, clear the bit to restore clean state so future reset attempts can proceed. Cc: stable@vger.kernel.org Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework") Signed-off-by: Ahsan Atta <ahsan.atta@intel.com> Co-developed-by: Maksim Lukoshkov <maksim.lukoshkov@intel.com> Signed-off-by: Maksim Lukoshkov <maksim.lukoshkov@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204AThorsten Blum1-7/+12
[ Upstream commit ea5e57cc97185329dcc5ebdcaae7e1500bf0ad0b ] Commit 8006aff15516 ("crypto: atmel-sha204a - Set hwrng quality to lowest possible") reduced the hwrng quality to 1 based on a review by Bill Cox [1]. However, despite its title, the review only tested the ATSHA204, not the ATSHA204A. In the same thread, Atmel engineer Landon Cox wrote "this behavior has been eliminated entirely"[2] in the ATSHA204A and "this problem does not affect the ATECC108 or the ATECC108A (or the ATSHA204A)"[3]. According to the official ATSHA204A datasheet [4], the device contains a high-quality hardware RNG that combines its output with an internal seed value stored in EEPROM or SRAM to generate random numbers. The device also implements all security functions using SHA-256, and the driver uses the chip's Random command in seed-update mode. Keep 'quality = 1' for ATSHA204, but drop the explicit hwrng quality reduction for ATSHA204A and fall back to the hwrng core default. [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html [2] https://www.metzdowd.com/pipermail/cryptography/2014-December/023852.html [3] https://www.metzdowd.com/pipermail/cryptography/2014-December/023886.html [4] https://ww1.microchip.com/downloads/en/DeviceDoc/ATSHA204A-Data-Sheet-40002025A.pdf Fixes: 8006aff15516 ("crypto: atmel-sha204a - Set hwrng quality to lowest possible") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24crypto: atmel - Drop explicit initialization of struct ↵Uwe Kleine-König1-1/+1
i2c_device_id::driver_data to 0 [ Upstream commit d86ad3911a5d4549297ed810ee450e5772fd665f ] These drivers don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Stable-dep-of: ea5e57cc9718 ("crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24crypto: atmel-sha204a - Mark OF related data as maybe unusedKrzysztof Kozlowski1-2/+4
[ Upstream commit 75f3d950054389e2556277e42170e37dd97cd872 ] The driver can be compile tested with !CONFIG_OF making certain data unused: drivers/crypto/atmel-sha204a.c:129:34: error: ‘atmel_sha204a_dt_ids’ defined but not used [-Werror=unused-const-variable=] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Stable-dep-of: ea5e57cc9718 ("crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()Giovanni Cabiddu5-8/+76
[ Upstream commit 277281c10c63791067d24d421f7c43a15faa9096 ] The VF2PF interrupt handler queues PF-side response work that stores a raw pointer to per-VF state (struct adf_accel_vf_info). Currently, adf_disable_sriov() destroys per-VF mutexes and frees vf_info without stopping new VF2PF work or waiting for in-flight workers to complete. A concurrently scheduled or already queued worker can then dereference freed memory. This manifests as a use-after-free when KASAN is enabled: BUG: KASAN: null-ptr-deref in mutex_lock+0x76/0xe0 Write of size 8 at addr 0000000000000260 by task kworker/24:2/... Workqueue: qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat] Call Trace: kasan_report+0x119/0x140 mutex_lock+0x76/0xe0 adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat] adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat] adf_iov_send_resp+0x8c/0xe0 [intel_qat] process_one_work+0x6ac/0xfd0 worker_thread+0x4dd/0xd30 kthread+0x326/0x410 ret_from_fork+0x33b/0x670 Add a PF-local flag, vf2pf_disabled, that gates work queueing, worker processing, and interrupt re-enabling during teardown. Set this flag atomically with the hardware interrupt mask inside adf_disable_all_vf2pf_interrupts(). After masking, synchronize the AE cluster MSI-X interrupt and flush the PF response workqueue before tearing down per-VF locks and state so all in-flight work completes before vf_info is destroyed. Introduce adf_enable_all_vf2pf_interrupts() to clear the flag and unmask all VF2PF interrupts under the same lock when SR-IOV is re-enabled. This ensures the software flag and hardware state transition atomically on both the enable and disable paths. Cc: stable@vger.kernel.org Fixes: ed8ccaef52fa ("crypto: qat - Add support for SRIOV") Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Ahsan Atta <ahsan.atta@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24crypto: crypto4xx - Remove insecure and unused rng_algEric Biggers3-102/+0
commit 7811ec9e973d2c9e465083699f0c8240b98cb8c4 upstream. Remove crypto4xx_rng, as it is insecure and unused: - It has only a 64-bit security strength, which is highly inadequate. This can be seen by the fact that crypto4xx_hw_init() seeds it with only 64 bits of entropy, and the fact that the original commit mentions that it implements ANSI X9.17 Annex C. Another issue was that this driver didn't implement the crypto_rng API correctly, as crypto4xx_prng_generate() didn't return 0 on success. - No user of this code is known. It's usable only theoretically via the "rng" algorithm type of AF_ALG. But userspace actually just uses the actual Linux RNG (/dev/random etc) instead. And rng_algs don't contribute entropy to the actual Linux RNG either. (This may have been confused with hwrng, which does contribute entropy.) Fixes: d072bfa48853 ("crypto: crypto4xx - add prng crypto support") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24crypto: crypto4xx - Remove ahash-related codeHerbert Xu3-155/+1
commit 97855e7f1ccf4917f305baab199edb9f2595ff5b upstream. The hash implementation in crypto4xx has been disabled since 2009. As nobody has tried to fix this remove all the dead code. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24crypto: amcc - fix incorrect kernel-doc comment syntax in filesAditya Srivastava6-31/+31
commit 73f04d3d800f3c8058bb00447e3e1c4cdc85a2b0 upstream. The opening comment mark '/**' is used for highlighting the beginning of kernel-doc comments. There are certain files in drivers/crypto/amcc, which follow this syntax, but the content inside does not comply with kernel-doc. Such lines were probably not meant for kernel-doc parsing, but are parsed due to the presence of kernel-doc like comment syntax(i.e, '/**'), which causes unexpected warnings from kernel-doc. E.g., presence of kernel-doc like comment in drivers/crypto/amcc/crypto4xx_alg.c at header, and some other lines, causes these warnings by kernel-doc: "warning: expecting prototype for AMCC SoC PPC4xx Crypto Driver(). Prototype was for set_dynamic_sa_command_0() instead" "warning: Function parameter or member 'dir' not described in 'set_dynamic_sa_command_0'" etc.. Provide a simple fix by replacing such occurrences with general comment format, i.e. '/*', to prevent kernel-doc from parsing it. Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24crypto: cavium/cpt - fix DMA cleanup using wrong loop indexFelix Gu1-2/+2
[ Upstream commit 9dbf173bd32d5f81b005008b682bfb50aa093455 ] The sg_cleanup error path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one. Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-07-24crypto: marvell/octeontx - fix DMA cleanup using wrong loop indexFelix Gu1-2/+2
[ Upstream commit 7891c64c0520519782470ba29bac8a5761e295d8 ] The sg_cleanup path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one. Fixes: 10b4f09491bf ("crypto: marvell - add the Virtual Function driver for CPT") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-07-24crypto: ccp - Treat zero-length cert chain as query for blob lengthsSean Christopherson1-1/+2
[ Upstream commit ef8c9dacda2871accd64e3eda951fef6b788b1ea ] When handling a PDH export, treat a zero-length userspace cert chain buffer as a request to query the length of the relevant blobs. Failure to account for the zero-length buffer trips a BUG_ON() when running with CONFIG_DEBUG_VIRTUAL=y due to trying to get the physical address of the ZERO_SIZE_PTR (returned by kzalloc() on the bogus allocation). kernel BUG at arch/x86/mm/physaddr.c:28 ! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 30 UID: 0 PID: 28580 Comm: syz.2.18 Kdump: loaded Tainted: G W 6.18.16-smp-DEV #1 NONE Tainted: [W]=WARN Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 RIP: 0010:__phys_addr+0x16a/0x180 arch/x86/mm/physaddr.c:28 RSP: 0018:ffffc9008329fc80 EFLAGS: 00010293 RAX: ffffffff8179110a RBX: 0000778000000010 RCX: ffff8884e6992600 RDX: 0000000000000000 RSI: 0000000080000010 RDI: 0000778000000010 RBP: ffffc9008329fdf0 R08: 0000000000000dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff126d297 R12: dffffc0000000000 R13: 1ffff92010653fc8 R14: 0000000080000010 R15: dffffc0000000000 FS: 0000555556bec9c0(0000) GS:ffff88aa4ce1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd3159e7000 CR3: 00000004fbc44000 CR4: 0000000000350ef0 Call Trace: <TASK> [<ffffffff853d3869>] sev_ioctl_do_pdh_export+0x559/0x7a0 drivers/crypto/ccp/sev-dev.c:2308 [<ffffffff853d1fdd>] sev_ioctl+0x2cd/0x480 drivers/crypto/ccp/sev-dev.c:2556 [<ffffffff82549ebc>] vfs_ioctl fs/ioctl.c:52 [inline] [<ffffffff82549ebc>] __do_sys_ioctl fs/ioctl.c:598 [inline] [<ffffffff82549ebc>] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:584 [<ffffffff8630115f>] do_syscall_x64 arch/x86/entry/syscall_64.c:64 [inline] [<ffffffff8630115f>] do_syscall_64+0x9f/0xf40 arch/x86/entry/syscall_64.c:98 [<ffffffff81000136>] entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fd3158eac39 </TASK> Thankfully, the bug is benign outside of CONFIG_DEBUG_VIRTUAL=y as getting the physical address is just arithmetic, and the PSP errors out before trying to write to the garbage address (which it must, otherwise querying the blob lengths would clobber memory at pfn=0). Fixes: 76a2b524a4b1 ("crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command") Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-07-24crypto: atmel-sha204a - fix blocking and non-blocking rng logicLothar Rubusch1-4/+4
[ Upstream commit 319400fc5ee15db5793aa45f854968141326effc ] The blocking and non-blocking paths were failing to provide valid entropy due to improper buffer management. Reading the buffer starting from byte 1, only fetch the 32 bytes of random data from the return message. Tested on an Atmel SHA204A device. Before (here for blocking), tests showed repeatedly reading reduced bytes. $ head -c 32 /dev/hwrng | hexdump -C 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 After, the result will be similar to the following: $ head -c 32 /dev/hwrng | hexdump -C 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i| 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.| 00000020 Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator") Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Tested-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-07-24crypto: talitos - use dma_sync_single_for_cpu() before reading descriptor headerPaul Louvel1-7/+19
commit e17ff3d6ff907dc8406261e8fd3e1fc8a908f0f6 upstream. In order to know if a descriptor has been processed by the device, the driver polls the FIFO to see if DESC_HDR_DONE is set on a descriptor header to confirm completion. The current code does not make sure that the CPU gets up to date data before reading the descriptor. Fix this by calling dma_sync_single_for_cpu() before reading memory written by the device. Cc: stable@vger.kernel.org Fixes: 58cdbc6d2263 ("crypto: talitos - fix hash on SEC1.") Signed-off-by: Paul Louvel <paul.louvel@bootlin.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24crypto: caam - use print_hex_dump_devel to guard key hex dumps againThorsten Blum1-6/+6
commit 8005dc808bcce7d6cc2ae015a3cde1683bee602d upstream. Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled. Fixes: 8d818c105501 ("crypto: caam/qi2 - add DPAA2-CAAM driver") Fixes: 226853ac3ebe ("crypto: caam/qi2 - add skcipher algorithms") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24crypto: caam - use print_hex_dump_devel to guard key hex dumpsThorsten Blum4-16/+16
commit 3f57657b6ea23f933371f2c2846322f441773cee upstream. Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() and gen_split_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled. Fixes: 6e005503199b ("crypto: caam - print debug messages at debug level") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-24crypto: amlogic - avoid double cleanup in meson_crypto_probe()Dawei Feng1-1/+1
commit 6d827ade51a24e18d81afb9f32756d339520a14c upstream. When meson_allocate_chanlist() fails after a partial allocation, it already unwinds the allocated chanlist state through its local error path. meson_crypto_probe() then jump to error_flow and calls meson_free_chanlist() again, causing the same per-flow resources to be torn down twice. In the reproduced failure path, the second teardown re-entered crypto_engine_exit() on an already destroyed worker and KASAN reported a slab-use-after-free in kthread_destroy_worker(). Prevent double-free by handling partial allocation failures locally within meson_allocate_chanlist() and skipping the outer cleanup path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. The bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1, using the reproducer under tools/testing/meson_crypto_probe. The reproducer forces the second dma_alloc_attrs() call in the gxl-crypto probe path to return NULL, making meson_allocate_chanlist() fail after partial initialization. On the unpatched kernel this reliably triggered a slab-use-after-free. With this fix applied, the same reproducer no longer emits any KASAN report and the probe fails cleanly with -ENOMEM. ================================================================== BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0 Read of size 8 at addr ff1100010c057a68 by task insmod/265 CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G O 7.1.0-rc2-00376-g810af9adc907-dirty #10 PREEMPT(lazy) Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? kthread_destroy_worker+0xb2/0xd0 ? kthread_destroy_worker+0xb2/0xd0 kasan_report+0xca/0x100 ? kthread_destroy_worker+0xb2/0xd0 kthread_destroy_worker+0xb2/0xd0 meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto] platform_probe+0x99/0x140 really_probe+0x1c6/0x6a0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x248/0x310 ? acpi_driver_match_device+0xb0/0x100 driver_probe_device+0x48/0x210 ? __pfx___device_attach_driver+0x10/0x10 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x104/0x190 ? __pfx_bus_for_each_drv+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 __device_attach+0x19d/0x3b0 ? __pfx___device_attach+0x10/0x10 ? do_raw_spin_unlock+0x53/0x220 device_initial_probe+0x78/0xa0 bus_probe_device+0x5b/0x130 device_add+0xcfd/0x1430 ? __pfx_device_add+0x10/0x10 ? insert_resource+0x34/0x50 ? lock_release+0xc9/0x290 platform_device_add+0x24e/0x590 ? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro] meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro] do_one_initcall+0xc0/0x450 ? __pfx_do_one_initcall+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 ? __create_object+0x59/0x80 ? kasan_unpoison+0x27/0x60 do_init_module+0x27b/0x7d0 ? __pfx_do_init_module+0x10/0x10 ? kasan_quarantine_put+0x84/0x1d0 ? kfree+0x32c/0x510 ? load_module+0x561e/0x5ff0 load_module+0x54fe/0x5ff0 ? __pfx_load_module+0x10/0x10 ? security_file_permission+0x20/0x40 ? kernel_read_file+0x23d/0x6e0 ? mmap_region+0x235/0x4a0 ? __pfx_kernel_read_file+0x10/0x10 ? __file_has_perm+0x2c0/0x3e0 init_module_from_file+0x158/0x180 ? __pfx_init_module_from_file+0x10/0x10 ? __lock_acquire+0x45a/0x1ba0 ? idempotent_init_module+0x315/0x610 ? lock_release+0xc9/0x290 ? lockdep_init_map_type+0x4b/0x220 ? do_raw_spin_unlock+0x53/0x220 idempotent_init_module+0x330/0x610 ? __pfx_idempotent_init_module+0x10/0x10 ? __pfx_cred_has_capability.isra.0+0x10/0x10 ? ksys_mmap_pgoff+0x385/0x520 __x64_sys_finit_module+0xbe/0x120 do_syscall_64+0x115/0x690 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7d6d31690d Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f3 b4 0f 00 f7 d8 > RSP: 002b:00007fffc027ac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000055f7b81967c0 RCX: 00007f7d6d31690d RDX: 0000000000000000 RSI: 000055f79a0d6cd2 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000246 R12: 000055f79a0d6cd2 R13: 000055f7b8196790 R14: 000055f79a0d5888 R15: 000055f7b81968e0 </TASK> Fixes: 48fe583fe541 ("crypto: amlogic - Add crypto accelerator for amlogic GXL") Cc: stable@vger.kernel.org Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-04crypto: qat - remove unused character device and IOCTLsGiovanni Cabiddu5-549/+3
[ Upstream commit d237230728c567297f2f98b425d63156ab2ed17f ] The QAT driver exposes a character device (qat_adf_ctl) with IOCTLs for device configuration, start, stop, status query and enumeration. These IOCTLs are not part of any public uAPI header and have no known in-tree or out-of-tree users. Device lifecycle is already managed via sysfs. The ioctl interface also increases the attack surface and is the subject of a number of bug reports. Remove the character device, the IOCTL definitions, and the related data structures (adf_dev_status_info, adf_user_cfg_key_val, adf_user_cfg_section, adf_user_cfg_ctl_data). Drop the now-unused adf_cfg_user.h header and strip adf_ctl_drv.c down to the minimal module_init/module_exit hooks for workqueue, AER, and crypto/compression algorithm registration. Clean up leftover dead code that was only reachable from the removed IOCTL paths: adf_cfg_del_all(), adf_devmgr_verify_id(), adf_devmgr_get_num_dev(), adf_devmgr_get_dev_by_id(), adf_get_vf_real_id() and the unused ADF_CFG macros. Additionally, drop the entry associated to QAT IOCTLs in ioctl-number.rst. Cc: stable@vger.kernel.org Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework") Reported-by: Zhi Wang <wangzhi@stu.xidian.edu.cn> Reported-by: Bin Yu <byu@xidian.edu.cn> Reported-by: MingYu Wang <w15303746062@163.com> Closes: https://lore.kernel.org/all/61d6d499.ab89.19b9b7f3186.Coremail.wangzhi_xd@stu.xidian.edu.cn/ Link: https://lore.kernel.org/all/20260508034841.256794-1-w15303746062@163.com/ Link: https://lore.kernel.org/all/20260508023542.256299-1-w15303746062@163.com/ Link: https://lore.kernel.org/all/20260504025120.98242-1-w15303746062@163.com/ Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Ahsan Atta <ahsan.atta@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-07-04crypto: qat - Return pointer directly in adf_ctl_alloc_resourcesHerbert Xu1-18/+13
[ Upstream commit 5ce9891ea928208a915411ce8227f8c3e37e5ad9 ] Returning values through arguments is confusing and that has upset the compiler with the recent change to memdup_user: ../drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c: In function ‘adf_ctl_ioctl’: ../drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c:308:26: warning: ‘ctl_data’ may be used uninitialized [-Wmaybe-uninitialized] 308 | ctl_data->device_id); | ^~ ../drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c:294:39: note: ‘ctl_data’ was declared here 294 | struct adf_user_cfg_ctl_data *ctl_data; | ^~~~~~~~ In function ‘adf_ctl_ioctl_dev_stop’, inlined from ‘adf_ctl_ioctl’ at ../drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c:386:9: ../drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c:273:48: warning: ‘ctl_data’ may be used uninitialized [-Wmaybe-uninitialized] 273 | ret = adf_ctl_is_device_in_use(ctl_data->device_id); | ~~~~~~~~^~~~~~~~~~~ ../drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c: In function ‘adf_ctl_ioctl’: ../drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c:261:39: note: ‘ctl_data’ was declared here 261 | struct adf_user_cfg_ctl_data *ctl_data; | ^~~~~~~~ In function ‘adf_ctl_ioctl_dev_config’, inlined from ‘adf_ctl_ioctl’ at ../drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c:382:9: ../drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c:192:54: warning: ‘ctl_data’ may be used uninitialized [-Wmaybe-uninitialized] 192 | accel_dev = adf_devmgr_get_dev_by_id(ctl_data->device_id); | ~~~~~~~~^~~~~~~~~~~ ../drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c: In function ‘adf_ctl_ioctl’: ../drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c:185:39: note: ‘ctl_data’ was declared here 185 | struct adf_user_cfg_ctl_data *ctl_data; | ^~~~~~~~ Fix this by returning the pointer directly. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Thorsten Blum <thorsten.blum@linux.dev> Acked-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Stable-dep-of: d237230728c5 ("crypto: qat - remove unused character device and IOCTLs") Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-07-04crypto: qat - Replace kzalloc() + copy_from_user() with memdup_user()Thorsten Blum1-10/+3
[ Upstream commit 1e26339703e2afd397037defa798682b2b93dcc0 ] Replace kzalloc() followed by copy_from_user() with memdup_user() to improve and simplify adf_ctl_alloc_resources(). memdup_user() returns either -ENOMEM or -EFAULT (instead of -EIO) if an error occurs. Remove the unnecessary device id initialization, since memdup_user() (like copy_from_user()) immediately overwrites it. No functional changes intended other than returning the more idiomatic error code -EFAULT. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Stable-dep-of: d237230728c5 ("crypto: qat - remove unused character device and IOCTLs") Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-06-19crypto: caam - guard HMAC key hex dumps in hash_digest_keyThorsten Blum2-4/+4
[ Upstream commit 177730a273b18e195263ed953853273e901b5064 ] Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in hash_digest_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled. Fixes: 045e36780f11 ("crypto: caam - ahash hmac support") Fixes: 3f16f6c9d632 ("crypto: caam/qi2 - add support for ahash algorithms") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-01crypto: ccp - copy IV using skcipher ivsizePaul Moses1-2/+5
[ Upstream commit a7a1f3cdd64d8a165d9b8c9e9ad7fb46ac19dfc4 ] AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver. ccp_aes_complete() restores AES_BLOCK_SIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer. Use crypto_skcipher_ivsize() to copy only the algorithm's IV length. Fixes: 2b789435d7f3 ("crypto: ccp - CCP AES crypto API support") Signed-off-by: Paul Moses <p@1g4.org> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-06-01crypto: sa2ul - Fix AEAD fallback algorithm namesT Pratham1-2/+2
[ Upstream commit 8451ab6ad686ffdcdf9ddadaa446a79ab48e5590 ] For authenc AEAD algorithms, sa2ul is trying to register very specific -ce version as a fallback. This causes registration failure on SoCs which do not have ARMv8-CE enabled/available. Change the fallback algorithm from the specific driver name to generic algorithm name so that the kernel can allocate any available fallback. Fixes: d2c8ac187fc92 ("crypto: sa2ul - Add AEAD algorithm support") Signed-off-by: T Pratham <t-pratham@ti.com> Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-06-01crypto: atmel-tdes - fix DMA sync directionThorsten Blum1-4/+4
commit c8a9a647532f5c2a04180352693215e24e9dba03 upstream. Before DMA output is consumed by the CPU, ->dma_addr_out must be synced with dma_sync_single_for_cpu() instead of dma_sync_single_for_device(). Using the wrong direction can return stale cache data on non-coherent platforms. Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver") Fixes: 1f858040c2f7 ("crypto: atmel-tdes - add support for latest release of the IP (0x700)") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-01crypto: ccree - fix a memory leak in cc_mac_digest()Haoxiang Li1-0/+1
commit 02c64052fad03699b9c6d1df2f9b444d17e4ac50 upstream. Add cc_unmap_result() if cc_map_hash_request_final() fails to prevent potential memory leak. Fixes: 63893811b0fc ("crypto: ccree - add ahash support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-01crypto: hisilicon - Fix dma_unmap_single() directionThomas Fourier1-1/+1
commit 1ee57ab93b75eb59f426aef37b5498a7ffc28278 upstream. The direction used to map the buffer skreq->iv is DMA_TO_DEVICE but it is unmapped with direction DMA_BIDIRECTIONAL in the error path. Change the unmap to match the mapping. Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver") Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Reviewed-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-01crypto: atmel-ecc - Release client on allocation failureThorsten Blum1-0/+1
commit 095d50008d55d13f8fcf1bbeb7c6eba51779bc85 upstream. Call atmel_ecc_i2c_client_free() to release the I2C client reserved by atmel_ecc_i2c_client_alloc() when crypto_alloc_kpp() fails. Otherwise ->tfm_count will be out of sync. Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-01crypto: atmel-aes - Fix 3-page memory leak in atmel_aes_buff_cleanupThorsten Blum1-1/+1
commit 3fcfff4ed35f963380a68741bcd52742baff7f76 upstream. atmel_aes_buff_init() allocates 4 pages using __get_free_pages() with ATMEL_AES_BUFFER_ORDER, but atmel_aes_buff_cleanup() frees only the first page using free_page(), leaking the remaining 3 pages. Use free_pages() with ATMEL_AES_BUFFER_ORDER to fix the memory leak. Fixes: bbe628ed897d ("crypto: atmel-aes - improve performances of data transfer") Cc: stable@vger.kernel.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-01crypto: ccp: Don't attempt to copy ID to userspace if PSP command failedSean Christopherson1-0/+3
commit 4f685dbfa87c546e51d9dc6cab379d20f275e114 upstream. When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error. Reported-by: Alexander Potapenko <glider@google.com> Reported-by: Sebastian Alba Vives <sebasjosue84@gmail.com> Fixes: d6112ea0cb34 ("crypto: ccp - introduce SEV_GET_ID2 command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-01crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failedSean Christopherson1-1/+7
commit e76239fed3cffd6d304d8ca3ce23984fd24f57d3 upstream. When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error. Reported-by: Alexander Potapenko <glider@google.com> Reported-by: Sebastian Alba Vives <sebasjosue84@gmail.com> Fixes: 76a2b524a4b1 ("crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-01crypto: ccp: Don't attempt to copy CSR to userspace if PSP command failedSean Christopherson1-1/+7
commit abe4a6d6f606113251868c2c4a06ba904bb41eed upstream. When retrieving the PEK CSR, don't attempt to copy the blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405 CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: <TASK> dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pek_csr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sev_ioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error. Reported-by: Alexander Potapenko <glider@google.com> Reported-by: Sebastian Alba Vives <sebasjosue84@gmail.com> Fixes: e799035609e1 ("crypto: ccp: Implement SEV_PEK_CSR ioctl command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-18crypto: atmel-sha204a - Fix OOM ->tfm_count leakThorsten Blum1-2/+3
[ 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 <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> [ adapted kmalloc_obj() macro to kmalloc(sizeof()) ] Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-04crypto: ccp - Add an S4 restore flowMario Limonciello (AMD)6-1/+47
[ 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 <lars.francke@gmail.com> Closes: https://lore.kernel.org/platform-driver-x86/CAD-Ua_gfJnQSo8ucS_7ZwzuhoBRJ14zXP7s8b-zX3ZcxcyWePw@mail.gmail.com/ Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260116041132.153674-4-superm1@kernel.org Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04crypto: octeontx - fix dma_free_coherent() sizeThomas Fourier1-1/+2
[ Upstream commit 624a6760bf8464965c17c8df10b40b557eaa3002 ] The size of the buffer in alloc_command_queues() is curr->size + OTX_CPT_NEXT_CHUNK_PTR_SIZE, so used that length for dma_free_coherent(). Fixes: 10b4f09491bf ("crypto: marvell - add the Virtual Function driver for CPT") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04crypto: cavium - fix dma_free_coherent() sizeThomas Fourier1-1/+2
[ Upstream commit 941676c30ba5b40a01bed92448f457ce62fd1f07 ] The size of the buffer in alloc_command_queues() is curr->size + CPT_NEXT_CHUNK_PTR_SIZE, so used that length for dma_free_coherent(). Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-19crypto: virtio - Remove duplicated virtqueue_kick in ↵Bibo Mao1-2/+0
virtio_crypto_skcipher_crypt_req [ Upstream commit 14f86a1155cca1176abf55987b2fce7f7fcb2455 ] With function virtio_crypto_skcipher_crypt_req(), there is already virtqueue_kick() call with spinlock held in function __virtio_crypto_skcipher_do_req(). Remove duplicated virtqueue_kick() function call here. Fixes: d79b5d0bbf2e ("crypto: virtio - support crypto engine framework") Cc: stable@vger.kernel.org Signed-off-by: Bibo Mao <maobibo@loongson.cn> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-19crypto: virtio - Add spinlock protection with virtqueue notificationBibo Mao1-0/+5
commit b505047ffc8057555900d2d3a005d033e6967382 upstream. When VM boots with one virtio-crypto PCI device and builtin backend, run openssl benchmark command with multiple processes, such as openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32 openssl processes will hangup and there is error reported like this: virtio_crypto virtio0: dataq.0:id 3 is not a head! It seems that the data virtqueue need protection when it is handled for virtio done notification. If the spinlock protection is added in virtcrypto_done_task(), openssl benchmark with multiple processes works well. Fixes: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet") Cc: stable@vger.kernel.org Signed-off-by: Bibo Mao <maobibo@loongson.cn> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-19crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctlyKees Cook1-1/+1
commit 1562b1fb7e17c1b3addb15e125c718b2be7f5512 upstream. The existing allocation of scatterlists in omap_crypto_copy_sg_lists() was allocating an array of scatterlist pointers, not scatterlist objects, resulting in a 4x too small allocation. Use sizeof(*new_sg) to get the correct object size. Fixes: 74ed87e7e7f7 ("crypto: omap - add base support library for common routines") Signed-off-by: Kees Cook <kees@kernel.org> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-19crypto: octeontx - Fix length check to avoid truncation in ucode_load_storeThorsten Blum1-1/+1
commit 5565a72b24fa7935a9f30af386e92c8c9dfb23b9 upstream. OTX_CPT_UCODE_NAME_LENGTH limits the microcode name to 64 bytes. If a user writes a string of exactly 64 characters, the original code used 'strlen(buf) > 64' to check the length, but then strscpy() copies only 63 characters before adding a NUL terminator, silently truncating the copied string. Fix this off-by-one error by using 'count' directly for the length check to ensure long names are rejected early and copied without truncation. Cc: stable@vger.kernel.org Fixes: d9110b0b01ff ("crypto: marvell - add support for OCTEON TX CPT engine") Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-19crypto: ccree - Correctly handle return of sg_nents_for_lenHaotian Zhang1-1/+5
[ Upstream commit 8700ce07c5c6bf27afa7b59a8d9cf58d783a7d5c ] Fix error handling in cc_map_hash_request_update where sg_nents_for_len return value was assigned to u32, converting negative errors to large positive values before passing to sg_copy_to_buffer. Check sg_nents_for_len return value and propagate errors before assigning to areq_ctx->in_nents. Fixes: b7ec8530687a ("crypto: ccree - use std api when possible") Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-29crypto: rockchip - Fix dma_unmap_sg() nents valueThomas Fourier1-2/+1
[ Upstream commit 21140e5caf019e4a24e1ceabcaaa16bd693b393f ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: 57d67c6e8219 ("crypto: rockchip - rework by using crypto_engine") Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> [ removed unused rctx variable declaration since device pointer already came from tctx->dev->dev instead of rctx->dev ] Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-29crypto: atmel - Fix dma_unmap_sg() directionThomas Fourier1-1/+1
commit f5d643156ef62216955c119216d2f3815bd51cb1 upstream. It seems like everywhere in this file, dd->in_sg is mapped with DMA_TO_DEVICE and dd->out_sg is mapped with DMA_FROM_DEVICE. Fixes: 13802005d8f2 ("crypto: atmel - add Atmel DES/TDES driver") Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28crypto: qat - fix seq_file position update in adf_ring_next()Giovanni Cabiddu1-1/+3
[ Upstream commit 6908c5f4f066a0412c3d9a6f543a09fa7d87824b ] The `adf_ring_next()` function in the QAT debug transport interface fails to correctly update the position index when reaching the end of the ring elements. This triggers the following kernel warning when reading ring files, such as /sys/kernel/debug/qat_c6xx_<D:B:D:F>/transport/bank_00/ring_00: [27725.022965] seq_file: buggy .next function adf_ring_next [intel_qat] did not update position index Ensure that the `*pos` index is incremented before returning NULL when after the last element in the ring is found, satisfying the seq_file API requirements and preventing the warning. Fixes: a672a9dc872e ("crypto: qat - Intel(R) QAT transport code") Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Ahsan Atta <ahsan.atta@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-28crypto: img-hash - Fix dma_unmap_sg() nents valueThomas Fourier1-1/+1
[ Upstream commit 34b283636181ce02c52633551f594fec9876bec7 ] The dma_unmap_sg() functions should be called with the same nents as the dma_map_sg(), not the value the map function returned. Fixes: d358f1abbf71 ("crypto: img-hash - Add Imagination Technologies hw hash accelerator") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-28crypto: ccp - Fix crash when rebind ccp device for ccp.koMengbiao Xiong1-0/+3
[ Upstream commit 181698af38d3f93381229ad89c09b5bd0496661a ] When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding the ccp device causes the following crash: $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind [ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 204.978026] #PF: supervisor write access in kernel mode [ 204.979126] #PF: error_code(0x0002) - not-present page [ 204.980226] PGD 0 P4D 0 [ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI ... [ 204.997852] Call Trace: [ 204.999074] <TASK> [ 205.000297] start_creating+0x9f/0x1c0 [ 205.001533] debugfs_create_dir+0x1f/0x170 [ 205.002769] ? srso_return_thunk+0x5/0x5f [ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp] [ 205.005241] ccp5_init+0x8b2/0x960 [ccp] [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp] [ 205.007709] sp_init+0x5f/0x80 [ccp] [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp] [ 205.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376] local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x230 [ 205.013810] really_probe+0xed/0x380 [ 205.015024] __driver_probe_device+0x7e/0x160 [ 205.016240] device_driver_attach+0x2f/0x60 [ 205.017457] bind_store+0x7c/0xb0 [ 205.018663] drv_attr_store+0x28/0x40 [ 205.019868] sysfs_kf_write+0x5f/0x70 [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0 [ 205.022267] vfs_write+0x308/0x440 [ 205.023453] ksys_write+0x6d/0xe0 [ 205.024616] __x64_sys_write+0x1e/0x30 [ 205.025778] x64_sys_call+0x16ba/0x2150 [ 205.026942] do_syscall_64+0x56/0x1e0 [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 This patch sets ccp_debugfs_dir to NULL after destroying it in ccp5_debugfs_destroy, allowing the directory dentry to be recreated when rebinding the ccp device. Tested on AMD Ryzen 7 1700X. Fixes: 3cdbe346ed3f ("crypto: ccp - Add debugfs entries for CCP information") Signed-off-by: Mengbiao Xiong <xisme1998@gmail.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-28crypto: inside-secure - Fix `dma_unmap_sg()` nents valueThomas Fourier1-2/+6
[ Upstream commit cb7fa6b6fc71e0c801e271aa498e2f19e6df2931 ] The `dma_unmap_sg()` functions should be called with the same nents as the `dma_map_sg()`, not the value the map function returned. Fixes: c957f8b3e2e5 ("crypto: inside-secure - avoid unmapping DMA memory that was not mapped") Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com> Reviewed-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-28crypto: marvell/cesa - Fix engine load inaccuracyHerbert Xu2-3/+6
[ Upstream commit 442134ab30e75b7229c4bfc1ac5641d245cffe27 ] If an error occurs during queueing the engine load will never be decremented. Fix this by moving the engine load adjustment into the cleanup function. Fixes: bf8f91e71192 ("crypto: marvell - Add load balancing between engines") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27crypto: marvell/cesa - Do not chain submitted requestsHerbert Xu3-25/+39
commit 0413bcf0fc460a68a2a7a8354aee833293d7d693 upstream. This driver tries to chain requests together before submitting them to hardware in order to reduce completion interrupts. However, it even extends chains that have already been submitted to hardware. This is dangerous because there is no way of knowing whether the hardware has already read the DMA memory in question or not. Fix this by splitting the chain list into two. One for submitted requests and one for requests that have not yet been submitted. Only extend the latter. Reported-by: Klaus Kudielka <klaus.kudielka@gmail.com> Fixes: 85030c5168f1 ("crypto: marvell - Add support for chaining crypto requests in TDMA mode") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-27crypto: sun8i-ce - move fallback ahash_request to the end of the structOvidiu Panait1-1/+1
[ Upstream commit c822831b426307a6ca426621504d3c7f99765a39 ] 'struct ahash_request' has a flexible array at the end, so it must be the last member in a struct, to avoid overwriting other struct members. Therefore, move 'fallback_req' to the end of the 'sun8i_ce_hash_reqctx' struct. Fixes: 56f6d5aee88d ("crypto: sun8i-ce - support hash algorithms") Signed-off-by: Ovidiu Panait <ovidiu.panait.oss@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27crypto: marvell/cesa - Avoid empty transfer descriptorHerbert Xu1-1/+1
[ Upstream commit 1bafd82d9a40cf09c6c40f1c09cc35b7050b1a9f ] The user may set req->src even if req->nbytes == 0. If there is no data to hash from req->src, do not generate an empty TDMA descriptor. Fixes: db509a45339f ("crypto: marvell/cesa - add TDMA support") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-08-17 04:40:13 +0300