17 Aug, 2018
1 commit
-
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
Signed-off-by: David Howells
Cc: keyrings@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Signed-off-by: Linus Torvalds
26 Jun, 2018
1 commit
-
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
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
16 Jun, 2018
1 commit
-
As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fixManually checked if the produced result is valid, removing a few
false-positives.Acked-by: Takashi Iwai
Acked-by: Masami Hiramatsu
Acked-by: Stephen Boyd
Acked-by: Charles Keepax
Acked-by: Mathieu Poirier
Reviewed-by: Coly Li
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Jonathan Corbet
07 Apr, 2018
3 commits
-
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.hRename generated files to *.asn1.[ch] for consistency.
Signed-off-by: Masahiro Yamada
-
Clean up these patterns from the top Makefile to omit 'clean-files'
in each Makefile.Signed-off-by: Masahiro Yamada
-
These are common patterns where source files are parsed by the
asn1_compiler.Signed-off-by: Masahiro Yamada
22 Feb, 2018
5 commits
-
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 @sFixes: a511e1af8b12 ("KEYS: Move the point of trust determination to __key_link()")
Cc: # v4.7+
Signed-off-by: Eric Biggers
Signed-off-by: David Howells -
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 @sFixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier")
Reported-by: Paolo Valente
Cc: Paolo Valente
Cc: # v4.7+
Signed-off-by: Eric Biggers
Signed-off-by: David Howells -
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
Signed-off-by: David Howells -
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: # v4.12+
Signed-off-by: Eric Biggers
Signed-off-by: David Howells -
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: # v4.7+
Signed-off-by: Eric Biggers
Signed-off-by: David Howells
08 Dec, 2017
7 commits
-
->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: # v4.6+
Signed-off-by: Eric Biggers
Signed-off-by: David Howells -
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
Signed-off-by: David Howells -
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
Signed-off-by: David Howells -
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
Signed-off-by: David Howells -
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
Signed-off-by: David Howells
Reviewed-by: James Morris -
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
Signed-off-by: David Howells
Reviewed-by: James Morris -
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/0x96Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder")
Cc: # v3.7+
Signed-off-by: Eric Biggers
Signed-off-by: David Howells
Reviewed-by: James Morris
16 Nov, 2017
1 commit
-
Set the module licence to prevent the kernel from being tainted if loaded
as a module.Reported-by: Randy Dunlap
Signed-off-by: David Howells
15 Nov, 2017
1 commit
-
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
...
03 Nov, 2017
1 commit
-
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
Signed-off-by: Herbert Xu
02 Nov, 2017
1 commit
-
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
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
18 Oct, 2017
3 commits
-
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
Signed-off-by: David Howells
cc: stable@vger.kernel.org # 4.3+ -
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
Cc: Herbert Xu
Cc: "David S. Miller"
Signed-off-by: Chun-Yi Lee
Signed-off-by: David Howells -
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
Cc: Herbert Xu
Cc: "David S. Miller"
Signed-off-by: Chun-Yi Lee
Signed-off-by: David Howells
09 Jun, 2017
2 commits
-
Signed-off-by: Loganaden Velvindron
Signed-off-by: Yasir Auleear
Signed-off-by: David Howells
Signed-off-by: James Morris -
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
Signed-off-by: David Howells
Signed-off-by: James Morris
23 May, 2017
1 commit
-
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
CC: stable@vger.kernel.org
Signed-off-by: Herbert Xu
05 Apr, 2017
3 commits
-
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::chain");Signed-off-by: Mat Martineau
-
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
-
Look up asymmetric keyring restriction information using the key-type
lookup_restrict hook.Signed-off-by: Mat Martineau
04 Apr, 2017
1 commit
-
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
03 Apr, 2017
2 commits
-
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
-
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
16 Dec, 2016
1 commit
-
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
14 Dec, 2016
1 commit
-
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
Signed-off-by: David Howells
Signed-off-by: Herbert Xu
25 Nov, 2016
1 commit
-
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:
[] dump_stack+0x63/0x83
[] kasan_object_err+0x21/0x70
[] kasan_report_double_free+0x49/0x60
[] kasan_slab_free+0x9d/0xc0
[] kfree+0x8a/0x1a0
[] public_key_free+0x1f/0x30
[] x509_free_certificate+0x24/0x90
[] x509_cert_parse+0x2bc/0x300
[] x509_key_preparse+0x3e/0x330
[] asymmetric_key_preparse+0x6f/0x100
[] key_create_or_update+0x260/0x5f0
[] SyS_add_key+0x199/0x2a0
[] entry_SYSCALL_64_fastpath+0x1e/0xad
Object at ffff880110bd1900, in cache kmalloc-512 size: 512
....
Freed:
PID = 2579
[] save_stack_trace+0x1b/0x20
[] save_stack+0x46/0xd0
[] kasan_slab_free+0x73/0xc0
[] kfree+0x8a/0x1a0
[] x509_cert_parse+0x2a3/0x300
[] x509_key_preparse+0x3e/0x330
[] asymmetric_key_preparse+0x6f/0x100
[] key_create_or_update+0x260/0x5f0
[] SyS_add_key+0x199/0x2a0
[] entry_SYSCALL_64_fastpath+0x1e/0xadFixes: db6c43bd2132 ("crypto: KEYS: convert public key and digsig asym to the akcipher api")
Signed-off-by: Andrey Ryabinin
Cc:
Signed-off-by: David Howells
Signed-off-by: James Morris
18 Jul, 2016
3 commits
-
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
Signed-off-by: Mat Martineau
Signed-off-by: David Howells
Signed-off-by: James Morris -
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
Tested-by: Dave Young
Signed-off-by: David Howells
Cc: Baoquan He
Cc: Vivek Goyal
cc: kexec@lists.infradead.org
cc: linux-crypto@vger.kernel.org
Signed-off-by: James Morris -
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: 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: [] 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:[] [] 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] [] verify_pkcs7_signature+0x61/0x140
[ 459.043974] [] verify_pefile_signature+0x2cb/0x830
[ 459.044052] [] ? verify_pefile_signature+0x830/0x830
[ 459.044134] [] bzImage64_verify_sig+0x15/0x20
[ 459.046332] [] arch_kexec_kernel_verify_sig+0x29/0x40
[ 459.048552] [] SyS_kexec_file_load+0x1f4/0x6c0
[ 459.050768] [] ? __do_page_fault+0x1b6/0x550
[ 459.052996] [] 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 0f b7 36 49 8d 56 02 e8 d0 91 d6 ff 4d 8b 3c 24 4d 85 ff 0f
[ 459.060535] RIP [] pkcs7_verify+0x72c/0x7f0
[ 459.063040] RSP
[ 459.065456] CR2: 0000000000000000
[ 459.075998] ---[ end trace c15f0e897cda28dc ]---Signed-off-by: Lans Zhang
Signed-off-by: David Howells
Cc: Dave Young
Cc: Baoquan He
Cc: Vivek Goyal
cc: linux-crypto@vger.kernel.org
cc: kexec@lists.infradead.org
Signed-off-by: James Morris
