CVE-2026-64507

What it actually does

This Linux kernel flaw weakens Spectre-v2 hardening when the BPF JIT compiler is enabled. Reuse of BPF JIT memory could occur without an Indirect Branch Prediction Barrier flush, allowing an attacker who can create/load BPF programs to use JIT spraying techniques to influence CPU branch prediction and potentially aid speculative-execution data leakage. The issue is most relevant on x86 systems using BPF JIT with Spectre-v2 mitigations enabled, especially where unprivileged or broadly delegated BPF program loading is allowed.

Why it matters to the business

The main risk is unauthorized disclosure of sensitive data from Linux systems, particularly shared, multi-user, container-hosting, or multi-tenant platforms where local code execution is possible. Current public exploitation signal is low: EPSS is 0.00157, there is no known CISA KEV listing, no ransomware association, and no reported mature exploit in the provided intelligence. Even with low likelihood, kernel speculative-execution weaknesses should be remediated during normal kernel patch cycles because exploitation can be difficult to detect after the fact.

How an attack unfolds

An attacker first obtains the ability to execute code on a vulnerable Linux system and gains permission to load BPF programs, either because unprivileged BPF is enabled or because the attacker has sufficient capabilities such as CAP_BPF or CAP_SYS_ADMIN. The attacker then repeatedly loads and unloads crafted BPF programs to influence the layout and reuse of JIT-compiled BPF memory. By combining this with Spectre-v2-style branch prediction manipulation, the attacker attempts to create a JIT spraying condition that improves speculative execution control. If successful, this may allow limited leakage of sensitive kernel or cross-context information through side channels. The vulnerability does not typically provide a simple remote code execution path by itself; it is a local, hardware-assisted side-channel risk that depends heavily on CPU behavior, kernel configuration, BPF policy, and available timing primitives.

How to fix it

Apply the vendor-provided Linux kernel update that includes the fix for enabling an IBPB flush on BPF JIT memory reuse. No exact fixed package versions were provided, so use the relevant distribution or kernel vendor advisory to identify the corrected kernel build and reboot into it. As interim mitigations, disable unprivileged BPF where possible, restrict BPF program loading to trusted administrators, consider disabling BPF JIT if operationally acceptable, enable BPF JIT hardening, and ensure Spectre-v2 mitigations are not disabled via kernel command-line options. Avoid boot parameters such as mitigations=off, nospectre_v2, or spectre_v2=off on affected systems.

How to confirm the fix worked

Confirm the running kernel version includes the vendor fix by checking the installed kernel package changelog/advisory and verifying the system has rebooted into the updated kernel with uname -r. Validate exposure by checking whether BPF JIT is compiled and enabled, whether unprivileged BPF is allowed, and whether Spectre-v2 mitigations remain active. Useful checks include reviewing /boot/config-$(uname -r) for CONFIG_BPF_JIT, reading /proc/sys/net/core/bpf_jit_enable and /proc/sys/net/core/bpf_jit_harden where present, checking /proc/sys/kernel/unprivileged_bpf_disabled, and reviewing /proc/cmdline for disabled CPU mitigations. Where source-level validation is required, confirm the kernel tree or vendor patch set contains the change described as enabling an IBPB flush on BPF JIT allocation/reuse.

Typical attack path

1. Gain local code execution on a Linux host, container host, or workload with access to the bpf syscall.
2. Determine whether BPF JIT is enabled and whether unprivileged or delegated BPF loading is allowed.
3. Load crafted BPF programs to create predictable JIT-compiled instruction sequences.
4. Trigger repeated BPF JIT allocation and memory reuse to support JIT spraying behavior.
5. Manipulate indirect branch prediction in a Spectre-v2-style attack path.
6. Use timing/cache side channels to attempt recovery of sensitive data from privileged or neighboring execution contexts.

How to detect it

There are no reliable, direct logs that prove exploitation of this speculative-execution issue, and successful side-channel attacks may leave little or no forensic evidence. Detection should focus on suspicious prerequisites and behaviors: unexpected use of the bpf syscall, creation of many short-lived BPF programs, untrusted processes loading BPF programs, containers or users with CAP_BPF/CAP_SYS_ADMIN unexpectedly granted, and systems running with BPF JIT enabled plus unprivileged BPF allowed. Review auditd logs for bpf syscall activity, eBPF telemetry from bpftool or security agents, kernel logs for BPF verifier/JIT messages, container runtime security events showing elevated capabilities, and shell/process history for tools that compile or load BPF programs. Also inspect kernel boot parameters and sysctls for disabled Spectre mitigations or permissive BPF settings. Because no named threat actors or public exploit campaign were provided, detections should be behavioral rather than signature-based.

What your security team should do

• Prioritize patching shared Linux infrastructure, container hosts, build systems, CI runners, and multi-user servers where local code execution by less-trusted users is possible.
• Upgrade to a vendor kernel containing the fix and reboot; kernel package installation alone is not sufficient if the old kernel remains running.
• Disable unprivileged BPF unless there is a documented operational requirement for it.
• Limit CAP_BPF, CAP_SYS_ADMIN, and other BPF-loading privileges to trusted services and administrators only.
• Enable BPF JIT hardening where supported, and consider disabling BPF JIT on systems that do not require high-performance BPF workloads.
• Verify Spectre-v2 mitigations are enabled and remove boot options that globally disable CPU speculation mitigations.
• Add monitoring for unexpected BPF program loads, high-volume bpf syscall activity, and new processes using BPF capabilities.
• Treat suspected exploitation as difficult to prove; focus on containment, credential/key rotation, and host rebuild for high-sensitivity systems if suspicious BPF activity is found.