From: Daehyeon Ko <4ncienth@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
Mimi Zohar <zohar@linux.ibm.com>
Cc: linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v2] KEYS: trusted: Reject short TPM2 public areas
Date: Wed, 21 Oct 2026 01:19:54 +0900 [thread overview]
Message-ID: <20261020161954.3956212-1-4ncienth@gmail.com> (raw)
In-Reply-To: <ateELTsfmHsdCEGL@kernel.org>
tpm2_load_cmd() reads TPMA_OBJECT with get_unaligned_be32(pub + 4), but
does not require public_len to cover that field.
A TPM 2.0 ASN.1 key blob with public_len zero makes the read begin at the
end of the B + 4-byte decoded allocation, causing a four-byte heap
out-of-bounds read before the TPM command is transmitted. This is reachable
from an unprivileged add_key() call when TPM trusted keys and a TPM2 device
are available.
This affects v5.13-rc1 and later kernels built with CONFIG_TRUSTED_KEYS=y
and CONFIG_TRUSTED_KEYS_TPM=y when a TPM2 device is present. A KASAN run
as UID 1000 with no effective capabilities reported:
BUG: KASAN: slab-out-of-bounds in tpm2_unseal_trusted
Read of size 4 at addr ffff888106273b48 by task exploit/160
CPU: 1 UID: 1000 PID: 160 Comm: exploit
The buggy address belongs to the object at ffff888106273b40
which belongs to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes to the right of
allocated 8-byte region [ffff888106273b40, ffff888106273b48)
TPMT_PUBLIC starts with the two-byte type, two-byte nameAlg and four-byte
objectAttributes fields. Require public_len to cover all eight bytes before
reading the attributes.
The exact input produced the KASAN read in 3/3 fresh boots. The fixed build
rejected it with -EINVAL and no KASAN report in 3/3 boots; valid TPM 2.0
ASN.1 and legacy trusted-key loads continued to succeed.
The issue was found with an LLM-assisted source audit and validated with an
end-to-end QEMU and swtpm reproducer.
Fixes: e5fb5d2c5a03 ("security: keys: trusted: Make sealed key properly interoperable")
Cc: stable@vger.kernel.org
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
---
Changes in v2:
- Describe the wrapper as the TPM 2.0 ASN.1 key format.
- Explain the eight-byte minimum next to the check.
- Return -EINVAL for a malformed TPMT_PUBLIC instead of -E2BIG.
- Replace the obsolete Assisted-by trailer with changelog disclosure.
v1: https://lore.kernel.org/r/20260925095308.3248297-1-4ncienth@gmail.com
security/keys/trusted-keys/trusted_tpm2.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
index 30188a0ec6766..fb45795b53327 100644
--- a/security/keys/trusted-keys/trusted_tpm2.c
+++ b/security/keys/trusted-keys/trusted_tpm2.c
@@ -425,6 +425,13 @@ static int tpm2_load_cmd(struct tpm_chip *chip,
if (private_len + 2 + public_len + 2 > blob_len)
return -E2BIG;
+ /*
+ * TPMT_PUBLIC starts with type (2), nameAlg (2), and
+ * objectAttributes (4), which is read below.
+ */
+ if (public_len < 8)
+ return -EINVAL;
+
pub = blob + 2 + private_len + 2;
/* key attributes are always at offset 4 */
attrs = get_unaligned_be32(pub + 4);
base-commit: 722658cac48a6ba49f5506fd74d010ad9dbb2f05
--
2.55.0
next prev parent reply other threads:[~2026-10-20 16:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 9:53 [PATCH] KEYS: trusted: Reject short TPM2 public areas Daehyeon Ko
2026-09-25 10:03 ` sashiko-bot
2026-09-25 22:57 ` Jarkko Sakkinen
2026-10-20 15:09 ` Jarkko Sakkinen
2026-10-20 16:19 ` Daehyeon Ko [this message]
2026-10-20 16:22 ` [PATCH v2] " sashiko-bot
2026-10-20 17:19 ` Jarkko Sakkinen
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=20261020161954.3956212-1-4ncienth@gmail.com \
--to=4ncienth@gmail.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=jarkko@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=zohar@linux.ibm.com \
/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.