summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* crypto: authenc - Fix sleep in atomic context in decrypt_tailHerbert Xu2022-04-151-1/+1
| | | | | | | | | | | | | | | | | | [ 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: c53e75d5b112 ("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>
* crypto: rsa-pkcs1pad - fix buffer overread in pkcs1pad_verify_complete()Eric Biggers2022-04-151-0/+2
| | | | | | | | | | | | | | commit a24611ea356c7f3f0ec926da11b9482ac1f414fd upstream. Before checking whether the expected digest_info is present, we need to check that there are enough bytes remaining. Fixes: 39669c60ba49 ("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>
* crypto: rsa-pkcs1pad - restore signature length checkEric Biggers2022-04-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 39669c60ba49 ("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 5bb3d56f3518 ("crypto: akcipher - new verify API for public key algorithms"). Fixes: 39669c60ba49 ("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>
* crypto: rsa-pkcs1pad - correctly get hash from source scatterlistEric Biggers2022-04-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e316f7179be22912281ce6331d96d7c121fb2b17 upstream. Commit 5bb3d56f3518 ("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: 5bb3d56f3518 ("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>
* crypto: pcrypt - Delay write to padata->infoDaniel Jordan2021-11-171-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ 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: fa0657180cb85 ("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>
* crypto: ecc - fix CRYPTO_DEFAULT_RNG dependencyArnd Bergmann2021-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | [ 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: 223475c353b6 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm") Fixes: ef4af956b9d0 ("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>
* crypto: shash - avoid comparing pointers to exported functions under CFIArd Biesheuvel2021-07-141-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | [ 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>
* crypto: rng - fix crypto_rng_reset() refcounting when !CRYPTO_STATSEric Biggers2021-05-111-7/+3
| | | | | | | | | | | | | | | | | | commit bf1e9b3dff85a0433aaea6755c3f8036840dacfb 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: 9b91cc7900ce ("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>
* crypto: api - check for ERR pointers in crypto_destroy_tfm()Ard Biesheuvel2021-05-111-1/+1
| | | | | | | | | | | | | | | | | | [ Upstream commit 72e2a02cdf58fbe06533cc21f6d7dd518cf01ae5 ] 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>
* crypto: x86 - Regularize glue function prototypesKees Cook2021-03-202-10/+14
| | | | | | | | | | | | | | | | | | | commit 31701000f52600cb1dd335dec9333addf1a69494 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>
* crypto: tcrypt - avoid signed overflow in byte countArd Biesheuvel2021-03-071-10/+10
| | | | | | | | | | | | | | | | [ Upstream commit cbebe807d8465ef8f541a57c12ed6a3b55f73629 ] 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>
* crypto: ecdh_helper - Ensure 'len >= secret.len' in decode_key()Daniele Alessandrelli2021-03-041-0/+3
| | | | | | | | | | | | | | | | [ Upstream commit 49397f15495d5f06d87da962adab714720026232 ] 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: e8c7f30611313 ("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>
* crypto: asym_tpm: correct zero out potential secretsGreg Kroah-Hartman2021-01-121-1/+1
| | | | | | | | | | | | | | | | commit 26a5d10c7f4f9edc8a09f0301cc5ca55844db375 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>
* crypto: ecdh - avoid buffer overflow in ecdh_set_secret()Ard Biesheuvel2021-01-121-1/+2
| | | | | | | | | | | | | | | | | | | | | commit 4204b130b8a4d1cd2c4a0d9a5a09993e8948defe upstream. Pavel reports that commit 8319c80ab523 ("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: 8319c80ab523 ("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>
* crypto: ecdh - avoid unaligned accesses in ecdh_set_secret()Ard Biesheuvel2020-12-301-4/+5
| | | | | | | | | | | | | | | | | | | commit 8319c80ab523e5735c07bb0da3bae7a93997c61e 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>
* crypto: af_alg - avoid undefined behavior accessing salg_nameEric Biggers2020-12-301-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e1cbfc28701813b40fe3891526dfc55f475bae8d upstream. Commit 7175dac1d936 ("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: 7175dac1d936 ("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>
* crypto: algif_skcipher - EBUSY on aio should be an errorHerbert Xu2020-10-291-1/+1
| | | | | | | | | | | | | [ Upstream commit 6ccc838ed96261a4fef35aa45f7d951b31aa3d9d ] 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: 5da64d081413 ("crypto: algif_skcipher - Do not set...") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
* crypto: algif_aead - Do not set MAY_BACKLOG on the async pathHerbert Xu2020-10-291-3/+4
| | | | | | | | | | | | | | commit f4f2fe30bd59f6b848d0a90b2549441f6f3cc5a9 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: a8e3a343aba2 ("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>
* crypto: af_alg - Work around empty control messages without MSG_MOREHerbert Xu2020-09-031-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit 113767ab58ba2b4430fa802ccafd7e4c04ae512b 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: a52eb0489f96 ("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>
* crypto: algif_aead - fix uninitialized ctx->initOndrej Mosnacek2020-08-212-12/+1
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 39709b59769d024936bdb204d0b49a6ae9d83b3e ] 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: a52eb0489f96 ("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>
* crypto: af_alg - Fix regression on empty requestsHerbert Xu2020-08-211-1/+1
| | | | | | | | | | | | | | | | | [ Upstream commit 673136029221f5b7c0eea9efc9aabc1a081aa148 ] 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: a52eb0489f96 ("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>
* crypto: algif_aead - Only wake up when ctx->more is zeroHerbert Xu2020-08-213-7/+12
| | | | | | | | | | | | | | | | [ Upstream commit a52eb0489f96f7318fce6b1afe1cabd46c750746 ] 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: c1b1fa586429 ("crypto: af_alg - consolidation of...") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
* keys: asymmetric: fix error return code in software_key_query()Wei Yongjun2020-07-221-0/+1
| | | | | | | | | | | | | [ Upstream commit a95aa5c85186df292b00edeb49e2b2cb05d4b4dc ] Fix to return negative error code -ENOMEM from kmalloc() error handling case instead of 0, as done elsewhere in this function. Fixes: 1bef742086ae ("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>
* crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock()Herbert Xu2020-07-094-33/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit 01a078cc522b6e76f451f600260dfcd45b52c0ae 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: a2ce15b668c6 ("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>
* crypto: algboss - don't wait during notifier callbackEric Biggers2020-06-241-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 2dae7d67d06328e0273dd45a995c6396f89f4e4a 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: 582802f3e378 ("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>
* crypto: algif_skcipher - Cap recv SG list at ctx->usedHerbert Xu2020-06-241-5/+1
| | | | | | | | | | | | | | | | commit 4c636c1916324c5e8d13479b52f21f5152af2742 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: c1b1fa586429 ("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>
* crypto: drbg - fix error return code in drbg_alloc_state()Wei Yongjun2020-06-171-1/+3
| | | | | | | | | | | | | | | | commit 4e74a113fa130f456485cc3f2460ca743aadf8aa 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: 384577283cad ("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>
* crypto: algapi - Avoid spurious modprobe on LOADEDEric Biggers2020-06-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | commit 01f8445e237766d4d488c0e7cec9cf8827fb41c2 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: 871e235bdcbb ("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>
* gcc-10: avoid shadowing standard library 'free()' in cryptoLinus Torvalds2020-05-202-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 1509add362eb98340875abf85b448a5ecba2a29e 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>
* crypto: rng - Fix a refcounting bug in crypto_rng_reset()Dan Carpenter2020-04-171-2/+6
| | | | | | | | | | | | | | commit 9b91cc7900ce35b2e7e835726faa6295120cf839 upstream. We need to decrement this refcounter on these error paths. Fixes: 69bd3f459030 ("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>
* crypto: rename sm3-256 to sm3 in hash_algo_nameTianjia Zhang2020-02-281-1/+1
| | | | | | | | | | | | | | | | | | commit af7038fa796262e9884103ef5d4fe37bd9dbd44b 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: a80ce6d6d765 ("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>
* crypto: essiv - fix AEAD capitalization and preposition use in help textGeert Uytterhoeven2020-02-241-2/+2
| | | | | | | | | | | | [ Upstream commit 6cdcc5bd15648148f62c46cf573a51136946009d ] "AEAD" is capitalized everywhere else. Use "an" when followed by a written or spoken vowel. Fixes: 392e2e025cfd8a3c ("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>
* crypto: testmgr - don't try to decrypt uninitialized buffersEric Biggers2020-02-141-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | commit 169e10bff75b6fcfbc094124e853402ff1a0e249 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: 4ee79aa7c098 ("crypto: testmgr - fuzz skciphers against their generic implementation") Fixes: 4b772af62cb3 ("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>
* crypto: api - Fix race condition in crypto_spawn_algHerbert Xu2020-02-113-14/+6
| | | | | | | | | | | | | | | commit bc1d8cb6169a2deb7dbcad8ac6ed8ade1bc2bb05 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: 525ed3dcb430 ("[CRYPTO] api: Added spawns") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* crypto: pcrypt - Do not clear MAY_SLEEP flag in original requestHerbert Xu2020-02-111-1/+0
| | | | | | | | | | | | | | | commit 1643e8e6f19b8ac65edf01ced630f64b28bf1fcd upstream. We should not be modifying the original request's MAY_SLEEP flag upon completion. It makes no sense to do so anyway. Reported-by: Eric Biggers <ebiggers@kernel.org> Fixes: fa0657180cb8 ("crypto: pcrypt - Add pcrypt crypto...") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Tested-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* crypto: api - fix unexpectedly getting generic implementationHerbert Xu2020-02-112-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit e4da805f79b7adedd802488acadd05b598e7edc3 upstream. When CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y, the first lookup of an algorithm that needs to be instantiated using a template will always get the generic implementation, even when an accelerated one is available. This happens because the extra self-tests for the accelerated implementation allocate the generic implementation for comparison purposes, and then crypto_alg_tested() for the generic implementation "fulfills" the original request (i.e. sets crypto_larval::adult). This patch fixes this by only fulfilling the original request if we are currently the best outstanding larval as judged by the priority. If we're not the best then we will ask all waiters on that larval request to retry the lookup. Note that this patch introduces a behaviour change when the module providing the new algorithm is unregistered during the process. Previously we would have failed with ENOENT, after the patch we will instead redo the lookup. Fixes: d5b14e972b3b ("crypto: testmgr - fuzz hashes against...") Fixes: 4ee79aa7c098 ("crypto: testmgr - fuzz skciphers against...") Fixes: 4b772af62cb3 ("crypto: testmgr - fuzz AEADs against...") Reported-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-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>
* crypto: pcrypt - Avoid deadlock by using per-instance padata queuesHerbert Xu2020-02-111-3/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a33320033926272757a3fec07709b26584fa9a4f upstream. If the pcrypt template is used multiple times in an algorithm, then a deadlock occurs because all pcrypt instances share the same padata_instance, which completes requests in the order submitted. That is, the inner pcrypt request waits for the outer pcrypt request while the outer request is already waiting for the inner. This patch fixes this by allocating a set of queues for each pcrypt instance instead of using two global queues. In order to maintain the existing user-space interface, the pinst structure remains global so any sysfs modifications will apply to every pcrypt instance. Note that when an update occurs we have to allocate memory for every pcrypt instance. Should one of the allocations fail we will abort the update without rolling back changes already made. The new per-instance data structure is called padata_shell and is essentially a wrapper around parallel_data. Reproducer: #include <linux/if_alg.h> #include <sys/socket.h> #include <unistd.h> int main() { struct sockaddr_alg addr = { .salg_type = "aead", .salg_name = "pcrypt(pcrypt(rfc4106-gcm-aesni))" }; int algfd, reqfd; char buf[32] = { 0 }; algfd = socket(AF_ALG, SOCK_SEQPACKET, 0); bind(algfd, (void *)&addr, sizeof(addr)); setsockopt(algfd, SOL_ALG, ALG_SET_KEY, buf, 20); reqfd = accept(algfd, 0, 0); write(reqfd, buf, 32); read(reqfd, buf, 16); } Reported-by: syzbot+56c7151cad94eec37c521f0e47d2eee53f9361c4@syzkaller.appspotmail.com Fixes: fa0657180cb8 ("crypto: pcrypt - Add pcrypt crypto parallelization wrapper") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Tested-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* crypto: api - Check spawn->alg under lock in crypto_drop_spawnHerbert Xu2020-02-111-4/+2
| | | | | | | | | | | | | | | commit bc39d9486351deb0881a382c6c2d52b73467d304 upstream. We need to check whether spawn->alg is NULL under lock as otherwise the algorithm could be removed from under us after we have checked it and found it to be non-NULL. This could cause us to remove the spawn from a non-existent list. Fixes: d0bb12bd1529 ("crypto: api - Fix crypto_drop_spawn crash...") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* crypto: pcrypt - Fix user-after-free on module unloadHerbert Xu2020-02-011-1/+2
| | | | | | | | | | | | | | | commit b61ad212689fc7ef61f32112a0ffddfcbc8a6159 upstream. On module unload of pcrypt we must unregister the crypto algorithms first and then tear down the padata structure. As otherwise the crypto algorithms are still alive and can be used while the padata structure is being freed. Fixes: fa0657180cb8 ("crypto: pcrypt - Add pcrypt crypto...") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* crypto: af_alg - Use bh_lock_sock in sk_destructHerbert Xu2020-02-011-2/+4
| | | | | | | | | | | | | | | | | commit a2ce15b668c6001804d34080c79e5e3c9979eda7 upstream. As af_alg_release_parent may be called from BH context (most notably due to an async request that only completes after socket closure, or as reported here because of an RCU-delayed sk_destruct call), we must use bh_lock_sock instead of lock_sock. Reported-by: syzbot+c2f1558d49e25cc36e5e@syzkaller.appspotmail.com Reported-by: Eric Dumazet <eric.dumazet@gmail.com> Fixes: 796caacfda1c ("crypto: af_alg - Disallow bind/setkey/...") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* crypto: algif_skcipher - Use chunksize instead of blocksizeHerbert Xu2020-01-171-1/+1
| | | | | | | | | | | | | | | | | | | | commit 69e716c27aed0a841dc987fc980e6e9576887d74 upstream. When algif_skcipher does a partial operation it always process data that is a multiple of blocksize. However, for algorithms such as CTR this is wrong because even though it can process any number of bytes overall, the partial block must come at the very end and not in the middle. This is exactly what chunksize is meant to describe so this patch changes blocksize to chunksize. Fixes: fcbb8a3beda3 ("crypto: algif_skcipher - User-space...") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* KEYS: asymmetric: return ENOMEM if akcipher_request_alloc() failsEric Biggers2019-12-312-0/+2
| | | | | | | | | | | | | | | | commit 135a5b27c8ddf6f5f681f7e1bc15d350a83220f9 upstream. No error code was being set on this error path. Cc: stable@vger.kernel.org Fixes: 61e4c308f504 ("KEYS: asym_tpm: Implement encryption operation [ver #2]") Fixes: 62e395f6b1be ("KEYS: Implement encrypt, decrypt and sign for software asymmetric key [ver #2]") Reviewed-by: James Morris <jamorris@linux.microsoft.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* crypto: aegis128/simd - build 32-bit ARM for v8 architecture explicitlyArd Biesheuvel2019-12-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 7abc6ca840e93a0d8563491dfb078d5aa5f048ac ] Now that the Clang compiler has taken it upon itself to police the compiler command line, and reject combinations for arguments it views as incompatible, the AEGIS128 no longer builds correctly, and errors out like this: clang-10: warning: ignoring extension 'crypto' because the 'armv7-a' architecture does not support it [-Winvalid-command-line-argument] So let's switch to armv8-a instead, which matches the crypto-neon-fp-armv8 FPU profile we specify. Since neither were actually supported by GCC versions before 4.8, let's tighten the Kconfig dependencies as well so we won't run into errors when building with an ancient compiler. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reported-by: <ci_notify@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
* crypto: aegis128-neon - use Clang compatible cflags for ARMArd Biesheuvel2019-12-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 2afc161d3d35b0cfb77c8fe5a63c5dd65c2ea79c ] The next version of Clang will start policing compiler command line options, and will reject combinations of -march and -mfpu that it thinks are incompatible. This results in errors like clang-10: warning: ignoring extension 'crypto' because the 'armv7-a' architecture does not support it [-Winvalid-command-line-argument] /tmp/aegis128-neon-inner-5ee428.s: Assembler messages: /tmp/aegis128-neon-inner-5ee428.s:73: Error: selected processor does not support `aese.8 q2,q14' in ARM mode when buiding the SIMD aegis128 code for 32-bit ARM, given that the 'armv7-a' -march argument is considered to be compatible with the ARM crypto extensions. Instead, we should use armv8-a, which does allow the crypto extensions to be enabled. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
* crypto: user - fix memory leak in crypto_reportstatNavid Emamdoost2019-12-131-1/+3
| | | | | | | | | | | | | | | commit 51a65c657e5868cb31f6746beefda1f8c444edba upstream. In crypto_reportstat, a new skb is created by nlmsg_new(). This skb is leaked if crypto_reportstat_alg() fails. Required release for skb is added. Fixes: 0115ab23b941 ("crypto: user - Implement a generic crypto statistics") Cc: <stable@vger.kernel.org> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* crypto: user - fix memory leak in crypto_reportNavid Emamdoost2019-12-131-1/+3
| | | | | | | | | | | | | | commit f1a5778c0239e65288ffb87842d8173b45f719fd upstream. In crypto_report, a new skb is created via nlmsg_new(). This skb should be released if crypto_report_alg() fails. Fixes: 2da2418a8b84 ("crypto: Add userspace configuration API") Cc: <stable@vger.kernel.org> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* crypto: ecdh - fix big endian bug in ECC libraryArd Biesheuvel2019-12-131-1/+2
| | | | | | | | | | | | | | | | | | | commit 262777c0da63572461859a155024cf5c52023afb upstream. The elliptic curve arithmetic library used by the EC-DH KPP implementation assumes big endian byte order, and unconditionally reverses the byte and word order of multi-limb quantities. On big endian systems, the byte reordering is not necessary, while the word ordering needs to be retained. So replace the __swab64() invocation with a call to be64_to_cpu() which should do the right thing for both little and big endian builds. Fixes: e8c7f3061131 ("crypto: ecdh - Add ECDH software support") Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* crypto: af_alg - cast ki_complete ternary op to intAyush Sawal2019-12-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 53d58e19fe0739d71a1d4a8678eb41cb04dd09ac upstream. when libkcapi test is executed using HW accelerator, cipher operation return -74.Since af_alg_async_cb->ki_complete treat err as unsigned int, libkcapi receive 429467222 even though it expect -ve value. Hence its required to cast resultlen to int so that proper error is returned to libkcapi. AEAD one shot non-aligned test 2(libkcapi test) ./../bin/kcapi -x 10 -c "gcm(aes)" -i 7815d4b06ae50c9c56e87bd7 -k ea38ac0c9b9998c80e28fb496a2b88d9 -a "853f98a750098bec1aa7497e979e78098155c877879556bb51ddeb6374cbaefc" -t "c4ce58985b7203094be1d134c1b8ab0b" -q "b03692f86d1b8b39baf2abb255197c98" Fixes: 0c2a2d0aa6e4 ("crypto: algif_aead - overhaul memory management") Cc: <stable@vger.kernel.org> Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by: Atul Gupta <atul.gupta@chelsio.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge branch 'next-lockdown' of ↵Linus Torvalds2019-09-281-1/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull kernel lockdown mode from James Morris: "This is the latest iteration of the kernel lockdown patchset, from Matthew Garrett, David Howells and others. From the original description: This patchset introduces an optional kernel lockdown feature, intended to strengthen the boundary between UID 0 and the kernel. When enabled, various pieces of kernel functionality are restricted. Applications that rely on low-level access to either hardware or the kernel may cease working as a result - therefore this should not be enabled without appropriate evaluation beforehand. The majority of mainstream distributions have been carrying variants of this patchset for many years now, so there's value in providing a doesn't meet every distribution requirement, but gets us much closer to not requiring external patches. There are two major changes since this was last proposed for mainline: - Separating lockdown from EFI secure boot. Background discussion is covered here: https://lwn.net/Articles/751061/ - Implementation as an LSM, with a default stackable lockdown LSM module. This allows the lockdown feature to be policy-driven, rather than encoding an implicit policy within the mechanism. The new locked_down LSM hook is provided to allow LSMs to make a policy decision around whether kernel functionality that would allow tampering with or examining the runtime state of the kernel should be permitted. The included lockdown LSM provides an implementation with a simple policy intended for general purpose use. This policy provides a coarse level of granularity, controllable via the kernel command line: lockdown={integrity|confidentiality} Enable the kernel lockdown feature. If set to integrity, kernel features that allow userland to modify the running kernel are disabled. If set to confidentiality, kernel features that allow userland to extract confidential information from the kernel are also disabled. This may also be controlled via /sys/kernel/security/lockdown and overriden by kernel configuration. New or existing LSMs may implement finer-grained controls of the lockdown features. Refer to the lockdown_reason documentation in include/linux/security.h for details. The lockdown feature has had signficant design feedback and review across many subsystems. This code has been in linux-next for some weeks, with a few fixes applied along the way. Stephen Rothwell noted that commit 9d1f8be5cf42 ("bpf: Restrict bpf when kernel lockdown is in confidentiality mode") is missing a Signed-off-by from its author. Matthew responded that he is providing this under category (c) of the DCO" * 'next-lockdown' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (31 commits) kexec: Fix file verification on S390 security: constify some arrays in lockdown LSM lockdown: Print current->comm in restriction messages efi: Restrict efivar_ssdt_load when the kernel is locked down tracefs: Restrict tracefs when the kernel is locked down debugfs: Restrict debugfs when the kernel is locked down kexec: Allow kexec_file() with appropriate IMA policy when locked down lockdown: Lock down perf when in confidentiality mode bpf: Restrict bpf when kernel lockdown is in confidentiality mode lockdown: Lock down tracing and perf kprobes when in confidentiality mode lockdown: Lock down /proc/kcore x86/mmiotrace: Lock down the testmmiotrace module lockdown: Lock down module params that specify hardware parameters (eg. ioport) lockdown: Lock down TIOCSSERIAL lockdown: Prohibit PCMCIA CIS storage when the kernel is locked down acpi: Disable ACPI table override if the kernel is locked down acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down ACPI: Limit access to custom_method when the kernel is locked down x86/msr: Restrict MSR access when the kernel is locked down x86: Lock down IO port access when the kernel is locked down ...
| * kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCEJiri Bohac2019-08-191-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a preparatory patch for kexec_file_load() lockdown. A locked down kernel needs to prevent unsigned kernel images from being loaded with kexec_file_load(). Currently, the only way to force the signature verification is compiling with KEXEC_VERIFY_SIG. This prevents loading usigned images even when the kernel is not locked down at runtime. This patch splits KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE. Analogous to the MODULE_SIG and MODULE_SIG_FORCE for modules, KEXEC_SIG turns on the signature verification but allows unsigned images to be loaded. KEXEC_SIG_FORCE disallows images without a valid signature. Signed-off-by: Jiri Bohac <jbohac@suse.cz> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Matthew Garrett <mjg59@google.com> cc: kexec@lists.infradead.org Signed-off-by: James Morris <jmorris@namei.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-20 05:45:37 +0000