Live › vulnerability › CVE-2026-99221
When unsealing a trusted key from a TPM fails, the kernel's trusted_keys code keeps going and a later pcrlock check can overwrite the error, so key creation reports success. The sources do not describe what an attacker gains beyond a key being instantiated when it should have been rejected.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-02 16:24 UTC. All times on this page are UTC.
Only systems that use trusted keys sealed to a TPM are described as affected. The sources do not give the affected kernel version ranges or say how an attacker reaches the flawed path. Systems not using trusted keys are unlikely to be exposed.
No product ranges from the sources yet.
uname -r and compare it to the fixed releases in the NVD entry.grep -r trusted /proc/keys or cat /proc/keys for entries of type trusted.Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
keys/trusted_keys: return immediately after TPM unseal failure
trusted_tpm_unseal() proceeds to pcrlock() when the TPM unseal operation fails. If pcrlock() succeeds, its return value overwrites the unseal error, causing key instantiation to succeed.
Return immediately when unseal fails to preserve the original error.
This page as .md · .json · in your agent: get_signal("CVE-2026-99221")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.