GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel trusted keys: use-after-free when the trusted-key TPM backend is torn down

CVSS 7.8CVE-2026-89763Kernel, userspace & hypervisorcurated

Impact

trusted_tpm_exit() drops the TPM chip reference and frees the digest array before unregistering the trusted key type, so an in-flight add_key() sealing operation can call tpm_pcr_extend() against a freed digest array, and the chip can be released while callbacks still use it. KASAN confirms a slab-use-after-free reachable from __do_sys_add_key(). On a GPU node this matters only where trusted keys are in use (TPM-sealed secrets, measured boot key material) and someone can unload the trusted module - unloading is root-only, and the race window is module removal, so most fleets are not exposed. The write primitive from a freed slab is the sort of thing that turns a local account into kernel compromise where the exposure does exist.

Who can reach it

Local user who can call add_key() for a trusted key concurrently with root (or an automated package/driver update) unloading the trusted key module. Not remotely reachable.

What to do

Take the stable-kernel fix that moves unregister_key_type() ahead of releasing the TPM chip and digest array (three stable commits linked in the record). Rolling it out means installing the patched kernel and rebooting each node, so it lands in a normal drain-and-reboot cycle rather than an emergency window. No fixed version numbers are given in the record beyond the commit ids.

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.