CVE-2026-64354

What it actually does

This is a local Linux kernel memory-corruption vulnerability in the BPF Type Format loading path. During BPF_BTF_LOAD, the kernel parses user-supplied BTF metadata and expands repeated fields into a fixed-size scratch array. The capacity check can be bypassed because the expanded field-count calculation is performed with 32-bit arithmetic and can wrap. A malformed BTF payload can therefore make the kernel believe the destination has enough space, after which memcpy() writes past the end of the fixed array. The likely outcomes are kernel crash, memory corruption, and potentially local privilege escalation to kernel-level execution depending on kernel configuration, exploit reliability, and available hardening features.

Why it matters to the business

An attacker who already has local code execution or a low-privileged account on an affected Linux system may be able to escalate privileges, disable security controls, access sensitive data, tamper with workloads, or crash the host. This is especially relevant for multi-user Linux servers, developer workstations, CI/CD runners, container hosts, and environments that allow unprivileged BPF use. The issue is not listed as CISA KEV and has a low EPSS score at this time, suggesting no known widespread exploitation, but the impact is high because successful exploitation affects the kernel security boundary.

How an attack unfolds

An attacker first obtains the ability to run code locally on an affected Linux system, such as through a shell, compromised service account, malicious package, or container with sufficient access to the bpf() syscall. The attacker then crafts malformed BTF metadata containing repeated field counts chosen to overflow the 32-bit arithmetic used during BTF field expansion. The payload is submitted to the kernel using the BPF_BTF_LOAD command. Because the wrapped count passes the remaining-capacity check, the kernel copies more expanded field data than the fixed BTF_FIELDS_MAX scratch array can hold. This corrupts adjacent kernel memory. A crude exploit may simply trigger a kernel oops or panic, while a more advanced exploit would attempt to shape memory layout and overwrite controlled kernel data to gain elevated privileges or escape isolation.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the fix for validating BTF repeated field counts before expansion. Because no exact fixed package versions were provided, use vendor advisories, package changelogs, or kernel commit references to confirm inclusion of the patch titled similar to "bpf: Validate BTF repeated field counts before expansion." Reboot into the updated kernel after installation; merely installing a kernel package is insufficient if the system continues running the vulnerable kernel. As interim mitigation, restrict BPF exposure where operationally feasible: set kernel.unprivileged_bpf_disabled=1 or 2, remove unnecessary CAP_BPF, CAP_SYS_ADMIN, CAP_PERFMON, and CAP_NET_ADMIN permissions from users and containers, use seccomp profiles to block or restrict the bpf() syscall, avoid privileged containers, and enable kernel lockdown and LSM protections where compatible. These mitigations reduce exploitability but do not replace patching, especially for users or workloads that legitimately retain BPF privileges.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated. Check uname -r, distribution package versions, and vendor changelogs for the BPF/BTF fix. Verify that systems have rebooted into the patched kernel after update. Review sysctl settings such as kernel.unprivileged_bpf_disabled and confirm whether unprivileged users can call bpf(BPF_BTF_LOAD). On hardened systems, validate seccomp, container runtime, and capability policies to ensure untrusted workloads cannot access BPF functionality unnecessarily. Where source or debug information is available, confirm the kernel contains checked addition and multiplication around BTF repeated field expansion before memcpy. Avoid validating with untrusted exploit code on production systems; use vendor-provided checks or controlled lab testing only.

Typical attack path

1. Gain local code execution or authenticated low-privileged access on an affected Linux system.
2. Confirm that the bpf() syscall and BPF_BTF_LOAD operation are reachable under the current privileges, capabilities, seccomp profile, and sysctl settings.
3. Prepare malformed BTF data with repeated field counts that trigger integer wraparound during expanded field-count calculation.
4. Invoke bpf(BPF_BTF_LOAD) with the crafted BTF payload.
5. Trigger out-of-bounds writes in the kernel BTF parsing path.
6. Use the resulting memory corruption to crash the host or attempt privilege escalation to kernel/root privileges.
7. If privilege escalation succeeds, disable defenses, access protected data, pivot to other systems, or persist using root-level mechanisms.

How to detect it

Detecting successful exploitation is difficult because kernel memory corruption may not produce a clean application-level indicator, and a successful privilege escalation may leave few direct traces. Focus on evidence of attempted BPF_BTF_LOAD abuse, unexpected bpf() syscall use, kernel instability, and post-exploitation behavior. Review auditd logs for bpf syscalls, especially command value 18 / 0x12 corresponding to BPF_BTF_LOAD, from users or services that do not normally use BPF tooling. Inspect kernel logs from journald, dmesg, kmsg, crash dumps, KASAN, and oops reports for BPF/BTF parser function names and out-of-bounds write messages. Correlate suspicious BPF activity with new root shells, unexpected privilege changes, modified security tooling, container escapes, newly loaded persistence mechanisms, or unexplained host reboots. On container hosts, review runtime and orchestrator logs for privileged containers, added Linux capabilities, or workloads invoking BPF unexpectedly. Absence of these indicators does not prove non-exploitation; retain memory captures or crash dumps for forensic review when suspicious kernel faults occur.

• BPF_BTF_LOAD
• syscall=bpf
• a0=0x12
• cmd=18
• btf_parse_struct_metas
• btf_repeat_fields
• btf_parse_fields
• BTF_FIELDS_MAX
• slab-out-of-bounds
• out-of-bounds write
• kernel BUG
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: unable to handle kernel paging request
• general protection fault
• kernel panic
• Oops:
• bpf:
• btf:

What your security team should do

• Prioritize patching internet-facing Linux infrastructure, multi-user systems, container hosts, CI/CD runners, and systems where untrusted users or workloads can execute code.
• Reboot systems after kernel updates and verify the running kernel version is the fixed one.
• Temporarily disable or restrict unprivileged BPF using kernel.unprivileged_bpf_disabled where business requirements allow.
• Audit container and workload policies for excessive Linux capabilities, especially CAP_BPF, CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN, and privileged container settings.
• Ensure seccomp profiles restrict the bpf() syscall for workloads that do not require it.
• Enable or tune auditd/eBPF monitoring to log bpf() syscall use, especially BPF_BTF_LOAD attempts by unexpected users, services, or containers.
• Investigate recent kernel crashes, oops reports, or KASAN findings referencing BTF, BPF_BTF_LOAD, btf_parse_struct_metas, btf_repeat_fields, or btf_parse_fields.
• Because there is no KEV listing and exploit maturity is currently reported as none, balance urgency with exposure: patch high-risk shared Linux systems first, then complete fleet-wide kernel updates through normal emergency or accelerated maintenance windows.