Look up another CVE · open CVE-2026-89763 in the interactive tracker
CVE-2026-89763
KEYS: trusted: Fix TPM teardown ordering
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem security/keys. Debian urgency: not yet assigned.
Debian does not build this code. The per-release build detail is under "Where it lives" below.
What to do, per Debian release
Debian's own status for CVE-2026-89763 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
security/keys/trusted-keys/trusted_tpm1.c
- What this is
- KEYS-TRUSTEDMAINTAINERS section matched on security/keys/trusted-keys/ · linux-integrity@vger.kernel.org · Supported
- Kernel module
- none to look for. The file would have gone into trusted, and Debian does not compile it into that module, so finding trusted in lsmod would say nothing about this CVE.
Check it on the machine
grep -wE 'CONFIG_KEYS|CONFIG_TRUSTED_KEYS|CONFIG_TRUSTED_KEYS_TPM' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code. In 5 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12n
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_KEYS, CONFIG_TRUSTED_KEYS, CONFIG_TRUSTED_KEYS_TPM
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.12%, higher than 1.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- security/keys
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.1 | 6.12.111 | 3d67b4acbfc7 |
| 5.1 | 6.18.50 | 753c978f2400 |
| 5.1 | 7.2.4 | 2f7541afbc57 |
| 5.1 | 7.3 | 5e2d672280d9 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The UAF is reached only via the local add_key(2) syscall (trusted_instantiate → trusted_tpm_seal → pcrlock/tpm_* on global chip/digests) racing trusted_tpm_exit() during delete_module of trusted.ko; no network or adjacent protocol processes this key-type teardown.
- AC:LAttack complexity, low
- The attacker controls both sides of the race by issuing concurrent add_key("trusted") while trusted.ko is unloaded; key_type_lookup() still succeeds until unregister_key_type(), so the documented CPU0/CPU1 interleaving is reliably repeatable without uncontrollable victim memory layout.
- PR:LPrivileges required, low
- add_key(2) on a caller-owned keyring has no capable() check in trusted_instantiate(); every seal/unseal uses the global chip after put_device, and only optional pcrlock() needs CAP_SYS_ADMIN. Per CNA driver-removal UAF precedent, concurrent rmmod of trusted.ko does not require the attacker to hold CAP_SYS_MODULE.
- UI:NUser interaction, none
- Exploitation is driven by the attacker's own add_key threads and module-unload timing; no separate victim must mount a filesystem, open a device, or take any other action.
- S:UScope, unchanged
- The vulnerability is a standard in-kernel slab use-after-free affecting host kernel memory and availability; it does not cross a VM, IOMMU, or other distinct security-authority boundary.
- C:HConfidentiality impact, high
- KASAN shows a slab-use-after-free read of the freed digests array in tpm_pcr_extend, and put_device may free tpm_chip while callbacks still dereference it; per kernel CNA guidance a UAF enables object reuse and arbitrary kernel read, so Confidentiality is High.
- I:HIntegrity impact, high
- Seal/unseal after teardown calls tpm_try_get_ops() which mutates chip (get_device, mutex_lock) and PCR extend consumes the UAF'd digest buffer; use-after-free is heap-sprayable into write and control-flow primitives, so Integrity is High.
- A:HAvailability impact, high
- The KASAN report is a kernel slab-use-after-free oops during add_key versus delete_module; any such UAF can panic or hang the kernel, scoring Availability High even when not fully exploited for code execution.