crypto: asymmetric_keys/x509 - 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: f3eccecd78 ("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
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

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;
 	}