GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel keys: read method checked outside key->sem, so KEYCTL_READ can touch a freed key type module

UnscoredCVE-2026-99222Kernel, userspace & hypervisorcurated

Impact

keyctl_read_key() read key->type->read without holding key->sem. Holding a reference keeps the key alive but does not pin the module that owns its type, so a surviving key - the worked example is an RxRPC key - can be read while its module is unloaded: the key GC retypes the key, unregister_key_type() returns, free_module() runs, and the reader then uses the saved type's read member out of freed module storage. The read invocation itself was already under key->sem; only the earlier method check was not. The practical exposure on a server is a use-after-free in kernel memory reached from an unprivileged keyctl call, which means at minimum a node crash. It needs the type's module to actually be unloading, which on a headless GPU node with a static module set is rare - this is primarily a bug for hosts where key-type modules come and go.

Who can reach it

Local, unprivileged: a user calling KEYCTL_READ on a key whose type module is being unregistered at that moment. No remote path.

What to do

Take the stable kernel fix (the method check moves into __keyctl_read_key() under the existing read hold on key->sem) and reboot the node after draining GPU work. Until then, not unloading key-type modules such as af_rxrpc on running nodes removes the window. The record has stable commits only; no distro fixed versions are stated.

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.