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

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

[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.

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

diff --git a/crypto/asymmetric_keys/x509_public_key.c b/crypto/asymmetric_keys/x509_public_key.c
index 25cf8ac..5c9165a 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -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;
 	}
 
-- 
2.47.3

Re: [PATCH] crypto: asymmetric_keys: copy X.509 TBS for data signature algorithms

[Herbert Xu]

On Fri, Aug 21, 2026 at 07:25:03PM +0000, Jérémy Jean wrote:
> 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 <Jeremy.Jean@oss.cyber.gouv.fr>
> Assisted-by: Codex:gpt-5
> ---
>  crypto/asymmetric_keys/x509_public_key.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt