Skip to contentSkip to conversation

crypto: asymmetric_keys: copy X.509 TBS for data signature algorithms

PATCH In review Jérémy Jean 2 participants 2 messages Aug 21 – Sep 23

Subsystems (3)
Crypto API Keys/keyrings Asymmetric keys
lore
Share & tools
lore

Jérémy Jean

author
#0 lore raw

PATCH 1/1 crypto: asymmetric_keys: copy X.509 TBS for data signature algorithms

For signature algorithms operating on a message rather than a digest, x509_get_sig_params() points sig->m directly into cert->tbs. cert->tbs is the preparsed add_key() payload. The syscall wipes and frees it on return, while the instantiated key retains public_key_signature.

A later KEYCTL_LINK into an asymmetric restricted keyring therefore passes a dangling message pointer to ML-DSA. KASAN reports a slab-use-after-free in mldsa_verify(), with allocation and free provenance both leading to __do_sys_add_key(). Reuse is also an integrity issue: bytes occupying the freed object become the authenticated message instead of the certificate's own TBSCertificate.

Give the signature object its own copy of the TBS, as is already done for a precomputed digest, and release it through the existing m_free contract.

Fixes f3eccecd782d ("pkcs7: Allow the signing algo to do whatever digestion it wants itself")
Signed-off-by Jérémy Jean <[email protected]>
Assisted-by Codex:gpt-5
---
 crypto/asymmetric_keys/x509_public_key.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
crypto/asymmetric_keys/x509_public_key.c +4 -2
index 25cf8ac..5c9165a 100644
@@ -53,9 +53,11 @@ int x509_get_sig_params(struct x509_certificate *cert)
 
 	if (sig->algo_takes_data) {
 		/* The signature algorithm does whatever passes for hashing. */
-		sig->m = (u8 *)cert->tbs;
+		sig->m = kmemdup(cert->tbs, cert->tbs_size, GFP_KERNEL);
+		if (!sig->m)
+			return -ENOMEM;
 		sig->m_size = cert->tbs_size;
-		sig->m_free = false;
+		sig->m_free = true;
 		goto out;
 	}
Signature · 1 line
2.47.3
maintainer
#1 lore raw
Quoted 15 lines · Jérémy Jean

For signature algorithms operating on a message rather than a digest, x509_get_sig_params() points sig->m directly into cert->tbs. cert->tbs is the preparsed add_key() payload. The syscall wipes and frees it on return, while the instantiated key retains public_key_signature.

A later KEYCTL_LINK into an asymmetric restricted keyring therefore passes a dangling message pointer to ML-DSA. KASAN reports a slab-use-after-free in mldsa_verify(), with allocation and free provenance both leading to __do_sys_add_key(). Reuse is also an integrity issue: bytes occupying the freed object become the authenticated message instead of the certificate's own TBSCertificate.

Give the signature object its own copy of the TBS, as is already done for a precomputed digest, and release it through the existing m_free contract.

Quoted 6 lines
Fixes f3eccecd782d ("pkcs7: Allow the signing algo to do whatever digestion it wants itself")
Signed-off-by Jérémy Jean <[email protected]>
Assisted-by Codex:gpt-5
---
 crypto/asymmetric_keys/x509_public_key.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Patch applied. Thanks.

Signature · 3 lines
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt