CVE-2026-63823

What it actually does

This is a local Linux kernel use-after-free in the key management subsystem. A race between request_key() authorization-key handling and KEYCTL_INSTANTIATE_IOV / instantiate or reject paths can allow a low-privileged local user to cause the kernel to use a freed request_key_auth payload. Because the stale payload includes references such as the target key, successful exploitation may allow kernel memory corruption, privilege escalation to root, disclosure or modification of kernel memory, and system crash. Network-based exploitation is not expected; the attacker needs local code execution or the ability to invoke the relevant keyctl/request_key interfaces on the host.

Why it matters to the business

A user or compromised low-privileged process on an affected Linux system could potentially gain full administrative control of the host, tamper with workloads, steal secrets available on the machine, disable security tooling, or cause outages through kernel crashes. The vulnerability is not currently listed in CISA KEV, has low EPSS, and no mature public exploit is indicated, which lowers immediate mass-exploitation likelihood; however, local privilege-escalation flaws in the Linux kernel are frequently incorporated into post-compromise toolchains once exploit code becomes available.

How an attack unfolds

An attacker first obtains local execution as an unprivileged user, service account, container process with sufficient syscall access, or other low-privileged context. They then manipulate Linux keyrings by triggering request_key() so the kernel creates an authorization key containing a request_key_auth payload, while a second racing thread invokes KEYCTL_INSTANTIATE_IOV or a related instantiate/reject operation. By arranging for the operation to block while copying user-controlled payload data, for example on a page fault, the helper path can complete and free the request_key_auth payload while the instantiate path still holds a stale pointer. When execution resumes, the kernel dereferences the freed payload. A reliable exploit would attempt to reclaim or shape the freed memory so that the stale target_key reference or adjacent data is attacker-controlled, turning the use-after-free into privilege escalation or kernel code execution. Less reliable attempts may produce kernel oops, slab corruption, or denial of service.

How to fix it

Update the Linux kernel to a vendor-supported build that includes the upstream fix for the keyrings change described as "keys: Pin request_key_auth payload in instantiate paths." Because fixed package versions were not provided, use distribution security advisories for exact kernel package names and versions, then reboot into the patched kernel; installing the package without rebooting usually leaves the vulnerable kernel running. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, applying seccomp/AppArmor/SELinux profiles that block or constrain keyctl where practical, avoiding privileged or weakly isolated containers for untrusted code, and monitoring for kernel crashes or suspicious keyring activity. These mitigations reduce exploitability but should not be treated as a substitute for a patched kernel.

How to confirm the fix worked

Confirm remediation by verifying the running kernel, not just installed packages. Check the active kernel version with uname -r and compare it against the fixed version in the relevant Linux distribution advisory. Confirm the patch is present in source-based or custom kernels by checking for the request_key_auth payload reference-counting fix in the key management subsystem. After reboot, verify that package inventory and vulnerability scanners no longer report this issue for the running kernel. For high-assurance systems, review kernel logs after patching to ensure there are no continuing keyrings-related warnings, slab corruption messages, KASAN reports, or oops events associated with request_key_auth, keyctl, or key instantiation paths.

Typical attack path

1. Gain local execution on an affected Linux system as a low-privileged user or process.
2. Confirm that keyctl/request_key functionality is available and not blocked by policy, sandboxing, or seccomp.
3. Create a race condition involving request_key() authorization-key creation and KEYCTL_INSTANTIATE_IOV or related key instantiation/rejection operations.
4. Force the instantiate path to sleep while copying user payload data so the helper path can detach and free the request_key_auth payload.
5. Resume execution after the payload has been freed, causing the kernel to dereference stale request_key_auth data.
6. Use heap shaping or memory reclamation to convert the use-after-free into privilege escalation, kernel memory access, or system crash.
7. Establish persistence, tamper with logs, or move laterally if root-level control is obtained.

How to detect it

Retrospective detection is difficult because successful kernel privilege-escalation exploits may not leave application-level traces. Focus on kernel, audit, EDR, and host forensic telemetry. Review auditd logs for unusual keyctl syscall activity, especially KEYCTL_INSTANTIATE_IOV, KEYCTL_INSTANTIATE, KEYCTL_REJECT, request_key usage, or high-volume keyring operations from unexpected users, containers, build jobs, web service accounts, or temporary directories. Inspect dmesg, journald, /var/log/kern.log, /var/log/messages, and crash dumps for KASAN, general protection fault, kernel oops, slab corruption, or use-after-free messages involving request_key_auth, keyrings, keyctl, construct_alloc_key, complete_request_key, key_instantiate_and_link, or key_reject_and_link. Correlate any such events with process execution logs around the same time for compilers, exploit-like binaries, files executed from /tmp, /var/tmp, /dev/shm, or container overlay paths. Also hunt for post-exploitation artifacts: unexpected UID 0 shells, new setuid-root files, suspicious kernel modules, changes to sudoers or PAM configuration, stopped security agents, new persistence services, or unexplained credential access. Absence of these indicators does not prove non-exploitation, especially if kernel logs are rotated or tampered with.

• request_key_auth
• KEYCTL_INSTANTIATE_IOV
• KEYCTL_INSTANTIATE
• KEYCTL_REJECT
• keyctl instantiate_iov
• keyctl instantiate
• keyctl reject
• keyctl(KEYCTL_INSTANTIATE_IOV
• keyctl(KEYCTL_INSTANTIATE
• keyctl(KEYCTL_REJECT
• request_key(
• use-after-free in request_key_auth
• KASAN: use-after-free
• BUG: KASAN: use-after-free
• general protection fault
• kernel BUG at security/keys
• kernel BUG at crypto/asymmetric_keys
• key_instantiate_and_link
• key_reject_and_link
• complete_request_key
• construct_alloc_key
• construct_get_dest_keyring
• call_usermodehelper_exec
• /proc/keys
• /proc/key-users
• /tmp/keyctl
• /var/tmp/keyctl
• /dev/shm/keyctl

What your security team should do

• Prioritize patching internet-facing, multi-user, developer, CI/CD, container-host, VDI, bastion, and shared Linux systems where untrusted or semi-trusted users can run code.
• Reboot systems after installing the fixed kernel and verify the active kernel version; do not rely solely on package installation status.
• Temporarily restrict local access and untrusted workload execution on systems that cannot be patched quickly.
• Apply seccomp, AppArmor, SELinux, or container runtime profiles to limit keyctl/request_key access for workloads that do not require Linux keyring functionality.
• Search for signs of attempted exploitation, including abnormal keyctl activity, kernel oopses, KASAN use-after-free reports, slab corruption, and unexplained privilege escalation before declaring systems clean.
• Increase monitoring of local privilege-escalation behavior such as unexpected setuid binaries, new root-owned files in writable paths, suspicious kernel module loading, and security tooling being stopped.
• Track vendor advisories for exact fixed kernel versions because no fixed-version list was supplied with the vulnerability record.
• Reassess urgency if public exploit code, KEV listing, ransomware use, or named threat-actor exploitation is later reported.