Eric Lee / smarc-fsl-linux-kernel

16 Feb, 2021

1 commit

24 May, 2019

1 commit

  • b4d0d230c   treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 36 ... Browse Code »

    Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public licence as published by
    the free software foundation either version 2 of the licence or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 114 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Kate Stewart
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190520170857.552531963@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

22 Feb, 2018

1 commit

  • 4b34968e7   X.509: fix NULL dereference when restricting key with unsupported_sig ... Browse Code »

    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: # v4.7+
    Signed-off-by: Eric Biggers
    Signed-off-by: David Howells

    Eric Biggers
     

05 Apr, 2017

2 commits

04 Apr, 2017

1 commit

  • aaf66c883   KEYS: Split role of the keyring pointer for keyring restrict functions ... Browse Code »

    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

    Mat Martineau
     

18 Jul, 2016

1 commit

  • acddc7201   KEYS: Fix for erroneous trust of incorrectly signed X.509 certs ... Browse Code »

    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

    Mat Martineau
     

12 Apr, 2016

2 commits

  • a511e1af8   KEYS: Move the point of trust determination to __key_link() ... Browse Code »

    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

    David Howells
     
  • cfb664ff2   X.509: Move the trust validation code out to its own file ... Browse Code »

    Move the X.509 trust validation code out to its own file so that it can be
    generalised.

    Signed-off-by: David Howells

    David Howells