wireguard-linux/drivers/crypto/Kconfig, branch stable

crypto: qce - Mark QCE as BROKEN

2026-07-17T08:09:22Z

This driver is harmful: - It is much slower than the CPU [1] [2]. - It Has a history of bugs [2] [3]. - It does not have exclusive access to the hardware [4], causing races with the secure world. - It register its implementations with too low a cra_priority for them to be actually used [5]. Therefore, disable it to ensure that nobody builds it into kernels they intend to ship. In the future, the driver will be used for processing restricted media content. However, the kernel does not currently support this. Since the driver will have future uses, allow building it if COMPILE_TEST is enabled. [1]: https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org/ [2]: https://lore.kernel.org/r/20250615031807.GA81869@sol/ [3]: https://lore.kernel.org/r/20260706-qce-fix-self-tests-v5-0-86f461ff1829@oss.qualcomm.com/ [4]: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-0-56f67da84c05@oss.qualcomm.com/ [5]: https://lore.kernel.org/r/20260524204537.GB110177@quark/ Fixes: ec8f5d8f6f76 ("crypto: qce - Qualcomm crypto engine driver") Signed-off-by: Demi Marie Obenour Acked-by: Eric Biggers Signed-off-by: Herbert Xu

hwrng: qcom - Move qcom-rng.c into drivers/char/hw_random/

2026-07-05T05:22:35Z

Since this file just implements a hwrng driver, move it into drivers/char/hw_random/. Rename the kconfig option accordingly as well. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: qcom-rng - Remove crypto_rng interface

2026-07-05T05:19:52Z

qcom-rng.c exposes the same hardware through two completely separate interfaces, crypto_rng and hwrng. However, the implementation of this is buggy because it permits generation operations from these interfaces to run concurrently with each other, accessing the same registers. That is, qcom_rng_generate() synchronizes with itself but not with qcom_hwrng_read(). This results in potential repetition of output from the RNG, output of non-random values, etc. Fortunately, there's actually no point in hardware RNG drivers implementing the crypto_rng interface. It's not actually used by anything besides the "rng" algorithm type of AF_ALG, which in turn is not actually used in practice. Other crypto_rng hardware drivers are likewise being phased out, leaving just the hwrng support. Thus, remove it to simplify the code and avoid conflict (and confusion) with the hwrng interface which is the one that actually matters. Fixes: f29cd5bb64c2 ("crypto: qcom-rng - Add hw_random interface support") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Reviewed-by: Dmitry Baryshkov Signed-off-by: Herbert Xu

hwrng: xilinx - Move xilinx-rng into drivers/char/hw_random/

2026-06-12T01:56:26Z

Since this file just implements a hwrng driver, move it into drivers/char/hw_random/. Rename the kconfig option accordingly as well. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: xilinx-trng - Replace crypto_drbg_ctr_df() with HMAC-SHA512

2026-06-11T06:03:13Z

This code is just trying to condition 48 bytes of random data. This can be done easily using HKDF-SHA512-Extract, saving 300 lines of code. This commit also fixes forward security (in this particular case) by clearing the entropy from memory after it's used. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: xilinx-trng - Remove crypto_rng interface

2026-06-11T06:03:13Z

Implementing the crypto_rng interface has no purpose, as it isn't used in practice. It's being removed from other drivers too. Just remove it. This leaves hwrng, which is actually used. Tagging with 'Cc stable' due to the bugs that this removes: - xtrng_trng_generate() sometimes returned success even when it didn't fill in all the bytes. - It was possible for xtrng_trng_generate() and xtrng_hwrng_trng_read() to run concurrently and interfere with each other, as the locking code in xtrng_hwrng_trng_read() was broken. Fixes: 8979744aca80 ("crypto: xilinx - Add TRNG driver for Versal") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: exynos-rng - Remove exynos-rng driver

2026-06-11T06:03:13Z

This driver has no purpose. It doesn't feed into the Linux RNG, nor does it implement the hwrng interface. It is accessible only via the "rng" algorithm type of AF_ALG, which isn't used in practice. Everyone uses either the Linux RNG, or rarely /dev/hwrng. Moreover, this is a PRNG whose only source of entropy is the 160-bit seed the user passes in. So this can be used only by a user who already has a source of cryptographically secure random numbers, such as /dev/random. Which they can, and do, just use in the first place. Just remove this driver. There's no need to keep useless code around. Note that the other crypto_rng drivers in drivers/crypto/ are similarly unused and are being removed too. This commit just handles exynos-rng. Signed-off-by: Eric Biggers Acked-by: Krzysztof Kozlowski Signed-off-by: Herbert Xu

crypto: loongson - Remove broken and unused loongson-rng

2026-06-11T05:53:59Z

The loongson-rng rng_alg has several vulnerabilities, including not providing forward security, and a use-after-free bug due to the use of wait_for_completion_interruptible(). Meanwhile, the rng_alg framework doesn't really have any purpose in the first place other than to access the software algorithms crypto/drbg.c and crypto/jitterentropy.c. Hardware-specific rng_algs have no in-kernel user, and unlike hwrng there's no feed into the actual Linux RNG. As such, there's really no point to this code. There are of course other rng_alg drivers that are similarly unused, but they're similarly in the process of being phased out, e.g. https://lore.kernel.org/r/20260529193648.18172-1-ebiggers@kernel.org and https://lore.kernel.org/r/20260529220430.34135-1-ebiggers@kernel.org Given that, there's no point in fixing forward these vulnerabilities, and it makes much more sense to simply roll back the addition of this driver. If this platform provides TRNG (not PRNG) functionality, it could make sense to add a hwrng driver, but it would be quite different. Link: https://lore.kernel.org/linux-crypto/20260525145939.GC2018@quark/ Fixes: 766b2d724c8d ("crypto: loongson - add Loongson RNG driver support") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: crypto4xx - Remove insecure and unused rng_alg

2026-06-11T05:53:59Z

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 Acked-by: Christian Lamparter Signed-off-by: Herbert Xu

crypto: omap-des - add COMPILE_TEST and fix CONFIG_OF=n build

2026-05-22T12:25:30Z

CRYPTO_DEV_OMAP_DES only depends on ARCH_OMAP2PLUS, which is ARM-only and selects OF via ARM's USE_OF, making any non-OF code unreachable. Add COMPILE_TEST so the driver can be built with CONFIG_OF=n, making the non-OF code reachable. Fix the resulting non-OF build failures: - omap_des_irq() was defined inside a CONFIG_OF block, but is referenced unconditionally from omap_des_probe(). Move the CONFIG_OF guard so it only covers omap_des_get_of(). - The non-OF omap_des_get_of() stub took a struct device *, while omap_des_probe() passes a struct platform_device *. Make the stub prototype match the OF implementation and the caller. Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu