summaryrefslogtreecommitdiff
path: root/crypto
AgeCommit message (Collapse)Author
2022-05-19Merge tag 'v5.4.193' into update-to-2.3.7__5.4-2.3.x-imxPhilippe Schenker
This is the 5.4.193 stable release Conflicts: arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts drivers/edac/synopsys_edac.c drivers/mmc/host/sdhci-esdhc-imx.c drivers/mmc/host/sdhci.c drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c sound/soc/codecs/msm8916-wcd-analog.c
2022-04-15crypto: authenc - Fix sleep in atomic context in decrypt_tailHerbert Xu
[ Upstream commit 66eae850333d639fc278d6f915c6fc01499ea893 ] The function crypto_authenc_decrypt_tail discards its flags argument and always relies on the flags from the original request when starting its sub-request. This is clearly wrong as it may cause the SLEEPABLE flag to be set when it shouldn't. Fixes: 92d95ba91772 ("crypto: authenc - Convert to new AEAD interface") Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-15crypto: rsa-pkcs1pad - fix buffer overread in pkcs1pad_verify_complete()Eric Biggers
commit a24611ea356c7f3f0ec926da11b9482ac1f414fd upstream. Before checking whether the expected digest_info is present, we need to check that there are enough bytes remaining. Fixes: a49de377e051 ("crypto: Add hash param to pkcs1pad") Cc: <stable@vger.kernel.org> # v4.6+ Cc: Tadeusz Struk <tadeusz.struk@linaro.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-15crypto: rsa-pkcs1pad - restore signature length checkEric Biggers
commit d3481accd974541e6a5d6a1fb588924a3519c36e upstream. RSA PKCS#1 v1.5 signatures are required to be the same length as the RSA key size. RFC8017 specifically requires the verifier to check this (https://datatracker.ietf.org/doc/html/rfc8017#section-8.2.2). Commit a49de377e051 ("crypto: Add hash param to pkcs1pad") changed the kernel to allow longer signatures, but didn't explain this part of the change; it seems to be unrelated to the rest of the commit. Revert this change, since it doesn't appear to be correct. We can be pretty sure that no one is relying on overly-long signatures (which would have to be front-padded with zeroes) being supported, given that they would have been broken since commit c7381b012872 ("crypto: akcipher - new verify API for public key algorithms"). Fixes: a49de377e051 ("crypto: Add hash param to pkcs1pad") Cc: <stable@vger.kernel.org> # v4.6+ Cc: Tadeusz Struk <tadeusz.struk@linaro.org> Suggested-by: Vitaly Chikunov <vt@altlinux.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-15crypto: rsa-pkcs1pad - correctly get hash from source scatterlistEric Biggers
commit e316f7179be22912281ce6331d96d7c121fb2b17 upstream. Commit c7381b012872 ("crypto: akcipher - new verify API for public key algorithms") changed akcipher_alg::verify to take in both the signature and the actual hash and do the signature verification, rather than just return the hash expected by the signature as was the case before. To do this, it implemented a hack where the signature and hash are concatenated with each other in one scatterlist. Obviously, for this to work correctly, akcipher_alg::verify needs to correctly extract the two items from the scatterlist it is given. Unfortunately, it doesn't correctly extract the hash in the case where the signature is longer than the RSA key size, as it assumes that the signature's length is equal to the RSA key size. This causes a prefix of the hash, or even the entire hash, to be taken from the *signature*. (Note, the case of a signature longer than the RSA key size should not be allowed in the first place; a separate patch will fix that.) It is unclear whether the resulting scheme has any useful security properties. Fix this by correctly extracting the hash from the scatterlist. Fixes: c7381b012872 ("crypto: akcipher - new verify API for public key algorithms") Cc: <stable@vger.kernel.org> # v5.2+ Reviewed-by: Vitaly Chikunov <vt@altlinux.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-10Merge tag 'v5.4.160' into HEADDenys Drozdov
This is the 5.4.160 stable release
2021-11-17crypto: pcrypt - Delay write to padata->infoDaniel Jordan
[ Upstream commit 68b6dea802cea0dbdd8bd7ccc60716b5a32a5d8a ] These three events can race when pcrypt is used multiple times in a template ("pcrypt(pcrypt(...))"): 1. [taskA] The caller makes the crypto request via crypto_aead_encrypt() 2. [kworkerB] padata serializes the inner pcrypt request 3. [kworkerC] padata serializes the outer pcrypt request 3 might finish before the call to crypto_aead_encrypt() returns in 1, resulting in two possible issues. First, a use-after-free of the crypto request's memory when, for example, taskA writes to the outer pcrypt request's padata->info in pcrypt_aead_enc() after kworkerC completes the request. Second, the outer pcrypt request overwrites the inner pcrypt request's return code with -EINPROGRESS, making a successful request appear to fail. For instance, kworkerB writes the outer pcrypt request's padata->info in pcrypt_aead_done() and then taskA overwrites it in pcrypt_aead_enc(). Avoid both situations by delaying the write of padata->info until after the inner crypto request's return code is checked. This prevents the use-after-free by not touching the crypto request's memory after the next-inner crypto request is made, and stops padata->info from being overwritten. Fixes: 5068c7a883d16 ("crypto: pcrypt - Add pcrypt crypto parallelization wrapper") Reported-by: syzbot+b187b77c8474f9648fae@syzkaller.appspotmail.com Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-17crypto: ecc - fix CRYPTO_DEFAULT_RNG dependencyArnd Bergmann
[ Upstream commit 38aa192a05f22f9778f9420e630f0322525ef12e ] The ecc.c file started out as part of the ECDH algorithm but got moved out into a standalone module later. It does not build without CRYPTO_DEFAULT_RNG, so now that other modules are using it as well we can run into this link error: aarch64-linux-ld: ecc.c:(.text+0xfc8): undefined reference to `crypto_default_rng' aarch64-linux-ld: ecc.c:(.text+0xff4): undefined reference to `crypto_put_default_rng' Move the 'select CRYPTO_DEFAULT_RNG' statement into the correct symbol. Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm") Fixes: 4e6602916bc6 ("crypto: ecdsa - Add support for ECDSA signature verification") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20Merge tag 'v5.4.132' into 5.4-2.3.x-imxAndrey Zhizhikin
This is the 5.4.132 stable release Conflicts (manual resolve): - drivers/gpu/drm/rockchip/cdn-dp-core.c: Fix merge hiccup when integrating upstream commit 450c25b8a4c9c ("drm/rockchip: cdn-dp-core: add missing clk_disable_unprepare() on error in cdn_dp_grf_write()") - drivers/perf/fsl_imx8_ddr_perf.c: Port upstream commit 3fea9b708ae37 ("drivers/perf: fix the missed ida_simple_remove() in ddr_perf_probe()") manually to NXP version. Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
2021-07-14crypto: shash - avoid comparing pointers to exported functions under CFIArd Biesheuvel
[ Upstream commit 22ca9f4aaf431a9413dcc115dd590123307f274f ] crypto_shash_alg_has_setkey() is implemented by testing whether the .setkey() member of a struct shash_alg points to the default version, called shash_no_setkey(). As crypto_shash_alg_has_setkey() is a static inline, this requires shash_no_setkey() to be exported to modules. Unfortunately, when building with CFI, function pointers are routed via CFI stubs which are private to each module (or to the kernel proper) and so this function pointer comparison may fail spuriously. Let's fix this by turning crypto_shash_alg_has_setkey() into an out of line function. Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11Merge tag 'v5.4.118' into 5.4-2.3.x-imxAndrey Zhizhikin
This is the 5.4.118 stable release Conflicts (manual resolve): - drivers/mmc/core/core.c: - drivers/mmc/core/host.c: Fix merge fuzz for upstream commit 909a01b95120 ("mmc: core: Fix hanging on I/O during system suspend for removable cards") Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
2021-05-11crypto: rng - fix crypto_rng_reset() refcounting when !CRYPTO_STATSEric Biggers
commit 30d0f6a956fc74bb2e948398daf3278c6b08c7e9 upstream. crypto_stats_get() is a no-op when the kernel is compiled without CONFIG_CRYPTO_STATS, so pairing it with crypto_alg_put() unconditionally (as crypto_rng_reset() does) is wrong. Fix this by moving the call to crypto_stats_get() to just before the actual algorithm operation which might need it. This makes it always paired with crypto_stats_rng_seed(). Fixes: eed74b3eba9e ("crypto: rng - Fix a refcounting bug in crypto_rng_reset()") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-11crypto: api - check for ERR pointers in crypto_destroy_tfm()Ard Biesheuvel
[ Upstream commit 83681f2bebb34dbb3f03fecd8f570308ab8b7c2c ] Given that crypto_alloc_tfm() may return ERR pointers, and to avoid crashes on obscure error paths where such pointers are presented to crypto_destroy_tfm() (such as [0]), add an ERR_PTR check there before dereferencing the second argument as a struct crypto_tfm pointer. [0] https://lore.kernel.org/linux-crypto/000000000000de949705bc59e0f6@google.com/ Reported-by: syzbot+12cf5fbfdeba210a89dd@syzkaller.appspotmail.com Reviewed-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-21Merge tag 'v5.4.107' into 5.4-2.3.x-imxAndrey Zhizhikin
This is the 5.4.107 stable release Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
2021-03-20crypto: x86 - Regularize glue function prototypesKees Cook
commit 9c1e8836edbbaf3656bc07437b59c04be034ac4e upstream. The crypto glue performed function prototype casting via macros to make indirect calls to assembly routines. Instead of performing casts at the call sites (which trips Control Flow Integrity prototype checking), switch each prototype to a common standard set of arguments which allows the removal of the existing macros. In order to keep pointer math unchanged, internal casting between u128 pointers and u8 pointers is added. Co-developed-by: João Moreira <joao.moreira@intel.com> Signed-off-by: João Moreira <joao.moreira@intel.com> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: Ard Biesheuvel <ardb@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-07Merge tag 'v5.4.103' into 5.4-2.3.x-imxAndrey Zhizhikin
This is the 5.4.103 stable release Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
2021-03-07crypto: tcrypt - avoid signed overflow in byte countArd Biesheuvel
[ Upstream commit 303fd3e1c771077e32e96e5788817f025f0067e2 ] The signed long type used for printing the number of bytes processed in tcrypt benchmarks limits the range to -/+ 2 GiB, which is not sufficient to cover the performance of common accelerated ciphers such as AES-NI when benchmarked with sec=1. So switch to u64 instead. While at it, fix up a missing printk->pr_cont conversion in the AEAD benchmark. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04Merge tag 'v5.4.102' into 5.4-2.3.x-imxAndrey Zhizhikin
This is the 5.4.102 stable release Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
2021-03-04crypto: ecdh_helper - Ensure 'len >= secret.len' in decode_key()Daniele Alessandrelli
[ Upstream commit a53ab94eb6850c3657392e2d2ce9b38c387a2633 ] The length ('len' parameter) passed to crypto_ecdh_decode_key() is never checked against the length encoded in the passed buffer ('buf' parameter). This could lead to an out-of-bounds access when the passed length is less than the encoded length. Add a check to prevent that. Fixes: 3c4b23901a0c7 ("crypto: ecdh - Add ECDH software support") Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-01-12Merge tag 'v5.4.89' into 5.4-2.3.x-imxAndrey Zhizhikin
This is the 5.4.89 stable release Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
2021-01-12crypto: asym_tpm: correct zero out potential secretsGreg Kroah-Hartman
commit f93274ef0fe972c120c96b3207f8fce376231a60 upstream. The function derive_pub_key() should be calling memzero_explicit() instead of memset() in case the complier decides to optimize away the call to memset() because it "knows" no one is going to touch the memory anymore. Cc: stable <stable@vger.kernel.org> Reported-by: Ilil Blum Shem-Tov <ilil.blum.shem-tov@intel.com> Tested-by: Ilil Blum Shem-Tov <ilil.blum.shem-tov@intel.com> Link: https://lore.kernel.org/r/X8ns4AfwjKudpyfe@kroah.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-12crypto: ecdh - avoid buffer overflow in ecdh_set_secret()Ard Biesheuvel
commit 0aa171e9b267ce7c52d3a3df7bc9c1fc0203dec5 upstream. Pavel reports that commit 17858b140bf4 ("crypto: ecdh - avoid unaligned accesses in ecdh_set_secret()") fixes one problem but introduces another: the unconditional memcpy() introduced by that commit may overflow the target buffer if the source data is invalid, which could be the result of intentional tampering. So check params.key_size explicitly against the size of the target buffer before validating the key further. Fixes: 17858b140bf4 ("crypto: ecdh - avoid unaligned accesses in ecdh_set_secret()") Reported-by: Pavel Machek <pavel@denx.de> Cc: <stable@vger.kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-11Merge tag 'v5.4.87' into 5.4-2.3.x-imxAndrey Zhizhikin
This is the 5.4.87 stable release Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
2021-01-11Merge tag 'v5.4.73' into 5.4-2.3.x-imxAndrey Zhizhikin
This is the 5.4.73 stable release Conflicts: - arch/arm/boot/dts/imx6sl.dtsi: Commit [a1767c90194e2] in NXP tree is now covered with commit [5c4c2f437cead] from upstream. - drivers/gpu/drm/mxsfb/mxsfb_drv.c: Resolve merge hunk for patch [ed8b90d303cf0] from upstream - drivers/media/i2c/ov5640.c: Patch [aa4bb8b8838ff] in NXP tree is now covered by patches [79ec0578c7e0a] and [b2f8546056b35] from upstream. Changes from NXP patch [99aa4c8c18984] are covered in upstream version as well. - drivers/net/ethernet/freescale/fec_main.c: Fix merge fuzz for patch [9e70485b40c83] from upstream. - drivers/usb/cdns3/gadget.c: Keep NXP version of the file, upstream version is not compatible. - drivers/usb/dwc3/core.c: - drivers/usb/dwc3/core.h: Fix merge fuzz of patch [08045050c6bd2] together wth NXP patch [b30e41dc1e494] - sound/soc/fsl/fsl_sai.c: - sound/soc/fsl/fsl_sai.h: Commit [2ea70e51eb72a] in NXP tree is now covered with commit [1ad7f52fe6683] from upstream. Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
2020-12-30crypto: ecdh - avoid unaligned accesses in ecdh_set_secret()Ard Biesheuvel
commit 17858b140bf49961b71d4e73f1c3ea9bc8e7dda0 upstream. ecdh_set_secret() casts a void* pointer to a const u64* in order to feed it into ecc_is_key_valid(). This is not generally permitted by the C standard, and leads to actual misalignment faults on ARMv6 cores. In some cases, these are fixed up in software, but this still leads to performance hits that are entirely avoidable. So let's copy the key into the ctx buffer first, which we will do anyway in the common case, and which guarantees correct alignment. Cc: <stable@vger.kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30crypto: af_alg - avoid undefined behavior accessing salg_nameEric Biggers
commit 92eb6c3060ebe3adf381fd9899451c5b047bb14d upstream. Commit 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm names") made the kernel start accepting arbitrarily long algorithm names in sockaddr_alg. However, the actual length of the salg_name field stayed at the original 64 bytes. This is broken because the kernel can access indices >= 64 in salg_name, which is undefined behavior -- even though the memory that is accessed is still located within the sockaddr structure. It would only be defined behavior if the array were properly marked as arbitrary-length (either by making it a flexible array, which is the recommended way these days, or by making it an array of length 0 or 1). We can't simply change salg_name into a flexible array, since that would break source compatibility with userspace programs that embed sockaddr_alg into another struct, or (more commonly) declare a sockaddr_alg like 'struct sockaddr_alg sa = { .salg_name = "foo" };'. One solution would be to change salg_name into a flexible array only when '#ifdef __KERNEL__'. However, that would keep userspace without an easy way to actually use the longer algorithm names. Instead, add a new structure 'sockaddr_alg_new' that has the flexible array field, and expose it to both userspace and the kernel. Make the kernel use it correctly in alg_bind(). This addresses the syzbot report "UBSAN: array-index-out-of-bounds in alg_bind" (https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e). Reported-by: syzbot+92ead4eb8e26a26d465e@syzkaller.appspotmail.com Fixes: 3f69cc60768b ("crypto: af_alg - Allow arbitrarily long algorithm names") Cc: <stable@vger.kernel.org> # v4.12+ Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29crypto: algif_skcipher - EBUSY on aio should be an errorHerbert Xu
[ Upstream commit 2a05b029c1ee045b886ebf9efef9985ca23450de ] I removed the MAY_BACKLOG flag on the aio path a while ago but the error check still incorrectly interpreted EBUSY as success. This may cause the submitter to wait for a request that will never complete. Fixes: dad419970637 ("crypto: algif_skcipher - Do not set...") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29crypto: algif_aead - Do not set MAY_BACKLOG on the async pathHerbert Xu
commit cbdad1f246dd98e6c9c32a6e5212337f542aa7e0 upstream. The async path cannot use MAY_BACKLOG because it is not meant to block, which is what MAY_BACKLOG does. On the other hand, both the sync and async paths can make use of MAY_SLEEP. Fixes: 83094e5e9e49 ("crypto: af_alg - add async support to...") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-08Merge tag 'v5.4.70' into imx_5.4.yJason Liu
* tag 'v5.4.70': (3051 commits) Linux 5.4.70 netfilter: ctnetlink: add a range check for l3/l4 protonum ep_create_wakeup_source(): dentry name can change under you... ... Conflicts: arch/arm/mach-imx/pm-imx6.c arch/arm64/boot/dts/freescale/imx8mm-evk.dts arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts drivers/crypto/caam/caamalg.c drivers/gpu/drm/imx/dw_hdmi-imx.c drivers/gpu/drm/imx/imx-ldb.c drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c drivers/mmc/host/sdhci-esdhc-imx.c drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c drivers/net/ethernet/freescale/enetc/enetc.c drivers/net/ethernet/freescale/enetc/enetc_pf.c drivers/thermal/imx_thermal.c drivers/usb/cdns3/ep0.c drivers/xen/swiotlb-xen.c sound/soc/fsl/fsl_esai.c sound/soc/fsl/fsl_sai.c Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
2020-09-03crypto: af_alg - Work around empty control messages without MSG_MOREHerbert Xu
commit c195d66a8a75c60515819b101975f38b7ec6577f upstream. The iwd daemon uses libell which sets up the skcipher operation with two separate control messages. As the first control message is sent without MSG_MORE, it is interpreted as an empty request. While libell should be fixed to use MSG_MORE where appropriate, this patch works around the bug in the kernel so that existing binaries continue to work. We will print a warning however. A separate issue is that the new kernel code no longer allows the control message to be sent twice within the same request. This restriction is obviously incompatible with what iwd was doing (first setting an IV and then sending the real control message). This patch changes the kernel so that this is explicitly allowed. Reported-by: Caleb Jorden <caljorden@hotmail.com> Fixes: f3c802a1f300 ("crypto: algif_aead - Only wake up when...") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-21crypto: algif_aead - fix uninitialized ctx->initOndrej Mosnacek
[ Upstream commit 21dfbcd1f5cbff9cf2f9e7e43475aed8d072b0dd ] In skcipher_accept_parent_nokey() the whole af_alg_ctx structure is cleared by memset() after allocation, so add such memset() also to aead_accept_parent_nokey() so that the new "init" field is also initialized to zero. Without that the initial ctx->init checks might randomly return true and cause errors. While there, also remove the redundant zero assignments in both functions. Found via libkcapi testsuite. Cc: Stephan Mueller <smueller@chronox.de> Fixes: f3c802a1f300 ("crypto: algif_aead - Only wake up when ctx->more is zero") Suggested-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-21crypto: af_alg - Fix regression on empty requestsHerbert Xu
[ Upstream commit 662bb52f50bca16a74fe92b487a14d7dccb85e1a ] Some user-space programs rely on crypto requests that have no control metadata. This broke when a check was added to require the presence of control metadata with the ctx->init flag. This patch fixes the regression by setting ctx->init as long as one sendmsg(2) has been made, with or without a control message. Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Fixes: f3c802a1f300 ("crypto: algif_aead - Only wake up when...") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-08-21crypto: algif_aead - Only wake up when ctx->more is zeroHerbert Xu
[ Upstream commit f3c802a1f30013f8f723b62d7fa49eb9e991da23 ] AEAD does not support partial requests so we must not wake up while ctx->more is set. In order to distinguish between the case of no data sent yet and a zero-length request, a new init flag has been added to ctx. SKCIPHER has also been modified to ensure that at least a block of data is available if there is more data to come. Fixes: 2d97591ef43d ("crypto: af_alg - consolidation of...") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-22keys: asymmetric: fix error return code in software_key_query()Wei Yongjun
[ Upstream commit 6cbba1f9114a8134cff9138c79add15012fd52b9 ] Fix to return negative error code -ENOMEM from kmalloc() error handling case instead of 0, as done elsewhere in this function. Fixes: f1774cb8956a ("X.509: parse public key parameters from x509 for akcipher") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-09crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()Herbert Xu
commit 34c86f4c4a7be3b3e35aa48bd18299d4c756064d upstream. The locking in af_alg_release_parent is broken as the BH socket lock can only be taken if there is a code-path to handle the case where the lock is owned by process-context. Instead of adding such handling, we can fix this by changing the ref counts to atomic_t. This patch also modifies the main refcnt to include both normal and nokey sockets. This way we don't have to fudge the nokey ref count when a socket changes from nokey to normal. Credits go to Mauricio Faria de Oliveira who diagnosed this bug and sent a patch for it: https://lore.kernel.org/linux-crypto/20200605161657.535043-1-mfo@canonical.com/ Reported-by: Brian Moyles <bmoyles@netflix.com> Reported-by: Mauricio Faria de Oliveira <mfo@canonical.com> Fixes: 37f96694cf73 ("crypto: af_alg - Use bh_lock_sock in...") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-24crypto: algboss - don't wait during notifier callbackEric Biggers
commit 77251e41f89a813b4090f5199442f217bbf11297 upstream. When a crypto template needs to be instantiated, CRYPTO_MSG_ALG_REQUEST is sent to crypto_chain. cryptomgr_schedule_probe() handles this by starting a thread to instantiate the template, then waiting for this thread to complete via crypto_larval::completion. This can deadlock because instantiating the template may require loading modules, and this (apparently depending on userspace) may need to wait for the crc-t10dif module (lib/crc-t10dif.c) to be loaded. But crc-t10dif's module_init function uses crypto_register_notifier() and therefore takes crypto_chain.rwsem for write. That can't proceed until the notifier callback has finished, as it holds this semaphore for read. Fix this by removing the wait on crypto_larval::completion from within cryptomgr_schedule_probe(). It's actually unnecessary because crypto_alg_mod_lookup() calls crypto_larval_wait() itself after sending CRYPTO_MSG_ALG_REQUEST. This only actually became a problem in v4.20 due to commit b76377543b73 ("crc-t10dif: Pick better transform if one becomes available"), but the unnecessary wait was much older. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207159 Reported-by: Mike Gerow <gerow@google.com> Fixes: 398710379f51 ("crypto: algapi - Move larval completion into algboss") Cc: <stable@vger.kernel.org> # v3.6+ Cc: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Reported-by: Kai Lüke <kai@kinvolk.io> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-24crypto: algif_skcipher - Cap recv SG list at ctx->usedHerbert Xu
commit 7cf81954705b7e5b057f7dc39a7ded54422ab6e1 upstream. Somewhere along the line the cap on the SG list length for receive was lost. This patch restores it and removes the subsequent test which is now redundant. Fixes: 2d97591ef43d ("crypto: af_alg - consolidation of...") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-19Merge tag 'v5.4.47' into imx_5.4.yJason Liu
* tag 'v5.4.47': (2193 commits) Linux 5.4.47 KVM: arm64: Save the host's PtrAuth keys in non-preemptible context KVM: arm64: Synchronize sysreg state on injecting an AArch32 exception ... Conflicts: arch/arm/boot/dts/imx6qdl.dtsi arch/arm/mach-imx/Kconfig arch/arm/mach-imx/common.h arch/arm/mach-imx/suspend-imx6.S arch/arm64/boot/dts/freescale/imx8qxp-mek.dts arch/powerpc/include/asm/cacheflush.h drivers/cpufreq/imx6q-cpufreq.c drivers/dma/imx-sdma.c drivers/edac/synopsys_edac.c drivers/firmware/imx/imx-scu.c drivers/net/ethernet/freescale/fec.h drivers/net/ethernet/freescale/fec_main.c drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c drivers/net/phy/phy_device.c drivers/perf/fsl_imx8_ddr_perf.c drivers/usb/cdns3/gadget.c drivers/usb/dwc3/gadget.c include/uapi/linux/dma-buf.h Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
2020-06-17crypto: drbg - fix error return code in drbg_alloc_state()Wei Yongjun
commit e0664ebcea6ac5e16da703409fb4bd61f8cd37d9 upstream. Fix to return negative error code -ENOMEM from the kzalloc error handling case instead of 0, as done elsewhere in this function. Reported-by: Xiumei Mu <xmu@redhat.com> Fixes: db07cd26ac6a ("crypto: drbg - add FIPS 140-2 CTRNG for noise source") Cc: <stable@vger.kernel.org> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-17crypto: algapi - Avoid spurious modprobe on LOADEDEric Biggers
commit beeb460cd12ac9b91640b484b6a52dcba9d9fc8f upstream. Currently after any algorithm is registered and tested, there's an unnecessary request_module("cryptomgr") even if it's already loaded. Also, CRYPTO_MSG_ALG_LOADED is sent twice, and thus if the algorithm is "crct10dif", lib/crc-t10dif.c replaces the tfm twice rather than once. This occurs because CRYPTO_MSG_ALG_LOADED is sent using crypto_probing_notify(), which tries to load "cryptomgr" if the notification is not handled (NOTIFY_DONE). This doesn't make sense because "cryptomgr" doesn't handle this notification. Fix this by using crypto_notify() instead of crypto_probing_notify(). Fixes: dd8b083f9a5e ("crypto: api - Introduce notifier for new crypto algorithms") Cc: <stable@vger.kernel.org> # v4.20+ Cc: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-20gcc-10: avoid shadowing standard library 'free()' in cryptoLinus Torvalds
commit 1a263ae60b04de959d9ce9caea4889385eefcc7b upstream. gcc-10 has started warning about conflicting types for a few new built-in functions, particularly 'free()'. This results in warnings like: crypto/xts.c:325:13: warning: conflicting types for built-in function ‘free’; expected ‘void(void *)’ [-Wbuiltin-declaration-mismatch] because the crypto layer had its local freeing functions called 'free()'. Gcc-10 is in the wrong here, since that function is marked 'static', and thus there is no chance of confusion with any standard library function namespace. But the simplest thing to do is to just use a different name here, and avoid this gcc mis-feature. [ Side note: gcc knowing about 'free()' is in itself not the mis-feature: the semantics of 'free()' are special enough that a compiler can validly do special things when seeing it. So the mis-feature here is that gcc thinks that 'free()' is some restricted name, and you can't shadow it as a local static function. Making the special 'free()' semantics be a function attribute rather than tied to the name would be the much better model ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-17crypto: rng - Fix a refcounting bug in crypto_rng_reset()Dan Carpenter
commit eed74b3eba9eda36d155c11a12b2b4b50c67c1d8 upstream. We need to decrement this refcounter on these error paths. Fixes: f7d76e05d058 ("crypto: user - fix use_after_free of struct xxx_request") Cc: <stable@vger.kernel.org> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-07crypto: tls - fix logical-not-parentheses compile warningIuliana Prodan
Fix the following warning: crypto/testmgr.c: In function ‘__test_tls’: crypto/testmgr.c:2648:12: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] if (!ret == template[i].fail) { ^~ Fixes: 8abdaaeda43 ("crypto: add support for TLS 1.0 record encryption") Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Reviewed-by: Valentin Ciocoi R?dulescu <valentin.ciocoi@nxp.com>
2020-03-31MLK-21644 crypto: tcrypt - workaround for overlapping src, dst AADHoria Geantă
This is a temporary workround for the case when: -SWIOTLB is used for DMA bounce buffering AND -data to be DMA-ed is mapped DMA_FROM_DEVICE and device only partially overwrites the "original" data AND -it's expected that the "original" data that was not overwritten by the device to be untouched As discussed in upstream, the proper fix should be: -either an extension of the DMA API OR -a workaround in the device driver (considering these cases are rarely met in practice) Since both alternatives are not trivial (to say the least), add a workaround for the few cases matching the error conditions listed above. Link: https://lore.kernel.org/lkml/VI1PR0402MB348537CB86926B3E6D1DBE0A98070@VI1PR0402MB3485.eurprd04.prod.outlook.com/ Link: https://lore.kernel.org/lkml/20190522072018.10660-1-horia.geanta@nxp.com/ Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Reviewed-by: Valentin Ciocoi Radulescu <valentin.ciocoi@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com>
2020-03-08Merge tag 'v5.4.24' into imx_5.4.yJason Liu
Merge Linux stable release v5.4.24 into imx_5.4.y * tag 'v5.4.24': (3306 commits) Linux 5.4.24 blktrace: Protect q->blk_trace with RCU kvm: nVMX: VMWRITE checks unsupported field before read-only field ... Signed-off-by: Jason Liu <jason.hui.liu@nxp.com> Conflicts: arch/arm/boot/dts/imx6sll-evk.dts arch/arm/boot/dts/imx7ulp.dtsi arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi drivers/clk/imx/clk-composite-8m.c drivers/gpio/gpio-mxc.c drivers/irqchip/Kconfig drivers/mmc/host/sdhci-of-esdhc.c drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c drivers/net/can/flexcan.c drivers/net/ethernet/freescale/dpaa/dpaa_eth.c drivers/net/ethernet/mscc/ocelot.c drivers/net/ethernet/stmicro/stmmac/stmmac_main.c drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c drivers/net/phy/realtek.c drivers/pci/controller/mobiveil/pcie-mobiveil-host.c drivers/perf/fsl_imx8_ddr_perf.c drivers/tee/optee/shm_pool.c drivers/usb/cdns3/gadget.c kernel/sched/cpufreq.c net/core/xdp.c sound/soc/fsl/fsl_esai.c sound/soc/fsl/fsl_sai.c sound/soc/sof/core.c sound/soc/sof/imx/Kconfig sound/soc/sof/loader.c
2020-02-28crypto: rename sm3-256 to sm3 in hash_algo_nameTianjia Zhang
commit 6a30e1b1dcad0ba94fae757f797812d7d8dcb72c upstream. The name sm3-256 is defined in hash_algo_name in hash_info, but the algorithm name implemented in sm3_generic.c is sm3, which will cause the sm3-256 algorithm to be not found in some application scenarios of the hash algorithm, and an ENOENT error will occur. For example, IMA, keys, and other subsystems that reference hash_algo_name all use the hash algorithm of sm3. Fixes: 5ca4c20cfd37 ("keys, trusted: select hash algorithm for TPM2 chips") Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Reviewed-by: Pascal van Leeuwen <pvanleeuwen@rambus.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-27LF-804 crypto: tls - fix module autoloadingHoria Geantă
tls module lacks an alias, thus cannot be auto-loaded. Note that all crypto modules have to be "protected" under the namespace created by the "crypto-" prefix: commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"") Fixes: a61cc4776299 ("crypto: add support for TLS 1.0 record encryption") Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Reviewed-by: Valentin Ciocoi Radulescu <valentin.ciocoi@nxp.com>
2020-02-24crypto: essiv - fix AEAD capitalization and preposition use in help textGeert Uytterhoeven
[ Upstream commit ab3d436bf3e9d05f58ceaa85ff7475bfcd6e45af ] "AEAD" is capitalized everywhere else. Use "an" when followed by a written or spoken vowel. Fixes: be1eb7f78aa8fbe3 ("crypto: essiv - create wrapper template for ESSIV generation") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-14crypto: testmgr - don't try to decrypt uninitialized buffersEric Biggers
commit eb455dbd02cb1074b37872ffca30a81cb2a18eaa upstream. Currently if the comparison fuzz tests encounter an encryption error when generating an skcipher or AEAD test vector, they will still test the decryption side (passing it the uninitialized ciphertext buffer) and expect it to fail with the same error. This is sort of broken because it's not well-defined usage of the API to pass an uninitialized buffer, and furthermore in the AEAD case it's acceptable for the decryption error to be EBADMSG (meaning "inauthentic input") even if the encryption error was something else like EINVAL. Fix this for skcipher by explicitly initializing the ciphertext buffer on error, and for AEAD by skipping the decryption test on error. Reported-by: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com> Fixes: d435e10e67be ("crypto: testmgr - fuzz skciphers against their generic implementation") Fixes: 40153b10d91c ("crypto: testmgr - fuzz AEADs against their generic implementation") Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-11crypto: api - Fix race condition in crypto_spawn_algHerbert Xu
commit 73669cc556462f4e50376538d77ee312142e8a8a upstream. The function crypto_spawn_alg is racy because it drops the lock before shooting the dying algorithm. The algorithm could disappear altogether before we shoot it. This patch fixes it by moving the shooting into the locked section. Fixes: 6bfd48096ff8 ("[CRYPTO] api: Added spawns") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>