GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux keys: unpinned request_key_auth payload lets KEYCTL_INSTANTIATE race into a use-after-free

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

Impact

The authorisation-key payload used by request_key() upcalls had no refcount. The commit message gives the exact race: while a KEYCTL_INSTANTIATE_IOV caller sleeps on a page fault copying the user payload, the request_key helper can complete, detach and free the rka, and the instantiating thread then dereferences rka->target_key after it is freed. Any local user can drive both sides of this - the keyring upcall path is ordinary unprivileged functionality used by filesystem and network credential helpers. On a shared GPU node this is a use-after-free in core kernel code reachable without any device access at all, so node isolation around /dev/kfd or /dev/nvidia* does not help. Scored 7.8 local by NVD.

Who can reach it

Local unprivileged user, including any container that is not blocked from keyctl() - no device access, no network path, and the race is driven with user-controlled page faults.

What to do

Update to a stable kernel that refcounts the request_key_auth payload and holds a reference across the instantiate and reject paths. There is no configuration mitigation short of blocking keyctl() with seccomp, which breaks credential helpers that use it. Drain and reboot each node to pick up the kernel.

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.