CVE-2026-89763: KEYS: trusted: Fix TPM teardown ordering
In the Linux kernel, the following vulnerability has been resolved:
KEYS: trusted: Fix TPM teardown ordering
trustedtpmexit() drops the TPM chip reference and frees the digest array before unregistering the trusted key type. keytypelookup() holds keytypessem for reading until the key operation finishes, while unregisterkeytype() takes it for writing. It therefore provides the synchronization point that must precede backend teardown.
The current order permits this interleaving:
CPU 0 CPU 1 trustedtpmexit() keytypelookup("trusted") putdevice(&chip->dev) trustedtpmseal() kfree(digests) pcrlock() unregisterkeytype() tpmpcrextend(..., digests)
CPU 1 can consequently dereference the freed digest array. The chip can also be released before callbacks stop using it.
KASAN reported:
BUG: KASAN: slab-use-after-free in tpmpcrextend+0x1f0/0x200 Read of size 2 at addr ffff88810872d000 by task poc/89 Call Trace: tpmpcrextend+0x1f0/0x200 pcrlock+0x42/0x70 [trusted] trustedtpmseal+0x1b6/0x570 [trusted] trustedinstantiate+0x293/0x340 [trusted] keyinstantiateandlink+0xb2/0x2b0 keycreateorupdate+0x61e/0xb50 dosysaddkey+0x1b8/0x310 Allocated by task 88: kmallocnoprof+0x1a7/0x490 dooneinitcall+0xa1/0x390 doinitmodule+0x2df/0x840 Freed by task 90: kfree+0x131/0x3c0 trustedtpmexit+0x59/0xa0 [trusted] dosysdeletemodule+0x346/0x510
Move unregisterkeytype() before releasing either resource. This stops new lookups and waits for in-flight key operations to finish before the backend state is destroyed.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.111-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.111-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.111 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.50 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.4 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 6.8.0-1038.42 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.116-1Fixed in 7.2.15-1Fixed in 7.3.3-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.115-2~deb12u1 - Compensating control
In trusted_tpm_exit(), call unregister_key_type() before releasing either backend resource: before put_device(&chip->dev) and before kfree(digests), so new lookups stop and in-flight key operations finish before teardown.
Event History
Frequently Asked Questions
What conditions are required for this race to occur?
A trusted-key operation must still be running while trusted TPM teardown is in progress. The affected interleaving involves a trusted_tpm_seal() path using the digest array or TPM chip after teardown has released those resources.
How might this issue appear during testing or incident analysis?
KASAN can report a slab use-after-free in tpm_pcr_extend(), with a call chain through pcrlock(), trusted_tpm_seal(), and trusted_instantiate(). The report may identify a read from the freed digest array.