CVE-2026-63824

What it actually does

This is a local Linux kernel buffer overflow in the KEYS subsystem, specifically in handling public-key cryptographic keyctl operations. The vulnerable code calculates an internal output-buffer length from a caller-provided size rather than the maximum output length of the cryptographic primitive. A local authenticated user can provide a too-small buffer and trigger memory corruption in kernel context. Because the flaw occurs in kernel memory, successful exploitation can plausibly lead to local privilege escalation, kernel memory disclosure, data corruption, or system crash.

Why it matters to the business

An attacker who already has local code execution or a low-privileged account on a vulnerable Linux system could potentially gain full control of the host or crash it. This is most concerning for multi-user Linux servers, shared compute platforms, CI/CD runners, container hosts, bastion systems, and environments where untrusted users or workloads can execute local processes. The EPSS score is currently low and there is no known KEV listing or public exploit maturity reported, but the high CVSS impact means affected systems should still be patched through normal kernel update processes, with higher priority for shared or internet-exposed access platforms.

How an attack unfolds

An attacker first obtains the ability to run local code as an unprivileged user on a vulnerable Linux system. They then invoke the keyctl syscall using public-key cryptographic operations that reach the vulnerable KEYS code path. By supplying parameters that cause the kernel to allocate an internal output buffer based on an attacker-controlled, too-small length, the attacker can cause the cryptographic output to exceed the allocated buffer. This can corrupt adjacent kernel memory. Depending on kernel version, memory layout, mitigations, and exploit reliability, the result may be a kernel crash, information disclosure, or controlled corruption that enables privilege escalation to root. Exploitation is local, requires no user interaction, and does not require administrative privileges, but it does require the attacker to execute code on the target host.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the fix for `KEYS: fix overflow in keyctl_pkey_params_get_2()`. Because no affected product list or exact fixed kernel versions were provided, remediation should be validated against vendor advisories for the specific distribution, kernel branch, appliance, or managed image in use. After installing the patched kernel package, reboot systems to ensure the fixed kernel is running; merely installing the package is not sufficient if the host continues booted into the vulnerable kernel. Where immediate patching is not possible, reduce risk by limiting local shell access, restricting execution by untrusted users and workloads, applying least privilege to service accounts, using seccomp or workload sandboxing to block or restrict the `keyctl` syscall where operationally safe, and prioritizing isolation of shared compute and container-host systems. Test any syscall filtering carefully because legitimate software may use the Linux keyring facility for credential storage, encryption, authentication, or package-management workflows.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, contains the vendor fix. Check the active kernel with `uname -r`, compare it to the fixed version listed by the Linux distribution or appliance vendor, and review package changelogs or advisory metadata for the patch text `KEYS: fix overflow in keyctl_pkey_params_get_2()`. Vulnerability scanners should be configured to evaluate the running kernel version and distribution backports, not just upstream version numbers. On systems using live patching, confirm the live patch is loaded and explicitly covers this KEYS subsystem fix. If syscall filtering was used as a mitigation, validate with audit, seccomp, or eBPF tracing that untrusted workloads cannot invoke the relevant `keyctl` public-key operations. A reboot into the patched kernel should be confirmed after kernel package deployment.

Typical attack path

1. Gain local code execution on a vulnerable Linux host as a low-privileged user, service account, compromised application user, or untrusted workload.
2. Prepare or obtain a proof-of-concept program that invokes the keyctl syscall and exercises KEYS public-key cryptographic operations.
3. Create or reference suitable asymmetric key material exposed through the Linux KEYS subsystem.
4. Call the vulnerable keyctl operation with crafted parameters, including an output-buffer size that is smaller than the cryptographic primitive can produce.
5. Trigger the incorrect internal buffer allocation and cause a kernel buffer overflow.
6. Use the resulting kernel memory corruption to crash the system, disclose kernel memory, or attempt privilege escalation.
7. If privilege escalation succeeds, establish persistence, access sensitive data, or move laterally from the compromised host.

How to detect it

There are no widely reported public exploitation indicators or named threat actors for this issue based on the provided data. Detection should focus on signs of attempted local exploitation and post-exploitation rather than a single reliable signature. Useful log sources include kernel logs from `dmesg`, `journald`, `/var/log/kern.log`, `/var/log/messages`, and `/var/log/syslog`; Linux audit logs if syscall auditing is enabled; endpoint telemetry showing process execution and privilege changes; and eBPF/syscall tracing where available. Look for kernel oops, panic, general protection fault, slab corruption, KASAN, or BUG messages referencing the KEYS subsystem, `keyctl`, or `keyctl_pkey_params_get_2`. In audit or EDR telemetry, investigate unusual or high-volume `keyctl` syscall activity by unexpected processes, especially followed by crashes, credential changes, new root-owned processes, modified setuid files, suspicious kernel-module loading, or new persistence artifacts. Because exploitation may leave only a crash or memory-corruption artifact, absence of logs does not prove absence of exploitation, especially if the system rebooted or logs were not persisted.

• keyctl_pkey_params_get_2
• KEYS: fix overflow in keyctl_pkey_params_get_2()
• keyctl_pkey
• KEYCTL_PKEY_ENCRYPT
• KEYCTL_PKEY_DECRYPT
• KEYCTL_PKEY_SIGN
• KEYCTL_PKEY_VERIFY
• syscall=keyctl
• SYSCALL=keyctl
• comm="keyctl"
• /usr/bin/keyctl
• /bin/keyctl
• BUG: kernel
• Oops:
• general protection fault
• kernel panic
• slab-out-of-bounds
• KASAN
• use-after-free
• corrupted list
• Kernel panic - not syncing

What your security team should do

• Inventory Linux systems where untrusted users, tenants, CI jobs, containers, or third-party workloads can execute local code, and prioritize those systems for kernel updates.
• Patch affected Linux kernels through the appropriate distribution or appliance vendor channel, then reboot to activate the fixed kernel.
• For high-risk shared platforms, consider temporary seccomp or sandbox policies that deny the `keyctl` syscall to untrusted workloads where compatible with application requirements.
• Monitor vendor advisories for exact fixed versions and backported package names because Linux distributions often fix kernel CVEs without changing to the upstream version where the fix first appeared.
• Hunt for kernel crashes, oops events, or anomalous keyctl activity on systems that were exposed before patching.
• Treat any unexplained local root privilege escalation or kernel crash near KEYS/keyctl activity as potentially suspicious and preserve volatile forensic evidence where possible.
• Maintain compensating controls such as least-privilege local accounts, container isolation, disabled unnecessary interactive access, and strict separation between untrusted workloads and sensitive hosts.