GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel trusted_keys: a failed TPM unseal can still instantiate the key when pcrlock succeeds

UnscoredCVE-2026-99221Kernel, userspace & hypervisorcurated

Impact

trusted_tpm_unseal() continued on to pcrlock() after the TPM unseal operation failed, and a successful pcrlock() return overwrote the unseal error, so key instantiation reported success. The consequence an operator cares about is that a trusted key whose TPM-sealed material could not actually be unsealed - the case sealing is meant to detect, a changed PCR state or a TPM error - is accepted instead of refused. Anything that relies on trusted keys as a measured-boot gate, such as unlocking encrypted local NVMe on a GPU node, loses the guarantee that the key only materialises on an unmodified boot. The record is a one-paragraph fix changelog with no attack scenario, no score and no CWE, so treat the exposure as stated and no wider.

Who can reach it

Local, on a system using trusted keys backed by a TPM with pcrlock. No remote path and no attacker-controlled input is described in the record; the flaw is an error path that fails open.

What to do

Take the stable kernel fix (return immediately when unseal fails) and reboot the node after draining GPU work. If you depend on trusted keys for a measured-boot decision, re-verify on a patched kernel that keys you expect to fail do fail. The record lists stable commits only, with no distro fixed versions.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.