summaryrefslogtreecommitdiff
path: root/crypto/asymmetric_keys
AgeCommit message (Collapse)AuthorFilesLines
2018-08-16Replace magic for trusting the secondary keyring with #defineYannik Sembritzki1-1/+1
Replace the use of a magic number that indicates that verify_*_signature() should use the secondary keyring with a symbol. Signed-off-by: Yannik Sembritzki <yannik@sembritzki.me> Signed-off-by: David Howells <dhowells@redhat.com> Cc: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-06-25X.509: unpack RSA signatureValue field from BIT STRINGMaciej S. Szmigiero1-0/+9
The signatureValue field of a X.509 certificate is encoded as a BIT STRING. For RSA signatures this BIT STRING is of so-called primitive subtype, which contains a u8 prefix indicating a count of unused bits in the encoding. We have to strip this prefix from signature data, just as we already do for key data in x509_extract_key_data() function. This wasn't noticed earlier because this prefix byte is zero for RSA key sizes divisible by 8. Since BIT STRING is a big-endian encoding adding zero prefixes has no bearing on its value. The signature length, however was incorrect, which is a problem for RSA implementations that need it to be exactly correct (like AMD CCP). Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Fixes: c26fd69fa009 ("X.509: Add a crypto key parser for binary (DER) X.509 certificates") Cc: stable@vger.kernel.org Signed-off-by: James Morris <james.morris@microsoft.com>
2018-06-15docs: Fix some broken referencesMauro Carvalho Chehab2-2/+2
As we move stuff around, some doc references are broken. Fix some of them via this script: ./scripts/documentation-file-ref-check --fix Manually checked if the produced result is valid, removing a few false-positives. Acked-by: Takashi Iwai <tiwai@suse.de> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Acked-by: Stephen Boyd <sboyd@kernel.org> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Coly Li <colyli@suse.de> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: Jonathan Corbet <corbet@lwn.net>
2018-04-07kbuild: rename *-asn1.[ch] to *.asn1.[ch]Masahiro Yamada4-16/+16
Our convention is to distinguish file types by suffixes with a period as a separator. *-asn1.[ch] is a different pattern from other generated sources such as *.lex.c, *.tab.[ch], *.dtb.S, etc. More confusing, files with '-asn1.[ch]' are generated files, but '_asn1.[ch]' are checked-in files: net/netfilter/nf_conntrack_h323_asn1.c include/linux/netfilter/nf_conntrack_h323_asn1.h include/linux/sunrpc/gss_asn1.h Rename generated files to *.asn1.[ch] for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-04-07kbuild: clean up *-asn1.[ch] patterns from top-level MakefileMasahiro Yamada1-7/+0
Clean up these patterns from the top Makefile to omit 'clean-files' in each Makefile. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-04-07.gitignore: move *-asn1.[ch] patterns to the top-level .gitignoreMasahiro Yamada1-1/+0
These are common patterns where source files are parsed by the asn1_compiler. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-02-22X.509: fix NULL dereference when restricting key with unsupported_sigEric Biggers1-8/+13
The asymmetric key type allows an X.509 certificate to be added even if its signature's hash algorithm is not available in the crypto API. In that case 'payload.data[asym_auth]' will be NULL. But the key restriction code failed to check for this case before trying to use the signature, resulting in a NULL pointer dereference in key_or_keyring_common() or in restrict_link_by_signature(). Fix this by returning -ENOPKG when the signature is unsupported. Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled and keyctl has support for the 'restrict_keyring' command: keyctl new_session keyctl restrict_keyring @s asymmetric builtin_trusted openssl req -new -sha512 -x509 -batch -nodes -outform der \ | keyctl padd asymmetric desc @s Fixes: a511e1af8b12 ("KEYS: Move the point of trust determination to __key_link()") Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com>
2018-02-22X.509: fix BUG_ON() when hash algorithm is unsupportedEric Biggers1-1/+3
The X.509 parser mishandles the case where the certificate's signature's hash algorithm is not available in the crypto API. In this case, x509_get_sig_params() doesn't allocate the cert->sig->digest buffer; this part seems to be intentional. However, public_key_verify_signature() is still called via x509_check_for_self_signed(), which triggers the 'BUG_ON(!sig->digest)'. Fix this by making public_key_verify_signature() return -ENOPKG if the hash buffer has not been allocated. Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled: openssl req -new -sha512 -x509 -batch -nodes -outform der \ | keyctl padd asymmetric desc @s Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier") Reported-by: Paolo Valente <paolo.valente@linaro.org> Cc: Paolo Valente <paolo.valente@linaro.org> Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com>
2018-02-22PKCS#7: fix direct verification of SignerInfo signatureEric Biggers1-0/+1
If none of the certificates in a SignerInfo's certificate chain match a trusted key, nor is the last certificate signed by a trusted key, then pkcs7_validate_trust_one() tries to check whether the SignerInfo's signature was made directly by a trusted key. But, it actually fails to set the 'sig' variable correctly, so it actually verifies the last signature seen. That will only be the SignerInfo's signature if the certificate chain is empty; otherwise it will actually be the last certificate's signature. This is not by itself a security problem, since verifying any of the certificates in the chain should be sufficient to verify the SignerInfo. Still, it's not working as intended so it should be fixed. Fix it by setting 'sig' correctly for the direct verification case. Fixes: 757932e6da6d ("PKCS#7: Handle PKCS#7 messages that contain no X.509 certs") Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com>
2018-02-22PKCS#7: fix certificate blacklistingEric Biggers1-4/+6
If there is a blacklisted certificate in a SignerInfo's certificate chain, then pkcs7_verify_sig_chain() sets sinfo->blacklisted and returns 0. But, pkcs7_verify() fails to handle this case appropriately, as it actually continues on to the line 'actual_ret = 0;', indicating that the SignerInfo has passed verification. Consequently, PKCS#7 signature verification ignores the certificate blacklist. Fix this by not considering blacklisted SignerInfos to have passed verification. Also fix the function comment with regards to when 0 is returned. Fixes: 03bb79315ddc ("PKCS#7: Handle blacklisted certificates") Cc: <stable@vger.kernel.org> # v4.12+ Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com>
2018-02-22PKCS#7: fix certificate chain verificationEric Biggers1-1/+1
When pkcs7_verify_sig_chain() is building the certificate chain for a SignerInfo using the certificates in the PKCS#7 message, it is passing the wrong arguments to public_key_verify_signature(). Consequently, when the next certificate is supposed to be used to verify the previous certificate, the next certificate is actually used to verify itself. An attacker can use this bug to create a bogus certificate chain that has no cryptographic relationship between the beginning and end. Fortunately I couldn't quite find a way to use this to bypass the overall signature verification, though it comes very close. Here's the reasoning: due to the bug, every certificate in the chain beyond the first actually has to be self-signed (where "self-signed" here refers to the actual key and signature; an attacker might still manipulate the certificate fields such that the self_signed flag doesn't actually get set, and thus the chain doesn't end immediately). But to pass trust validation (pkcs7_validate_trust()), either the SignerInfo or one of the certificates has to actually be signed by a trusted key. Since only self-signed certificates can be added to the chain, the only way for an attacker to introduce a trusted signature is to include a self-signed trusted certificate. But, when pkcs7_validate_trust_one() reaches that certificate, instead of trying to verify the signature on that certificate, it will actually look up the corresponding trusted key, which will succeed, and then try to verify the *previous* certificate, which will fail. Thus, disaster is narrowly averted (as far as I could tell). Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier") Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com>
2017-12-08X.509: fix comparisons of ->pkey_algoEric Biggers2-2/+2
->pkey_algo used to be an enum, but was changed to a string by commit 4e8ae72a75aa ("X.509: Make algo identifiers text instead of enum"). But two comparisons were not updated. Fix them to use strcmp(). This bug broke signature verification in certain configurations, depending on whether the string constants were deduplicated or not. Fixes: 4e8ae72a75aa ("X.509: Make algo identifiers text instead of enum") Cc: <stable@vger.kernel.org> # v4.6+ Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com>
2017-12-08X.509: use crypto_shash_digest()Eric Biggers1-5/+1
Use crypto_shash_digest() instead of crypto_shash_init() followed by crypto_shash_finup(). (For simplicity only; they are equivalent.) Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com>
2017-12-08KEYS: be careful with error codes in public_key_verify_signature()Eric Biggers1-2/+5
In public_key_verify_signature(), if akcipher_request_alloc() fails, we return -ENOMEM. But that error code was set 25 lines above, and by accident someone could easily insert new code in between that assigns to 'ret', which would introduce a signature verification bypass. Make the code clearer by moving the -ENOMEM down to where it is used. Additionally, the callers of public_key_verify_signature() only consider a negative return value to be an error. This means that if any positive return value is accidentally introduced deeper in the call stack (e.g. 'return EBADMSG' instead of 'return -EBADMSG' somewhere in RSA), signature verification will be bypassed. Make things more robust by having public_key_verify_signature() warn about positive errors and translate them into -EINVAL. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com>
2017-12-08pkcs7: use crypto_shash_digest()Eric Biggers1-5/+2
Use crypto_shash_digest() instead of crypto_shash_init() followed by crypto_shash_finup(). (For simplicity only; they are equivalent.) Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com>
2017-12-08pkcs7: fix check for self-signed certificateEric Biggers1-1/+1
pkcs7_validate_trust_one() used 'x509->next == x509' to identify a self-signed certificate. That's wrong; ->next is simply the link in the linked list of certificates in the PKCS#7 message. It should be checking ->signer instead. Fix it. Fortunately this didn't actually matter because when we re-visited 'x509' on the next iteration via 'x509->signer', it was already seen and not verified, so we returned -ENOKEY anyway. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <james.l.morris@oracle.com>
2017-12-08pkcs7: return correct error code if pkcs7_check_authattrs() failsEric Biggers1-1/+3
If pkcs7_check_authattrs() returns an error code, we should pass that error code on, rather than using ENOMEM. Fixes: 99db44350672 ("PKCS#7: Appropriately restrict authenticated attributes and content type") Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <james.l.morris@oracle.com>
2017-12-08X.509: reject invalid BIT STRING for subjectPublicKeyEric Biggers1-0/+2
Adding a specially crafted X.509 certificate whose subjectPublicKey ASN.1 value is zero-length caused x509_extract_key_data() to set the public key size to SIZE_MAX, as it subtracted the nonexistent BIT STRING metadata byte. Then, x509_cert_parse() called kmemdup() with that bogus size, triggering the WARN_ON_ONCE() in kmalloc_slab(). This appears to be harmless, but it still must be fixed since WARNs are never supposed to be user-triggerable. Fix it by updating x509_cert_parse() to validate that the value has a BIT STRING metadata byte, and that the byte is 0 which indicates that the number of bits in the bitstring is a multiple of 8. It would be nice to handle the metadata byte in asn1_ber_decoder() instead. But that would be tricky because in the general case a BIT STRING could be implicitly tagged, and/or could legitimately have a length that is not a whole number of bytes. Here was the WARN (cleaned up slightly): WARNING: CPU: 1 PID: 202 at mm/slab_common.c:971 kmalloc_slab+0x5d/0x70 mm/slab_common.c:971 Modules linked in: CPU: 1 PID: 202 Comm: keyctl Tainted: G B 4.14.0-09238-g1d3b78bbc6e9 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014 task: ffff880033014180 task.stack: ffff8800305c8000 Call Trace: __do_kmalloc mm/slab.c:3706 [inline] __kmalloc_track_caller+0x22/0x2e0 mm/slab.c:3726 kmemdup+0x17/0x40 mm/util.c:118 kmemdup include/linux/string.h:414 [inline] x509_cert_parse+0x2cb/0x620 crypto/asymmetric_keys/x509_cert_parser.c:106 x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174 asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388 key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850 SYSC_add_key security/keys/keyctl.c:122 [inline] SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62 entry_SYSCALL_64_fastpath+0x1f/0x96 Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder") Cc: <stable@vger.kernel.org> # v3.7+ Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <james.l.morris@oracle.com>
2017-11-15pkcs7: Set the module licence to prevent taintingDavid Howells4-0/+9
Set the module licence to prevent the kernel from being tainted if loaded as a module. Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: David Howells <dhowells@redhat.com>
2017-11-14Merge branch 'linus' of ↵Linus Torvalds1-24/+4
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto updates from Herbert Xu: "Here is the crypto update for 4.15: API: - Disambiguate EBUSY when queueing crypto request by adding ENOSPC. This change touches code outside the crypto API. - Reset settings when empty string is written to rng_current. Algorithms: - Add OSCCA SM3 secure hash. Drivers: - Remove old mv_cesa driver (replaced by marvell/cesa). - Enable rfc3686/ecb/cfb/ofb AES in crypto4xx. - Add ccm/gcm AES in crypto4xx. - Add support for BCM7278 in iproc-rng200. - Add hash support on Exynos in s5p-sss. - Fix fallback-induced error in vmx. - Fix output IV in atmel-aes. - Fix empty GCM hash in mediatek. Others: - Fix DoS potential in lib/mpi. - Fix potential out-of-order issues with padata" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (162 commits) lib/mpi: call cond_resched() from mpi_powm() loop crypto: stm32/hash - Fix return issue on update crypto: dh - Remove pointless checks for NULL 'p' and 'g' crypto: qat - Clean up error handling in qat_dh_set_secret() crypto: dh - Don't permit 'key' or 'g' size longer than 'p' crypto: dh - Don't permit 'p' to be 0 crypto: dh - Fix double free of ctx->p hwrng: iproc-rng200 - Add support for BCM7278 dt-bindings: rng: Document BCM7278 RNG200 compatible crypto: chcr - Replace _manual_ swap with swap macro crypto: marvell - Add a NULL entry at the end of mv_cesa_plat_id_table[] hwrng: virtio - Virtio RNG devices need to be re-registered after suspend/resume crypto: atmel - remove empty functions crypto: ecdh - remove empty exit() MAINTAINERS: update maintainer for qat crypto: caam - remove unused param of ctx_map_to_sec4_sg() crypto: caam - remove unneeded edesc zeroization crypto: atmel-aes - Reset the controller before each use crypto: atmel-aes - properly set IV after {en,de}crypt hwrng: core - Reset user selected rng by writing "" to rng_current ...
2017-11-03crypto: move pub key to generic async completionGilad Ben-Yossef1-24/+4
public_key_verify_signature() is starting an async crypto op and waiting for it to complete. Move it over to generic code doing the same. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman2-0/+2
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-18pkcs7: Prevent NULL pointer dereference, since sinfo is not always set.Eric Sesterhenn1-0/+3
The ASN.1 parser does not necessarily set the sinfo field, this patch prevents a NULL pointer dereference on broken input. Fixes: 99db44350672 ("PKCS#7: Appropriately restrict authenticated attributes and content type") Signed-off-by: Eric Sesterhenn <eric.sesterhenn@x41-dsec.de> Signed-off-by: David Howells <dhowells@redhat.com> cc: stable@vger.kernel.org # 4.3+
2017-10-18KEYS: checking the input id parameters before finding asymmetric keyChun-Yi Lee1-0/+2
For finding asymmetric key, the input id_0 and id_1 parameters can not be NULL at the same time. This patch adds the BUG_ON checking for id_0 and id_1. Cc: David Howells <dhowells@redhat.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Chun-Yi Lee <jlee@suse.com> Signed-off-by: David Howells <dhowells@redhat.com>
2017-10-18KEYS: Fix the wrong index when checking the existence of second idChun-Yi Lee1-1/+1
Fix the wrong index number when checking the existence of second id in function of finding asymmetric key. The id_1 is the second id that the index in array must be 1 but not 0. Fixes: 9eb029893ad5 (KEYS: Generalise x509_request_asymmetric_key()) Cc: David Howells <dhowells@redhat.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Chun-Yi Lee <jlee@suse.com> Signed-off-by: David Howells <dhowells@redhat.com>
2017-06-09crypto : asymmetric_keys : verify_pefile:zero memory content before freeingLoganaden Velvindron1-2/+2
Signed-off-by: Loganaden Velvindron <logan@hackers.mu> Signed-off-by: Yasir Auleear <yasirmx@hackers.mu> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
2017-06-09X.509: Fix error code in x509_cert_parse()Dan Carpenter1-0/+1
We forgot to set the error code on this path so it could result in returning NULL which leads to a NULL dereference. Fixes: db6c43bd2132 ("crypto: KEYS: convert public key and digsig asym to the akcipher api") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
2017-05-23crypto: asymmetric_keys - handle EBUSY due to backlog correctlyGilad Ben-Yossef1-1/+1
public_key_verify_signature() was passing the CRYPTO_TFM_REQ_MAY_BACKLOG flag to akcipher_request_set_callback() but was not handling correctly the case where a -EBUSY error could be returned from the call to crypto_akcipher_verify() if backlog was used, possibly casuing data corruption due to use-after-free of buffers. Resolve this by handling -EBUSY correctly. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> CC: stable@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-04-04KEYS: Keyring asymmetric key restrict method with chainingMat Martineau2-45/+144
Add a restrict_link_by_key_or_keyring_chain link restriction that searches for signing keys in the destination keyring in addition to the signing key or keyring designated when the destination keyring was created. Userspace enables this behavior by including the "chain" option in the keyring restriction: keyctl(KEYCTL_RESTRICT_KEYRING, keyring, "asymmetric", "key_or_keyring:<signing key>:chain"); Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
2017-04-04KEYS: Restrict asymmetric key linkage using a specific keychainMat Martineau2-1/+105
Adds restrict_link_by_signature_keyring(), which uses the restrict_key member of the provided destination_keyring data structure as the key or keyring to search for signing keys. Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
2017-04-04KEYS: Add a lookup_restriction function for the asymmetric key typeMat Martineau1-8/+44
Look up asymmetric keyring restriction information using the key-type lookup_restrict hook. Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
2017-04-03KEYS: Split role of the keyring pointer for keyring restrict functionsMat Martineau1-3/+5
The first argument to the restrict_link_func_t functions was a keyring pointer. These functions are called by the key subsystem with this argument set to the destination keyring, but restrict_link_by_signature expects a pointer to the relevant trusted keyring. Restrict functions may need something other than a single struct key pointer to allow or reject key linkage, so the data used to make that decision (such as the trust keyring) is moved to a new, fourth argument. The first argument is now always the destination keyring. Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
2017-04-03PKCS#7: Handle blacklisted certificatesDavid Howells2-8/+25
PKCS#7: Handle certificates that are blacklisted when verifying the chain of trust on the signatures on a PKCS#7 message. Signed-off-by: David Howells <dhowells@redhat.com>
2017-04-03X.509: Allow X.509 certs to be blacklistedDavid Howells2-0/+16
Allow X.509 certs to be blacklisted based on their TBSCertificate hash. This is convenient since we have to determine this anyway to be able to check the signature on an X.509 certificate. This is also what UEFI uses in its blacklist. If a certificate built into the kernel is blacklisted, something like the following might then be seen during boot: X.509: Cert 123412341234c55c1dcc601ab8e172917706aa32fb5eaf826813547fdf02dd46 is blacklisted Problem loading in-kernel X.509 certificate (-129) where the hex string shown is the blacklisted hash. Signed-off-by: David Howells <dhowells@redhat.com>
2016-12-15Merge branch 'linus' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes the following issues: - a crash regression in the new skcipher walker - incorrect return value in public_key_verify_signature - fix for in-place signing in the sign-file utility" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: skcipher - fix crash in virtual walk sign-file: Fix inplace signing when src and dst names are both specified crypto: asymmetric_keys - set error code on failure
2016-12-14crypto: asymmetric_keys - set error code on failurePan Bian1-0/+1
In function public_key_verify_signature(), returns variable ret on error paths. When the call to kmalloc() fails, the value of ret is 0, and it is not set to an errno before returning. This patch fixes the bug. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188891 Signed-off-by: Pan Bian <bianpan2016@163.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-11-25X.509: Fix double free in x509_cert_parse() [ver #3]Andrey Ryabinin1-1/+0
We shouldn't free cert->pub->key in x509_cert_parse() because x509_free_certificate() also does this: BUG: Double free or freeing an invalid pointer ... Call Trace: [<ffffffff81896c20>] dump_stack+0x63/0x83 [<ffffffff81356571>] kasan_object_err+0x21/0x70 [<ffffffff81356ed9>] kasan_report_double_free+0x49/0x60 [<ffffffff813561ad>] kasan_slab_free+0x9d/0xc0 [<ffffffff81350b7a>] kfree+0x8a/0x1a0 [<ffffffff81844fbf>] public_key_free+0x1f/0x30 [<ffffffff818455d4>] x509_free_certificate+0x24/0x90 [<ffffffff818460bc>] x509_cert_parse+0x2bc/0x300 [<ffffffff81846cae>] x509_key_preparse+0x3e/0x330 [<ffffffff818444cf>] asymmetric_key_preparse+0x6f/0x100 [<ffffffff8178bec0>] key_create_or_update+0x260/0x5f0 [<ffffffff8178e6d9>] SyS_add_key+0x199/0x2a0 [<ffffffff821d823b>] entry_SYSCALL_64_fastpath+0x1e/0xad Object at ffff880110bd1900, in cache kmalloc-512 size: 512 .... Freed: PID = 2579 [<ffffffff8104283b>] save_stack_trace+0x1b/0x20 [<ffffffff813558f6>] save_stack+0x46/0xd0 [<ffffffff81356183>] kasan_slab_free+0x73/0xc0 [<ffffffff81350b7a>] kfree+0x8a/0x1a0 [<ffffffff818460a3>] x509_cert_parse+0x2a3/0x300 [<ffffffff81846cae>] x509_key_preparse+0x3e/0x330 [<ffffffff818444cf>] asymmetric_key_preparse+0x6f/0x100 [<ffffffff8178bec0>] key_create_or_update+0x260/0x5f0 [<ffffffff8178e6d9>] SyS_add_key+0x199/0x2a0 [<ffffffff821d823b>] entry_SYSCALL_64_fastpath+0x1e/0xad Fixes: db6c43bd2132 ("crypto: KEYS: convert public key and digsig asym to the akcipher api") Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: <stable@vger.kernel.org> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
2016-07-18KEYS: Fix for erroneous trust of incorrectly signed X.509 certsMat Martineau1-1/+1
Arbitrary X.509 certificates without authority key identifiers (AKIs) can be added to "trusted" keyrings, including IMA or EVM certs loaded from the filesystem. Signature verification is currently bypassed for certs without AKIs. Trusted keys were recently refactored, and this bug is not present in 4.6. restrict_link_by_signature should return -ENOKEY (no matching parent certificate found) if the certificate being evaluated has no AKIs, instead of bypassing signature checks and returning 0 (new certificate accepted). Reported-by: Petko Manolov <petkan@mip-labs.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
2016-07-18pefile: Fix the failure of calculation for digestLans Zhang1-1/+6
Commit e68503bd68 forgot to set digest_len and thus cause the following error reported by kexec when launching a crash kernel: kexec_file_load failed: Bad message Fixes: e68503bd68 (KEYS: Generalise system_verify_data() to provide access to internal content) Signed-off-by: Lans Zhang <jia.zhang@windriver.com> Tested-by: Dave Young <dyoung@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com> Cc: Baoquan He <bhe@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> cc: kexec@lists.infradead.org cc: linux-crypto@vger.kernel.org Signed-off-by: James Morris <james.l.morris@oracle.com>
2016-07-18PKCS#7: Fix panic when referring to the empty AKID when DEBUG definedLans Zhang1-1/+1
This fix resolves the following kernel panic if an empty or missing AuthorityKeyIdentifier is encountered and DEBUG is defined in pkcs7_verify.c. [ 459.041989] PKEY: <==public_key_verify_signature() = 0 [ 459.041993] PKCS7: Verified signature 1 [ 459.041995] PKCS7: ==> pkcs7_verify_sig_chain() [ 459.041999] PKCS7: verify Sample DB Certificate for SCP: 01 [ 459.042002] PKCS7: - issuer Sample KEK Certificate for SCP [ 459.042014] BUG: unable to handle kernel NULL pointer dereference at (null) [ 459.042135] IP: [<ffffffff813e7b4c>] pkcs7_verify+0x72c/0x7f0 [ 459.042217] PGD 739e6067 PUD 77719067 PMD 0 [ 459.042286] Oops: 0000 [#1] PREEMPT SMP [ 459.042328] Modules linked in: [ 459.042368] CPU: 0 PID: 474 Comm: kexec Not tainted 4.7.0-rc7-WR8.0.0.0_standard+ #18 [ 459.042462] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 10/09/2014 [ 459.042586] task: ffff880073a50000 ti: ffff8800738e8000 task.ti: ffff8800738e8000 [ 459.042675] RIP: 0010:[<ffffffff813e7b4c>] [<ffffffff813e7b4c>] pkcs7_verify+0x72c/0x7f0 [ 459.042784] RSP: 0018:ffff8800738ebd58 EFLAGS: 00010246 [ 459.042845] RAX: 0000000000000000 RBX: ffff880076b7da80 RCX: 0000000000000006 [ 459.042929] RDX: 0000000000000001 RSI: ffffffff81c85001 RDI: ffffffff81ca00a9 [ 459.043014] RBP: ffff8800738ebd98 R08: 0000000000000400 R09: ffff8800788a304c [ 459.043098] R10: 0000000000000000 R11: 00000000000060ca R12: ffff8800769a2bc0 [ 459.043182] R13: ffff880077358300 R14: 0000000000000000 R15: ffff8800769a2dc0 [ 459.043268] FS: 00007f24cc741700(0000) GS:ffff880074e00000(0000) knlGS:0000000000000000 [ 459.043365] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 459.043431] CR2: 0000000000000000 CR3: 0000000073a36000 CR4: 00000000001006f0 [ 459.043514] Stack: [ 459.043530] 0000000000000000 ffffffbf00000020 31ffffff813e68b0 0000000000000002 [ 459.043644] ffff8800769a2bc0 0000000000000000 00000000007197b8 0000000000000002 [ 459.043756] ffff8800738ebdd8 ffffffff81153fb1 0000000000000000 0000000000000000 [ 459.043869] Call Trace: [ 459.043898] [<ffffffff81153fb1>] verify_pkcs7_signature+0x61/0x140 [ 459.043974] [<ffffffff813e7f0b>] verify_pefile_signature+0x2cb/0x830 [ 459.044052] [<ffffffff813e8470>] ? verify_pefile_signature+0x830/0x830 [ 459.044134] [<ffffffff81048e25>] bzImage64_verify_sig+0x15/0x20 [ 459.046332] [<ffffffff81046e09>] arch_kexec_kernel_verify_sig+0x29/0x40 [ 459.048552] [<ffffffff810f10e4>] SyS_kexec_file_load+0x1f4/0x6c0 [ 459.050768] [<ffffffff81050e36>] ? __do_page_fault+0x1b6/0x550 [ 459.052996] [<ffffffff8199241f>] entry_SYSCALL_64_fastpath+0x17/0x93 [ 459.055242] Code: e8 0a d6 ff ff 85 c0 0f 88 7a fb ff ff 4d 39 fd 4d 89 7d 08 74 45 4d 89 fd e9 14 fe ff ff 4d 8b 76 08 31 c0 48 c7 c7 a9 00 ca 81 <41> 0f b7 36 49 8d 56 02 e8 d0 91 d6 ff 4d 8b 3c 24 4d 85 ff 0f [ 459.060535] RIP [<ffffffff813e7b4c>] pkcs7_verify+0x72c/0x7f0 [ 459.063040] RSP <ffff8800738ebd58> [ 459.065456] CR2: 0000000000000000 [ 459.075998] ---[ end trace c15f0e897cda28dc ]--- Signed-off-by: Lans Zhang <jia.zhang@windriver.com> Signed-off-by: David Howells <dhowells@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Baoquan He <bhe@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> cc: linux-crypto@vger.kernel.org cc: kexec@lists.infradead.org Signed-off-by: James Morris <james.l.morris@oracle.com>
2016-05-30Merge branch 'linus' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes the following issues: - missing selection in public_key that may result in a build failure - Potential crash in error path in omap-sham - ccp AES XTS bug that affects requests larger than 4096" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: ccp - Fix AES XTS error for request sizes above 4096 crypto: public_key: select CRYPTO_AKCIPHER crypto: omap-sham - potential Oops on error in probe
2016-05-19crypto: public_key: select CRYPTO_AKCIPHERArnd Bergmann1-0/+1
In some rare randconfig builds, we can end up with ASYMMETRIC_PUBLIC_KEY_SUBTYPE enabled but CRYPTO_AKCIPHER disabled, which fails to link because of the reference to crypto_alloc_akcipher: crypto/built-in.o: In function `public_key_verify_signature': :(.text+0x110e4): undefined reference to `crypto_alloc_akcipher' This adds a Kconfig 'select' statement to ensure the dependency is always there. Cc: <stable@vger.kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-05-11KEYS: The PKCS#7 test key type should use the secondary keyringDavid Howells1-1/+1
The PKCS#7 test key type should use the secondary keyring instead of the built-in keyring if available as the source of trustworthy keys. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-11KEYS: Move the point of trust determination to __key_link()David Howells3-56/+33
Move the point at which a key is determined to be trustworthy to __key_link() so that we use the contents of the keyring being linked in to to determine whether the key being linked in is trusted or not. What is 'trusted' then becomes a matter of what's in the keyring. Currently, the test is done when the key is parsed, but given that at that point we can only sensibly refer to the contents of the system trusted keyring, we can only use that as the basis for working out the trustworthiness of a new key. With this change, a trusted keyring is a set of keys that once the trusted-only flag is set cannot be added to except by verification through one of the contained keys. Further, adding a key into a trusted keyring, whilst it might grant trustworthiness in the context of that keyring, does not automatically grant trustworthiness in the context of a second keyring to which it could be secondarily linked. To accomplish this, the authentication data associated with the key source must now be retained. For an X.509 cert, this means the contents of the AuthorityKeyIdentifier and the signature data. If system keyrings are disabled then restrict_link_by_builtin_trusted() resolves to restrict_link_reject(). The integrity digital signature code still works correctly with this as it was previously using KEY_FLAG_TRUSTED_ONLY, which doesn't permit anything to be added if there is no system keyring against which trust can be determined. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-11KEYS: Make the system trusted keyring depend on the asymmetric key typeDavid Howells1-1/+1
Make the system trusted keyring depend on the asymmetric key type as there's not a lot of point having it if you can't then load asymmetric keys onto it. This requires the ASYMMETRIC_KEY_TYPE to be made a bool, not a tristate, as the Kconfig language doesn't then correctly force ASYMMETRIC_KEY_TYPE to 'y' rather than 'm' if SYSTEM_TRUSTED_KEYRING is 'y'. Making SYSTEM_TRUSTED_KEYRING *select* ASYMMETRIC_KEY_TYPE instead doesn't work as the Kconfig interpreter then wrongly complains about dependency loops. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-11X.509: Move the trust validation code out to its own fileDavid Howells4-80/+116
Move the X.509 trust validation code out to its own file so that it can be generalised. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-11X.509: Use verify_signature() if we have a struct key * to useDavid Howells1-2/+1
We should call verify_signature() rather than directly calling public_key_verify_signature() if we have a struct key to use as we shouldn't be poking around in the private data of the key struct as that's subtype dependent. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-11KEYS: Generalise x509_request_asymmetric_key()David Howells4-35/+33
Generalise x509_request_asymmetric_key(). It doesn't really have any dependencies on X.509 features as it uses generalised IDs and the public_key structs that contain data extracted from X.509. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-11KEYS: Move x509_request_asymmetric_key() to asymmetric_type.cDavid Howells2-89/+89
Move x509_request_asymmetric_key() to asymmetric_type.c so that it can be generalised. Signed-off-by: David Howells <dhowells@redhat.com>
2016-04-06PKCS#7: Make trust determination dependent on contents of trust keyringDavid Howells5-19/+5
Make the determination of the trustworthiness of a key dependent on whether a key that can verify it is present in the supplied ring of trusted keys rather than whether or not the verifying key has KEY_FLAG_TRUSTED set. verify_pkcs7_signature() will return -ENOKEY if the PKCS#7 message trust chain cannot be verified. Signed-off-by: David Howells <dhowells@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-24 01:12:09 +0000