CVE-2026-63809

What it actually does

This is a Linux kernel memory-management flaw in the cgroup BPF sysctl write path. proc_sys_call_handler() allocates a temporary sysctl buffer with kvzalloc(), which may return either kmalloc-backed or vmalloc-backed memory depending on size and allocation behavior. The vulnerable path incorrectly releases a replaced buffer with kfree(); if the allocation came from vmalloc(), using kfree() can corrupt kernel memory or trigger a kernel page fault. Because the flaw occurs in kernel context, successful exploitation could potentially cause denial of service through a kernel crash and, depending on allocator state and exploitability, may enable local privilege escalation or arbitrary kernel memory corruption.

Why it matters to the business

Systems running affected Linux kernel builds may be vulnerable to local attacks that crash hosts or containers' underlying nodes and could potentially allow an attacker with existing local access to gain higher privileges. The issue is not listed in CISA KEV, has very low EPSS, and no public exploit maturity is indicated, so broad internet-scale exploitation is unlikely at this time; however, kernel memory-corruption bugs should still be treated as high priority on multi-user servers, container hosts, CI runners, and systems where untrusted users or workloads can execute local code.

How an attack unfolds

An attacker first needs local code execution with sufficient ability to reach the sysctl write path from a task associated with a cgroup where cgroup BPF sysctl filtering can replace the sysctl write buffer. The attacker then writes a large enough value to a writable /proc/sys entry to cause the temporary sysctl buffer allocation to be handled through the kvmalloc/kvzalloc path, where allocation may fall back to vmalloc. When the cgroup BPF sysctl filter replaces or processes that buffer, the vulnerable kernel path frees the buffer with kfree() instead of kvfree(). If the buffer is vmalloc-backed, this mismatched free can corrupt kernel memory or trigger an Oops in kfree(). A reliable exploit would attempt to shape allocator state and repeat the operation to convert the memory corruption into privilege escalation; simpler exploitation may only produce a local denial of service by crashing the kernel.

How to fix it

Upgrade to a Linux kernel version that includes the fix changing the replaced sysctl write buffer release from kfree() to kvfree() in the BPF sysctl handling path. If consuming kernels from a Linux distribution or appliance vendor, apply the vendor security update that includes the upstream fix rather than relying only on upstream version numbers. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, minimizing use of cgroup BPF sysctl programs where feasible, enforcing least privilege for users that can write sysctl values, and using container isolation controls to prevent untrusted containers from writing host /proc/sys entries. Operational mitigations reduce exploitability but do not correct the kernel memory corruption; patching remains the required fix.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or build contains the patch that uses kvfree() for the replaced sysctl write buffer in the cgroup BPF sysctl path. On source-based or custom kernels, inspect the relevant kernel source around proc_sys_call_handler() and __cgroup_bpf_run_filter_sysctl() to ensure vmalloc-capable allocations are released with kvfree(), not kfree(). On managed distributions, validate that the installed kernel version matches the vendor advisory's fixed build and that the system has been rebooted into the updated kernel. Exposure is higher on systems allowing local untrusted execution, cgroup BPF usage, or writes to /proc/sys entries from less-trusted workloads; confirm those controls are restricted if patching is delayed.

Typical attack path

1. Gain local execution on a Linux system running an affected kernel.
2. Run from, or move into, a cgroup configuration where the cgroup BPF sysctl hook can exercise the sysctl replacement path.
3. Write a large value to a writable /proc/sys/sysctl entry to drive proc_sys_call_handler() through the vulnerable allocation and replacement logic.
4. Trigger a vmalloc-backed temporary buffer allocation through kvzalloc()/kvmalloc fallback behavior.
5. Cause the vulnerable path to free the replaced buffer with kfree() instead of kvfree().
6. Leverage the resulting kernel memory corruption for a crash or attempt to shape memory for local privilege escalation.

How to detect it

To assess whether this was already triggered, review kernel logs and crash artifacts for Oops, page faults, KASAN reports, or allocator corruption involving kfree(), __cgroup_bpf_run_filter_sysctl(), and proc_sys_call_handler(). Useful sources include journald, /var/log/kern.log, /var/log/messages, dmesg output, kernel crash dumps, kdump/vmcore analysis, auditd records for sysctl writes, and eBPF/cgroup management logs if available. Look for unusual or repeated large writes to /proc/sys entries, especially from non-administrative processes, containers, test binaries, or workloads associated with cgroup BPF sysctl hooks. Kernel crashes alone are not proof of malicious exploitation, because the bug can be triggered during testing or fault-injection scenarios; correlate crash timing with local user activity, container starts, BPF program loading, sysctl writes, and privilege changes after the event.

• BUG: unable to handle page fault
• Oops: Oops: 0000
• RIP: 0010:kfree
• __cgroup_bpf_run_filter_sysctl
• proc_sys_call_handler
• vfs_write
• /proc/sys/kernel/domainname
• KASAN
• CONFIG_FAILSLAB
• repro_proc_sys_

What your security team should do

• Prioritize patching Linux kernel builds on multi-user systems, container hosts, Kubernetes nodes, CI/CD runners, bastion hosts, and any servers where untrusted or semi-trusted users can run code.
• Use distribution or vendor advisories to identify the exact fixed kernel package for each platform, then reboot systems to ensure the fixed kernel is active.
• Inventory systems using custom, mainline, release-candidate, or self-built kernels and confirm the kvfree() fix has been backported.
• Restrict local access and sysctl write capability while remediation is pending, especially from containers and untrusted workloads.
• Review whether cgroup BPF sysctl programs are deployed and limit their use to trusted administrative contexts.
• Monitor kernel logs for Oops, page fault, KASAN, or allocator corruption messages involving kfree(), proc_sys_call_handler(), or __cgroup_bpf_run_filter_sysctl().
• Because this is not KEV-listed, has very low EPSS, and has no known public exploit, treat emergency internet-edge response as lower priority than exposed remote-code-execution vulnerabilities, but do not defer patching on shared-host or local-code-execution environments.