CVE-2026-64036

What it actually does

This is a Linux kernel improper input validation flaw in the cgroup rstat BPF-facing kfunc css_rstat_updated(). A caller-controlled CPU identifier is used for per-CPU rstat array access without first confirming that the CPU is valid or possible on the system. A local user or process with sufficient BPF-related privileges, specifically capabilities such as CAP_BPF and CAP_PERFMON, can run a BPF iter/cgroup program that passes an invalid CPU value and triggers an out-of-bounds kernel memory access. Depending on kernel build, memory layout, hardening, and exploitability, the impact can range from kernel warning/crash to potential privilege escalation or compromise of kernel memory confidentiality/integrity.

Why it matters to the business

Systems running affected Linux kernels may be exposed to local kernel compromise by users, containers, services, or workloads that have been granted advanced BPF/performance-monitoring capabilities. The main operational risks are host instability, denial of service from kernel crashes, and possible full host takeover if the memory corruption is weaponized. Although this is not remotely exploitable by itself and is not currently listed in CISA KEV, kernel privilege-escalation vulnerabilities are high-impact in multi-user, container, CI/CD, research, and observability-heavy environments where BPF capabilities may be delegated.

How an attack unfolds

An attacker first needs local execution on a Linux system and access to BPF functionality with the necessary capabilities, such as CAP_BPF and CAP_PERFMON. They then load or trigger a BPF iter/cgroup program that calls the exposed css_rstat_updated() kfunc. Instead of supplying a legitimate CPU number, the program passes an invalid, very large, or otherwise impossible CPU value. On vulnerable kernels, the function uses that value for per-CPU rstat lookup without validation, resulting in an out-of-bounds access in kernel/cgroup/rstat.c. A simple exploit may crash the kernel and cause denial of service; a more advanced exploit would attempt to shape kernel memory and convert the out-of-bounds access into a privilege escalation or kernel memory disclosure. Current public exploit maturity is reported as none, and EPSS is low, but exposure should still be treated seriously because the affected component is in kernel space.

How to fix it

Apply a kernel update from the relevant Linux distribution or kernel vendor that includes the fix validating the CPU argument before css_rstat_updated() accesses per-CPU rstat data. Because no product-specific fixed versions were provided, track the vendor advisory for each deployed kernel stream and confirm that the patch for cgroup/rstat CPU validation is included. As interim mitigation, minimize access to BPF and performance-monitoring capabilities: avoid granting CAP_BPF, CAP_PERFMON, CAP_SYS_ADMIN, or broad privileged-container permissions to untrusted users or workloads; disable unprivileged BPF where supported; restrict loading of BPF programs through LSM, seccomp, container runtime policy, and least-privilege service configuration; and limit shell/local access to systems where kernel updates are pending. Reboot into the patched kernel after installation, as kernel package installation alone is not sufficient if the old kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a vendor build that contains the cgroup/rstat css_rstat_updated() CPU validation patch. Validate with uname -a, distribution package tooling, and vendor security advisory metadata. Review whether untrusted users, services, or containers retain CAP_BPF, CAP_PERFMON, CAP_SYS_ADMIN, privileged mode, or access to BPF filesystem and perf_event interfaces. If practical in a controlled test environment only, use vendor regression tests or kernel selftests that exercise BPF cgroup iterator paths and confirm invalid CPU values are rejected without UBSAN, WARN, oops, or panic output. Check boot status after patching to ensure the patched kernel is active and old vulnerable kernels are not the default boot option.

Typical attack path

1. Obtain local code execution on a Linux host, container host, or workload environment.
2. Acquire or abuse BPF-related privileges such as CAP_BPF and CAP_PERFMON, or run within a context where those capabilities were intentionally granted.
3. Load a BPF iter/cgroup program capable of invoking the css_rstat_updated() kfunc.
4. Pass an invalid CPU value, such as an extremely large integer, to the kfunc.
5. Trigger the vulnerable per-CPU rstat lookup path and cause an out-of-bounds kernel access.
6. Use the resulting condition to crash the host, read or corrupt kernel memory, or attempt privilege escalation depending on exploit reliability and kernel hardening.

How to detect it

Look for signs that a local process attempted to exercise the vulnerable BPF cgroup iterator path. Primary evidence sources are kernel logs from dmesg, journald, syslog, kmsg, crash dumps, kdump/vmcore, auditd records, eBPF loader telemetry, container runtime events, and endpoint telemetry showing BPF program loading. Search for UBSAN array-index-out-of-bounds messages in kernel/cgroup/rstat.c and call traces containing css_rstat_updated, bpf_iter_run_prog, cgroup_iter_seq_show, or bpf_seq_read. Review audit logs for unexpected use of bpf() syscalls, perf_event_open(), or processes running with CAP_BPF, CAP_PERFMON, CAP_SYS_ADMIN, or privileged container settings shortly before a kernel warning, oops, panic, reboot, or service interruption. On container hosts, correlate suspicious BPF activity with pod/container creation, privileged containers, mounted /sys/fs/bpf, host namespaces, or observability/debug containers. Absence of these logs does not fully rule out exploitation, especially if kernel logs rotated or the host crashed before persistence, so preserve crash artifacts and compare timelines around unexpected reboots.

• UBSAN: array-index-out-of-bounds in kernel/cgroup/rstat.c
• index 2147483647 is out of range for type 'long unsigned int [64]'
• css_rstat_updated
• bpf_iter_run_prog
• cgroup_iter_seq_show
• bpf_seq_read
• kernel/cgroup/rstat.c:31
• Call Trace: css_rstat_updated
• BUG: unable to handle kernel
• kernel panic
• Oops:
• /sys/fs/bpf
• bpf(BPF_PROG_LOAD
• perf_event_open

What your security team should do

• Prioritize patching Linux hosts that allow local users, container workloads, CI runners, observability agents, or research workloads to use BPF or performance-monitoring capabilities.
• Inventory systems and containers with CAP_BPF, CAP_PERFMON, CAP_SYS_ADMIN, privileged=true, hostPID, host mounts, or access to /sys/fs/bpf and perf_event interfaces.
• Disable or restrict unprivileged BPF and remove unnecessary BPF/perf capabilities from services and containers until all affected kernels are patched.
• Monitor kernel logs for UBSAN, out-of-bounds, oops, panic, or BPF iterator call traces involving css_rstat_updated, cgroup/rstat, bpf_iter_run_prog, cgroup_iter_seq_show, or bpf_seq_read.
• Treat unexpected kernel crashes on systems with BPF-capable workloads as potentially security-relevant and preserve kdump, journal, audit, and container runtime evidence.
• Ensure patched kernels are actually booted and remove or de-prioritize vulnerable kernels from bootloader configuration after maintenance windows.
• Because exploitation currently requires local privileged BPF access and no public exploit maturity is reported, use risk-based scheduling, but do not defer patching on shared, multi-tenant, or container-host systems.