All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hui Peng <benquike@gmail.com>
To: David Howells <dhowells@redhat.com>,
	Lukas Wunner <lukas@wunner.de>, Ignat Korchagin <ignat@linux.win>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Paul Moore <paul@paul-moore.com>,
	keyrings@vger.kernel.org, linux-crypto@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, Hui Peng <benquike@gmail.com>,
	stable@vger.kernel.org
Subject: [PATCH v2] certs: x509: duplicate cert->tbs when sig->algo_takes_data is set
Date: Sun, 20 Sep 2026 23:52:49 +0000	[thread overview]
Message-ID: <20260920235249.260530-1-benquike@gmail.com> (raw)
In-Reply-To: <CAHC9VhS7sZQaPaRswKQ1ETrReEPB2f5buNAMGSXqZ1iBKTs+bg@mail.gmail.com>

In x509_get_sig_params(), when sig->algo_takes_data is true, sig->m is
assigned (u8 *)cert->tbs with sig->m_free = false. However, cert->tbs
points into the temporary ASN.1 buffer (prep->data) passed to
x509_cert_parse(), while cert->sig is retained in
prep->payload.data[asym_auth] by x509_key_preparse() after prep->data
is freed by the caller. Subsequent signature verification on the key's
public_key_signature dereferences the freed TBS buffer.

Duplicate cert->tbs with kmemdup() and set sig->m_free = true so sig->m
remains valid for the lifetime of struct public_key_signature.

Tested in QEMU against Linux 7.3.0-rc3 with KASAN enabled by adding an
ML-DSA-44 (OID 2.16.840.1.101.3.4.3.17) X.509 certificate via
add_key("asymmetric", ...) and linking it into a signature-restricted
keyring via keyctl(KEYCTL_LINK), which triggers the following KASAN
slab-use-after-free before this patch:

  BUG: KASAN: slab-use-after-free in mldsa_verify+0x95/0xa0 [mldsa]
  Read of size 1 at addr ffff88800108c004 by task init/1

  Call Trace:
   <TASK>
   dump_stack_lvl+0x70/0xa0
   print_report+0x153/0x4c6
   kasan_report+0xf1/0x120
   mldsa_verify+0x95/0xa0 [mldsa]
   public_key_verify_signature+0x5cb/0x8e0
   verify_signature+0xe4/0x130
   key_or_keyring_common+0x428/0x850
   key_link+0x22e/0x360
   keyctl_keyring_link+0x6b/0xc0
   __do_sys_keyctl+0x146/0x4f0
   do_syscall_64+0xda/0x4b0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
   </TASK>

  Allocated by task 1:
   kasan_save_stack+0x30/0x50
   kasan_save_track+0x14/0x30
   __kasan_kmalloc+0x7f/0x90
   __kvmalloc_node_noprof+0x1c2/0x5b0
   __do_sys_add_key+0x1c2/0x390
   do_syscall_64+0xda/0x4b0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

  Freed by task 1:
   kasan_save_stack+0x30/0x50
   kasan_save_track+0x14/0x30
   kasan_save_free_info+0x3b/0x70
   __kasan_slab_free+0x47/0x70
   kfree+0x159/0x420
   __do_sys_add_key+0x2b3/0x390
   do_syscall_64+0xda/0x4b0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

  The buggy address belongs to the object at ffff88800108c000
   which belongs to the cache kmalloc-4k of size 4096
  The buggy address is located 4 bytes inside of
   freed 4096-byte region [ffff88800108c000, ffff88800108d000)

Fixes: f3eccecd782d ("pkcs7: Allow the signing algo to do whatever digestion it wants itself")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Hui Peng <benquike@gmail.com>
---
Changes in v2:
- Dropped the net/netlabel/netlabel_calipso.c change, keeping only the
  crypto/asymmetric_keys/x509_public_key.c fix.
- Added the KASAN slab-use-after-free report and test description to the
  commit message.

 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 25cf8ac7f257..5c9165a83f91 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

  reply	other threads:[~2026-09-20 23:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-19 22:34 [PATCH] netlabel: calipso, x509: clean up ADDRSELECT on DOI removal and check AKID len Hui Peng
2026-09-20  1:21 ` Paul Moore
2026-09-20 23:52   ` Hui Peng [this message]
2026-09-20 23:59     ` [PATCH v2] certs: x509: duplicate cert->tbs when sig->algo_takes_data is set sashiko-bot
2026-09-25 15:50     ` Ignat Korchagin
2026-09-20 22:34 ` [PATCH] netlabel: calipso, x509: clean up ADDRSELECT on DOI removal and check AKID len sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260920235249.260530-1-benquike@gmail.com \
    --to=benquike@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=ignat@linux.win \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=paul@paul-moore.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.