CVE-2026-31526

What it actually does

This is a Linux kernel eBPF verifier flaw in exception-exit resource checking for BPF subprograms. A crafted BPF program can call bpf_throw() from a static subprogram after acquiring certain resources such as RCU, preemption, or IRQ-related locks. On affected kernels, the verifier may fail to validate that those resources are released when the exception unwinds intermediate stack frames. At runtime, the exception path can bypass normal cleanup, leaving lock state inconsistent and potentially causing kernel instability, hangs, or denial of service. The issue requires local ability to load BPF programs and does not directly provide confidentiality or integrity impact.

Why it matters to the business

An attacker with local code execution and permission to load BPF programs could crash or destabilize Linux systems, causing service interruption, degraded availability, or host reboots. This is most relevant for multi-user Linux systems, container hosts, CI/build platforms, Kubernetes nodes, and environments where unprivileged or delegated BPF loading is allowed. The current EPSS is very low and stable, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity is indicated, so urgency is moderate unless BPF loading is broadly available to non-administrative users.

How an attack unfolds

An attacker first obtains local access to a Linux host, either as a low-privileged user or through a compromised workload. They then determine whether BPF program loading is permitted, for example through CAP_BPF, CAP_SYS_ADMIN, privileged container configuration, or unprivileged BPF being enabled. The attacker loads a specially crafted eBPF program containing a static subprogram that acquires a resource such as an RCU/preemption/IRQ-related lock and then triggers a bpf_throw() exception path. On vulnerable kernels, the verifier may not reject this program because resource-leak checking is incorrectly skipped for exception exits from subprograms. When the program executes, the BPF exception unwinds the call stack without running the cleanup that would normally release the acquired resource, potentially corrupting kernel execution state and causing a hang, panic, or host-level denial of service.

How to fix it

Apply a Linux kernel update that includes the upstream fix for BPF exception-exit lock checking in subprograms. Because no specific fixed downstream package versions were provided, use the fixed kernel versions published by the relevant Linux distribution or vendor and prioritize hosts that allow BPF program loading by non-root users, containers, observability agents, or developer workloads. As interim mitigation, restrict BPF loading to trusted administrators: disable unprivileged BPF where supported, remove unnecessary CAP_BPF/CAP_SYS_ADMIN from users and containers, avoid privileged containers, enforce seccomp/AppArmor/SELinux policies that block or constrain the bpf() syscall, and limit access to bpftool and custom BPF loaders. Reboot into the patched kernel after installation, since kernel updates do not take effect until the running kernel is replaced.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build, not just that an updated kernel package is installed. Validate with uname -r, distribution package metadata, and vendor advisories for this specific kernel fix. Check that unprivileged BPF is disabled where it is not operationally required, commonly through /proc/sys/kernel/unprivileged_bpf_disabled on distributions that expose it. Review container and service configurations for CAP_BPF, CAP_SYS_ADMIN, privileged=true, hostPID, and hostNetwork usage where BPF access may be possible. If feasible in a non-production test environment, verify that proof-of-concept-style BPF programs with bpf_throw() and unreleased RCU/preempt/IRQ resources are rejected by the verifier rather than accepted. Confirm after remediation that systems have been rebooted into the patched kernel.

Typical attack path

1. Gain local execution on a Linux system or inside a workload with sufficient privileges to invoke the bpf() syscall for program loading.
2. Check whether BPF program loading is allowed through capabilities, privileged container settings, or unprivileged BPF configuration.
3. Prepare an eBPF program using a static subprogram and an exception path via bpf_throw().
4. Acquire a relevant kernel-tracked resource in the BPF program and trigger the exception exit before the resource is released.
5. Rely on the vulnerable verifier behavior to accept the program instead of rejecting the leaked-resource path.
6. Execute or attach the BPF program so the exception path runs and leaves kernel lock/resource state inconsistent.
7. Cause kernel instability, soft lockups, panic, or denial of service affecting the host and dependent workloads.

How to detect it

To determine whether this was already exploited, review host telemetry for BPF program loading followed by kernel instability. Useful sources include auditd records for the bpf syscall, eBPF loader execution logs, EDR process telemetry, shell history for BPF tooling, kernel ring buffer logs, systemd-journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore artifacts, and container runtime or Kubernetes audit logs showing privileged containers or added CAP_BPF/CAP_SYS_ADMIN. Look for suspicious BPF_PROG_LOAD activity by unexpected users, containers, or processes, especially near soft lockups, RCU stalls, kernel panics, hung tasks, or sudden reboots. BPF verifier logs mentioning bpf_throw, unreleased RCU/preempt/IRQ locks, or resource-leak checks are especially relevant. Because exploitation may only cause a denial of service and not leave durable files, absence of file artifacts does not rule out exploitation; timeline correlation between BPF loads and kernel failure is the key investigative method.

• bpf_throw
• BPF_PROG_LOAD
• syscall=bpf
• comm="bpftool"
• /usr/sbin/bpftool
• /usr/bin/bpftool
• unprivileged_bpf_disabled
• CAP_BPF
• CAP_SYS_ADMIN
• privileged=true
• kernel: BUG: soft lockup
• kernel: INFO: rcu_sched detected stalls
• kernel: rcu: INFO: rcu_preempt detected stalls
• kernel: watchdog: BUG: soft lockup
• kernel: Kernel panic
• kernel: hung_task: blocked tasks

What your security team should do

• Patch and reboot Linux systems running affected kernels, prioritizing multi-tenant hosts, Kubernetes nodes, CI runners, bastion systems, and servers where local users or containers may load BPF programs.
• Temporarily disable unprivileged BPF and remove unnecessary CAP_BPF, CAP_SYS_ADMIN, and privileged-container permissions until patching is complete.
• Inventory BPF-capable workloads and tools, including observability agents, CNI components, security sensors, tracing tools, and developer utilities, to distinguish expected BPF activity from suspicious program loading.
• Monitor audit, kernel, and EDR telemetry for unusual bpf() syscall usage, failed BPF verifier loads, bpftool execution, and kernel instability events following BPF activity.
• Treat exploitation likelihood as currently low because EPSS is 0.001, no KEV listing exists, and exploit maturity is listed as none, but raise priority where untrusted local users or workloads can load BPF programs.
• Ensure incident response playbooks for Linux host crashes include collection of kernel logs, audit logs, recent BPF program load activity, container privilege metadata, and crash dumps where available.