linux-stable.git/include/keys, branch v6.6.144

keys: Pin request_key_auth payload in instantiate paths

2026-07-04T11:42:25+00:00

commit fd15b457a86939c38aa12116adabd8ff686c5e51 upstream.

A: request_key()       B: KEYCTL_INSTANTIATE_IOV
================       =========================

create auth key
store rka in auth key
wait for helper
                       get auth key
                       load rka from auth key
                       copy user payload
                       sleep on #PF

helper completed
detach and free rka
destroy auth key
                       wake up
                       use rka->target_key
                       **USE-AFTER-FREE**

Give request_key_auth payloads a refcount.  Take a payload reference while
authkey->sem stabilizes the payload and revocation state.  Hold that
reference across the instantiate and reject paths.  Drop the auth key
owning reference from revoke and destroy.

[jarkko: Replaced the first two paragraphs of text with an actual
 concurrency scenario.]
Cc: stable@vger.kernel.org # v5.10+
Fixes: b5f545c880a2 ("[PATCH] keys: Permit running process to instantiate keys")
Reported-by: Shaomin Chen 
Closes: https://lore.kernel.org/r/20260519144403.436694-1-eeesssooo020@gmail.com
Signed-off-by: Shaomin Chen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

integrity: PowerVM support for loading third party code signing keys

2023-08-17T20:12:35+00:00

On secure boot enabled PowerVM LPAR, third party code signing keys are
needed during early boot to verify signed third party modules. These
third party keys are stored in moduledb object in the Platform
KeyStore (PKS).

Load third party code signing keys onto .secondary_trusted_keys keyring.

Signed-off-by: Nayna Jain 
Reviewed-and-tested-by: Mimi Zohar 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Nageswara R Sastry 
Signed-off-by: Jarkko Sakkinen

KEYS: DigitalSignature link restriction

2023-08-17T20:12:20+00:00

Add a new link restriction.  Restrict the addition of keys in a keyring
based on the key having digitalSignature usage set. Additionally, verify
the new certificate against the ones in the system keyrings.  Add two
additional functions to use the new restriction within either the builtin
or secondary keyrings.

[jarkko@kernel.org: Fix checkpatch.pl --strict issues]
Signed-off-by: Eric Snowberg 
Reviewed-and-tested-by: Mimi Zohar 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen

KEYS: Add forward declaration in asymmetric-parser.h

2023-06-23T08:15:37+00:00

Add forward declaration for struct key_preparsed_payload so that
this header file is self-contained.

Signed-off-by: Herbert Xu

certs: Move load_certificate_list() to be with the asymmetric keys code

2022-06-21T15:05:06+00:00

Move load_certificate_list(), which loads a series of binary X.509
certificates from a blob and inserts them as keys into a keyring, to be
with the asymmetric keys code that it drives.

This makes it easier to add FIPS selftest code in which we need to load up
a private keyring for the tests to use.

Signed-off-by: David Howells 
Reviewed-by: Simo Sorce 
Reviewed-by: Herbert Xu 
cc: keyrings@vger.kernel.org
cc: linux-crypto@vger.kernel.org
Link: https://lore.kernel.org/r/165515742145.1554877.13488098107542537203.stgit@warthog.procyon.org.uk/

KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

2022-05-23T15:47:50+00:00

The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
built into many newer i.MX and QorIQ SoCs by NXP.

The CAAM does crypto acceleration, hardware number generation and
has a blob mechanism for encapsulation/decapsulation of sensitive material.

This blob mechanism depends on a device specific random 256-bit One Time
Programmable Master Key that is fused in each SoC at manufacturing
time. This key is unreadable and can only be used by the CAAM for AES
encryption/decryption of user data.

This makes it a suitable backend (source) for kernel trusted keys.

Previous commits generalized trusted keys to support multiple backends
and added an API to access the CAAM blob mechanism. Based on these,
provide the necessary glue to use the CAAM for trusted keys.

Reviewed-by: David Gstir 
Reviewed-by: Pankaj Gupta 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Tim Harvey 
Tested-by: Matthias Schiffer 
Tested-by: Pankaj Gupta 
Tested-by: Michael Walle  # on ls1028a (non-E and E)
Tested-by: John Ernberg  # iMX8QXP
Signed-off-by: Ahmad Fatoum 
Signed-off-by: Jarkko Sakkinen

KEYS: trusted: allow use of kernel RNG for key material

2022-05-23T15:47:50+00:00

The two existing trusted key sources don't make use of the kernel RNG,
but instead let the hardware doing the sealing/unsealing also
generate the random key material. However, both users and future
backends may want to place less trust into the quality of the trust
source's random number generator and instead reuse the kernel entropy
pool, which can be seeded from multiple entropy sources.

Make this possible by adding a new trusted.rng parameter,
that will force use of the kernel RNG. In its absence, it's up
to the trust source to decide, which random numbers to use,
maintaining the existing behavior.

Suggested-by: Jarkko Sakkinen 
Acked-by: Sumit Garg 
Acked-by: Pankaj Gupta 
Reviewed-by: David Gstir 
Reviewed-by: Pankaj Gupta 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Pankaj Gupta 
Tested-by: Michael Walle  # on ls1028a (non-E and E)
Tested-by: John Ernberg  # iMX8QXP
Signed-off-by: Ahmad Fatoum 
Signed-off-by: Jarkko Sakkinen

certs: Factor out the blacklist hash creation

2022-05-23T15:47:49+00:00

Factor out the blacklist hash creation with the get_raw_hash() helper.
This also centralize the "tbs" and "bin" prefixes and make them private,
which help to manage them consistently.

Cc: David Howells 
Cc: David S. Miller 
Cc: David Woodhouse 
Cc: Eric Snowberg 
Cc: Herbert Xu 
Cc: Jarkko Sakkinen 
Signed-off-by: Mickaël Salaün 
Link: https://lore.kernel.org/r/20210712170313.884724-5-mic@digikod.net
Signed-off-by: Jarkko Sakkinen

KEYS: Introduce link restriction for machine keys

2022-03-08T11:55:52+00:00

Introduce a new link restriction that includes the trusted builtin,
secondary and machine keys. The restriction is based on the key to be
added being vouched for by a key in any of these three keyrings.

With the introduction of the machine keyring, the end-user may choose to
trust Machine Owner Keys (MOK) within the kernel. If they have chosen to
trust them, the .machine keyring will contain these keys.  If not, the
machine keyring will always be empty.  Update the restriction check to
allow the secondary trusted keyring to also trust machine keys.

Allow the .machine keyring to be linked to the secondary_trusted_keys.
After the link is created, keys contained in the .machine keyring will
automatically be searched when searching secondary_trusted_keys.

Suggested-by: Mimi Zohar 
Signed-off-by: Eric Snowberg 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Mimi Zohar 
Signed-off-by: Jarkko Sakkinen

KEYS: store reference to machine keyring

2022-03-08T11:55:52+00:00

Expose the .machine keyring created in integrity code by adding
a reference.  Store a reference to the machine keyring in
system keyring code. The system keyring code needs this to complete
the keyring link to the machine keyring.

Signed-off-by: Eric Snowberg 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Mimi Zohar 
Signed-off-by: Jarkko Sakkinen