CVE-2026-31525

What it actually does

This is a local Linux kernel eBPF/BPF interpreter flaw caused by undefined signed 32-bit arithmetic behavior in signed division and modulo handling. When a BPF program causes a 32-bit destination value of INT_MIN / S32_MIN to be processed by the interpreter, the interpreter and verifier can disagree about the resulting value range. The verifier may believe subsequent memory access is safe while the interpreter computes a different runtime value, creating a verifier/interpreter mismatch that can enable out-of-bounds access to BPF map values. Successful exploitation can lead to kernel memory disclosure, kernel memory corruption, privilege escalation, or system crash. The issue requires local ability to load BPF programs, typically through unprivileged BPF where enabled or through privileges such as CAP_BPF, CAP_SYS_ADMIN, or equivalent delegated container/namespace permissions.

Why it matters to the business

An attacker who already has local code execution on a Linux system may be able to turn limited access into full control of the host, read sensitive kernel or application data, tamper with workloads, or crash the system. This is most concerning on multi-user servers, shared compute platforms, developer workstations, container hosts, and systems where unprivileged users or containers can load BPF programs. The vulnerability is not currently listed in CISA KEV, has low EPSS, no reported exploit maturity in the provided data, and a flat 30-day EPSS trend, so broad internet-scale exploitation is not indicated; however, local privilege-escalation kernel flaws should still be prioritized on exposed shared infrastructure because they can be chained after initial compromise.

How an attack unfolds

An attacker first obtains local execution as a low-privileged user or inside a context that can invoke the bpf() syscall. They then load a crafted BPF program that uses signed 32-bit division or modulo operations with a value that can become S32_MIN. During verification, the kernel verifier models the arithmetic result according to its abstract interpretation and concludes that later map-value access remains within bounds. At runtime, if the program is executed by the affected interpreter path, the undefined abs() handling produces a different result for S32_MIN, causing the actual pointer or offset calculation to diverge from what the verifier approved. The attacker can then attempt controlled out-of-bounds reads or writes against BPF map memory. With sufficient reliability and knowledge of kernel layout, those primitives may be developed into kernel memory disclosure, credential modification, arbitrary kernel memory corruption, privilege escalation to root, or denial of service through a kernel fault.

How to fix it

Apply a kernel update from the Linux distribution or vendor that includes the upstream fix for the BPF interpreter signed 32-bit division/modulo handling, specifically replacing unsafe abs((s32)...) behavior with safe S32_MIN handling. No exact fixed package versions were provided, so use vendor advisories for the affected distribution and kernel stream to identify the first non-vulnerable kernel release. Reboot into the updated kernel after installation; installing the package alone is not sufficient if the running kernel remains old. As compensating controls, disable unprivileged BPF where operationally feasible, restrict CAP_BPF and CAP_SYS_ADMIN to trusted services only, avoid granting broad capabilities to containers, enforce seccomp/AppArmor/SELinux policies that block or constrain bpf() use, and prefer hardened kernel configurations on shared systems. Where supported, set kernel.unprivileged_bpf_disabled to a restrictive value and persist it through sysctl configuration.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking the active kernel version with uname -r and matching it to the vendor's fixed advisory. Validate that the kernel changelog or vendor errata includes the BPF interpreter fix for signed 32-bit sdiv/smod handling of INT_MIN/S32_MIN. Confirm that the system has been rebooted after patching. Review BPF exposure by checking whether unprivileged BPF is disabled using sysctl kernel.unprivileged_bpf_disabled, and audit which users, services, or containers have CAP_BPF, CAP_SYS_ADMIN, or permission to invoke bpf(). On representative systems, use bpftool to enumerate loaded BPF programs and maps and confirm only expected programs are present. If source-based validation is possible, verify the kernel tree contains the safe abs_s32-style handling in the BPF interpreter sdiv32/smod32 paths rather than abs((s32)...) call sites.

Typical attack path

1. Gain local code execution on a Linux system as an unprivileged or constrained user.
2. Confirm that BPF program loading is permitted, either through unprivileged BPF or delegated capabilities such as CAP_BPF or CAP_SYS_ADMIN.
3. Load a crafted BPF program using signed 32-bit division or modulo operations involving S32_MIN / 0x80000000.
4. Pass verifier checks by relying on the verifier's mathematically correct range tracking.
5. Trigger execution through the affected BPF interpreter path so runtime arithmetic diverges from verifier assumptions.
6. Use the verifier/interpreter mismatch to perform out-of-bounds access to BPF map values.
7. Convert the out-of-bounds access into information disclosure, kernel memory corruption, privilege escalation, or a system crash.

How to detect it

Reliable detection of prior exploitation is difficult because successful BPF-based kernel exploitation may leave few application-level artifacts. Review audit logs for bpf() syscall use by unexpected users, shells, compilers, temporary binaries, scripting runtimes, containers, or services that do not normally load BPF programs. Inspect kernel logs, journald, dmesg, crash dumps, and panic records for BPF verifier messages, interpreter stack traces, general protection faults, KASAN out-of-bounds reports, or kernel oops events near suspicious local user activity. Use bpftool to enumerate currently loaded BPF programs and maps, compare them against the expected baseline for observability, networking, security, and service-mesh tooling, and investigate anonymous, short-lived, or unrecognized programs. If auditd or eBPF telemetry is available, correlate BPF_PROG_LOAD events with process lineage, user identity, container identity, file paths, and subsequent privilege changes. In containerized environments, review workload specifications and runtime logs for unexpected CAP_BPF or CAP_SYS_ADMIN grants. Absence of these indicators does not prove non-exploitation; a successful exploit may load and unload BPF objects quickly and only produce evidence in syscall audit, endpoint telemetry, or kernel crash artifacts.

• syscall=bpf
• SYSCALL=bpf
• BPF_PROG_LOAD
• BPF_MAP_CREATE
• comm="bpftool"
• comm="bpftrace"
• comm="python" syscall=bpf
• comm="perl" syscall=bpf
• comm="sh" syscall=bpf
• comm="bash" syscall=bpf
• kernel.unprivileged_bpf_disabled = 0
• ___bpf_prog_run
• bpf:
• verifier
• invalid access to map value
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: unable to handle kernel paging request
• general protection fault
• Oops:
• panic: Fatal exception

What your security team should do

• Prioritize patching shared Linux systems, container hosts, CI runners, developer workstations, bastion hosts, and any systems where untrusted users can run code.
• Immediately disable unprivileged BPF on systems that do not explicitly require it, and persist the setting across reboots.
• Audit use of CAP_BPF and CAP_SYS_ADMIN, especially in containers, systemd services, Kubernetes workloads, and developer tooling.
• Inventory running kernels and identify systems that remain on affected vendor kernel streams after package updates but before reboot.
• Monitor for unexpected bpf() syscall activity, newly loaded BPF programs, unusual BPF maps, and kernel crashes involving BPF interpreter execution.
• Treat successful exploitation as potential full host compromise: collect volatile evidence, preserve logs, and rotate credentials or secrets accessible from affected systems if compromise is suspected.
• Because no public exploit maturity or KEV listing is indicated in the provided data, balance urgency against exposure: patch exposed multi-user/shared hosts first, then complete fleet-wide remediation through normal kernel maintenance windows.