BMC/Intel-BMC/linux.git/security/keys, branch dev-5.15-intel

KEYS: trusted: Avoid calling null function trusted_key_exit

2022-04-08T12:23:09+00:00

[ Upstream commit c5d1ed846e15090bc90dfdaafc07eac066e070bb ] If one loads and unloads the trusted module, trusted_key_exit can be NULL. Call it through static_call_cond() to avoid a kernel trap. Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Signed-off-by: Dave Kleikamp Cc: Sumit Garg Cc: James Bottomley Cc: Jarkko Sakkinen Cc: Mimi Zohar Cc: David Howells Cc: James Morris Cc: "Serge E. Hallyn" Cc: linux-integrity@vger.kernel.org Cc: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin

KEYS: trusted: Fix trusted key backends when building as module

2022-04-08T12:23:09+00:00

[ Upstream commit 969a26446bcd142faedfe8c6f41cd7668596c1fa ] Before this commit the kernel could end up with no trusted key sources even though both of the currently supported backends (TPM and TEE) were compiled as modules. This manifested in the trusted key type not being registered at all. When checking if a CONFIG_… preprocessor variable is defined we only test for the builtin (=y) case and not the module (=m) case. By using the IS_REACHABLE() macro we do test for both cases. Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Reviewed-by: Jarkko Sakkinen Reviewed-by: Ahmad Fatoum Reviewed-by: Sumit Garg Signed-off-by: Andreas Rammhold Tested-by: Ahmad Fatoum Signed-off-by: Ahmad Fatoum Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin

KEYS: fix length validation in keyctl_pkey_params_get_2()

2022-04-08T12:22:51+00:00

commit c51abd96837f600d8fd940b6ab8e2da578575504 upstream. In many cases, keyctl_pkey_params_get_2() is validating the user buffer lengths against the wrong algorithm properties. Fix it to check against the correct properties. Probably this wasn't noticed before because for all asymmetric keys of the "public_key" subtype, max_data_size == max_sig_size == max_enc_size == max_dec_size. However, this isn't necessarily true for the "asym_tpm" subtype (it should be, but it's not strictly validated). Of course, future key types could have different values as well. Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]") Cc: # v4.20+ Signed-off-by: Eric Biggers Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman

ucounts: Move get_ucounts from cred_alloc_blank to key_change_session_keyring

2021-10-20T15:34:20+00:00

Setting cred->ucounts in cred_alloc_blank does not make sense. The uid and user_ns are deliberately not set in cred_alloc_blank but instead the setting is delayed until key_change_session_keyring. So move dealing with ucounts into key_change_session_keyring as well. Unfortunately that movement of get_ucounts adds a new failure mode to key_change_session_keyring. I do not see anything stopping the parent process from calling setuid and changing the relevant part of it's cred while keyctl_session_to_parent is running making it fundamentally necessary to call get_ucounts in key_change_session_keyring. Which means that the new failure mode cannot be avoided. A failure of key_change_session_keyring results in a single threaded parent keeping it's existing credentials. Which results in the parent process not being able to access the session keyring and whichever keys are in the new keyring. Further get_ucounts is only expected to fail if the number of bits in the refernece count for the structure is too few. Since the code has no other way to report the failure of get_ucounts and because such failures are not expected to be common add a WARN_ONCE to report this problem to userspace. Between the WARN_ONCE and the parent process not having access to the keys in the new session keyring I expect any failure of get_ucounts will be noticed and reported and we can find another way to handle this condition. (Possibly by just making ucounts->count an atomic_long_t). Cc: stable@vger.kernel.org Fixes: 905ae01c4ae2 ("Add a reference to ucounts for each cred") Link: https://lkml.kernel.org/r/7k0ias0uf.fsf_-_@disp2133 Tested-by: Yu Zhao Reviewed-by: Alexey Gladkov Signed-off-by: "Eric W. Biederman"

trusted-keys: match tpm_get_ops on all return paths

2021-05-12T19:36:37+00:00

The `tpm_get_ops` call at the beginning of the function is not paired with a `tpm_put_ops` on this return path. Cc: stable@vger.kernel.org Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Reported-by: Dan Carpenter Signed-off-by: Ben Boeckel Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

KEYS: trusted: Fix memory leak on object td

2021-05-12T19:36:36+00:00

Two error return paths are neglecting to free allocated object td, causing a memory leak. Fix this by returning via the error return path that securely kfree's td. Fixes clang scan-build warning: security/keys/trusted-keys/trusted_tpm1.c:496:10: warning: Potential memory leak [unix.Malloc] Cc: stable@vger.kernel.org Fixes: 5df16caada3f ("KEYS: trusted: Fix incorrect handling of tpm_get_random()") Signed-off-by: Colin Ian King Reviewed-by: Nick Desaulniers Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

Merge tag 'queue' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/tpmdd

2021-04-26T15:31:03+00:00

Pull tpm fixes from James Bottomley: "Fix a regression in the TPM trusted keys caused by the generic rework to add ARM TEE based trusted keys. Without this fix, the TPM trusted key subsystem fails to add or load any keys" * tag 'queue' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/tpmdd: KEYS: trusted: fix TPM trusted keys for generic framework

Merge tag 'tpmdd-next-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd

2021-04-26T15:27:59+00:00

Pull tpm updates from Jarkko Sakkinen: "New features: - ARM TEE backend for kernel trusted keys to complete the existing TPM backend - ASN.1 format for TPM2 trusted keys to make them interact with the user space stack, such as OpenConnect VPN Other than that, a bunch of bug fixes" * tag 'tpmdd-next-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: KEYS: trusted: Fix missing null return from kzalloc call char: tpm: fix error return code in tpm_cr50_i2c_tis_recv() MAINTAINERS: Add entry for TEE based Trusted Keys doc: trusted-encrypted: updates with TEE as a new trust source KEYS: trusted: Introduce TEE based Trusted Keys KEYS: trusted: Add generic trusted keys framework security: keys: trusted: Make sealed key properly interoperable security: keys: trusted: use ASN.1 TPM2 key format for the blobs security: keys: trusted: fix TPM2 authorizations oid_registry: Add TCG defined OIDS for TPM keys lib: Add ASN.1 encoder tpm: vtpm_proxy: Avoid reading host log when using a virtual device tpm: acpi: Check eventlog signature before using it tpm: efi: Use local variable for calculating final log size

KEYS: trusted: fix TPM trusted keys for generic framework

2021-04-21T23:30:06+00:00

The generic framework patch broke the current TPM trusted keys because it doesn't correctly remove the values consumed by the generic parser before passing them on to the implementation specific parser. Fix this by having the generic parser return the string minus the consumed tokens. Additionally, there may be no tokens left for the implementation specific parser, so make it handle the NULL case correctly and finally fix a TPM 1.2 specific check for no keyhandle. Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Tested-by: Sumit Garg Signed-off-by: James Bottomley

KEYS: trusted: Fix TPM reservation for seal/unseal

2021-04-21T23:28:20+00:00

The original patch 8c657a0590de ("KEYS: trusted: Reserve TPM for seal and unseal operations") was correct on the mailing list: https://lore.kernel.org/linux-integrity/20210128235621.127925-4-jarkko@kernel.org/ But somehow got rebased so that the tpm_try_get_ops() in tpm2_seal_trusted() got lost. This causes an imbalanced put of the TPM ops and causes oopses on TIS based hardware. This fix puts back the lost tpm_try_get_ops() Fixes: 8c657a0590de ("KEYS: trusted: Reserve TPM for seal and unseal operations") Reported-by: Mimi Zohar Acked-by: Mimi Zohar Signed-off-by: James Bottomley