CVE-2026-99221 in Linux
Summary
by MITRE • 11/02/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The Linux kernel's trusted keys subsystem relies on Trusted Platform Module hardware to securely store and manage cryptographic material, ensuring that sensitive data remains protected even if the system is compromised at the software level. A critical logic flaw was identified within the key instantiation process specifically involving the interaction between TPM unsealing operations and PCR lock mechanisms. When a user attempts to instantiate or access a trusted key, the kernel invokes the trusted_tpm_unseal function to retrieve the secret material encrypted by the TPM. This operation requires verifying that the system's Platform Configuration Registers match expected values before releasing the key data.
The vulnerability arises from an incorrect error handling sequence within this workflow. If the initial TPM unseal operation fails, indicating a mismatch in PCR values or other hardware-level security checks, the code incorrectly proceeds to call pcrlock(). The purpose of pcrlock() is typically to finalize and lock certain PCRs to prevent further modification, thereby preserving system state integrity for future measurements. However, under normal circumstances where unsealing succeeds, this sequence might be acceptable as part of a broader initialization routine. In the failure case, however, executing pcrlock() introduces a secondary return value that can overwrite or mask the original error code returned by the failed unseal operation.
This overwriting behavior leads to a severe security bypass where key instantiation is reported as successful despite the underlying cryptographic material never being properly retrieved or verified. An attacker who can manipulate system state or trigger conditions causing TPM unsealing failures might exploit this logic flaw to gain access to keys that should remain inaccessible due to integrity violations. This effectively undermines the core promise of trusted computing, allowing unauthorized access to encryption keys used for disk encryption, secure boot verification, or other critical security functions without triggering appropriate failure states in higher-level applications.
From a classification perspective, this issue aligns with CWE-253, which describes an incorrect check for an unusual condition that allows the system to enter an insecure state. More specifically, it reflects CWE-754, indicating an improper check for an unusual or exceptional condition where the error handling logic fails to preserve critical failure information. In terms of adversarial tactics, this vulnerability supports techniques associated with MITRE ATT&CK T1098, which involves manipulating account properties or authentication mechanisms to maintain persistence or escalate privileges by bypassing intended security controls through logical flaws rather than direct exploitation of buffer overflows or memory corruption issues.
The operational impact is significant because trusted keys are often used as root-of-trust components for system integrity and data protection. If an attacker can cause the unseal process to fail but have that failure masked, they may bypass checks designed to ensure the system has not been tampered with since the key was sealed. This could allow access to decrypted volumes or compromise secure boot chains if those keys are involved in validation processes. The flaw essentially creates a false positive state where security controls appear active and successful while actually being circumvented due to software logic errors rather than hardware failures.
To mitigate this vulnerability, developers must ensure that error codes from critical cryptographic operations like TPM unsealing are preserved and propagated correctly up the call stack without being overwritten by subsequent administrative or housekeeping functions such as pcrlock(). The fix involves returning immediately upon detecting a failure in the unseal operation, thereby preventing any further execution of code paths that might alter the return status. This ensures that applications relying on these keys receive accurate feedback about why access was denied, allowing them to handle authentication failures appropriately rather than proceeding with potentially compromised or missing cryptographic material.
System administrators and developers should apply kernel updates that include this patch as soon as possible to restore correct error propagation behavior in trusted key operations. Regular auditing of TPM-related logs can help detect instances where unsealing attempts fail but are not properly reported, which might indicate exploitation attempts against similar logic flaws in other subsystems. Maintaining strict control over PCR values and ensuring firmware integrity further reduces the risk surface associated with hardware-backed security features being undermined by software implementation errors.