In the Linux kernel

CVE-2026-31413 is a Linux kernel eBPF verifier soundness bug in maybe_fork_scalars() for BPF_OR. A crafted BPF program can make the verifier believe a scalar is safely bounded when runtime behavior differs, creating verifier/runtime divergence that can lead to out-of-bounds map access. Upstream affected ranges published by NVD are 6.12.75 to <6.12.80, 6.18.16 to <6.18.21, and 6.19.6 to <6.19.11; the mainline fix landed as commit c845894ebd6f... in 7.0-rc5.

The vendor's 7.8/HIGH score is technically understandable because successful exploitation can end in full local privilege escalation. In the real world, though, this is usually *post-initial-access* and often *post-policy-bypass*: the attacker needs a local foothold and a path to load a crafted BPF program, while many enterprise kernels gate unprivileged bpf() behind unprivileged_bpf_disabled or require CAP_BPF/CAP_SYS_ADMIN. Add the narrow affected version windows and the fact that major maintained Ubuntu and Debian releases are marked not affected, and this drops out of urgent fleet-wide patch-now territory.

Why this verdict

• Local-only attack surface: start from vendor 7.8/HIGH, then cut down because AV:L means this is already post-initial-access.
• BPF gate is the real choke point: practical exploitation usually requires unprivileged bpf() to be enabled or the attacker to already hold CAP_BPF/CAP_SYS_ADMIN; that is a strong downward adjustment in hardened fleets.
• Narrow affected population: NVD's affected windows are recent and specific, and maintained Ubuntu plus maintained Debian branches shown by their trackers are marked not affected, which materially shrinks blast radius.

Why not higher?

There is no KEV listing, no public exploitation evidence found, and no straightforward remote entry point. The exploit chain compounds on two prerequisites that slash the reachable population: prior local foothold and BPF program-loading reachability.

Why not lower?

If an attacker can submit crafted BPF bytecode on a vulnerable host, the impact is kernel-level and severe. On developer workstations, observability-heavy servers, or permissive container nodes where BPF access exists, this can still become a clean host-level privilege escalation.

1. Disable unprivileged BPF — Set /proc/sys/kernel/unprivileged_bpf_disabled=1 or your distro's persistent equivalent where operationally safe. This directly attacks the main exploit precondition and, for a MEDIUM noisgate verdict, there is no mitigation SLA — go straight to the remediation window unless your environment intentionally exposes BPF to low-privilege users.
2. Constrain container capabilities — Strip CAP_BPF, CAP_SYS_ADMIN, and adjacent high-risk capabilities from containers and node agents that do not absolutely need them. This matters most on Kubernetes and shared Linux nodes, and should be folded into your next normal hardening change before the 365-day remediation window closes.
3. Audit seccomp and syscall policy — Confirm that container runtimes and sandbox profiles do not unnecessarily permit dangerous syscall reach for untrusted workloads. This does not replace patching, but it reduces the chance that a compromised container can exercise the verifier path before you remediate.
4. Hunt for BPF loader usage — Collect telemetry on unexpected bpf() activity, bpftool usage, and reads/writes to /proc/sys/kernel/unprivileged_bpf_disabled. Use that as a targeted threat hunt on engineering hosts and Kubernetes nodes during the remediation window.

Run this on the target Linux host as root or with enough privilege to read /proc/sys/kernel/unprivileged_bpf_disabled; example: sudo bash ./check-cve-2026-31413.sh. It checks the running kernel release against the upstream vulnerable ranges and reports whether unprivileged BPF is enabled, but it intentionally returns UNKNOWN for vendor-backported kernels it cannot confidently map.

#!/usr/bin/env bash
# check-cve-2026-31413.sh
# Determine likely exposure to CVE-2026-31413 on the running Linux host.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

rel="$(uname -r 2>/dev/null)"
base="${rel%%-*}"
status="UNKNOWN"
reason="Unable to map running kernel to upstream affected ranges"

ver_ge() {
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
}

ver_lt() {
  [ "$1" != "$2" ] && [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

in_range() {
  local v="$1" lo="$2" hi="$3"
  ver_ge "$v" "$lo" && ver_lt "$v" "$hi"
}

# Upstream NVD ranges.
if in_range "$base" "6.12.75" "6.12.80" || in_range "$base" "6.18.16" "6.18.21" || in_range "$base" "6.19.6" "6.19.11"; then
  status="VULNERABLE"
  reason="Running kernel version falls inside upstream affected ranges"
else
  # Ubuntu maintained releases are marked not affected in the vendor advisory.
  if [ -r /etc/os-release ]; then
    . /etc/os-release
    case "${ID:-}" in
      ubuntu)
        status="PATCHED"
        reason="Ubuntu advisory marks maintained releases shown there as Not affected"
        ;;
      debian)
        # Debian tracker marks maintained bullseye/bookworm/trixie branches not affected,
        # but package naming/backports can be ambiguous from uname alone.
        if [ "$status" = "UNKNOWN" ]; then
          reason="Debian requires package-level validation; tracker marks maintained branches not affected"
        fi
        ;;
    esac
  fi

  # If upstream version is equal to or newer than the published fixes and not distro-modified,
  # we can call it patched with high confidence.
  if [ "$status" = "UNKNOWN" ] && [[ "$rel" != *-* ]]; then
    if ver_ge "$base" "6.19.11"; then
      status="PATCHED"
      reason="Mainline/stable kernel is at or beyond an upstream fixed version"
    elif ver_ge "$base" "6.18.21" && ver_lt "$base" "6.19.0"; then
      status="PATCHED"
      reason="6.18 stable kernel is at or beyond upstream fixed version"
    elif ver_ge "$base" "6.12.80" && ver_lt "$base" "6.13.0"; then
      status="PATCHED"
      reason="6.12 stable kernel is at or beyond upstream fixed version"
    fi
  fi
fi

bpf_gate="unknown"
if [ -r /proc/sys/kernel/unprivileged_bpf_disabled ]; then
  bpf_gate="$(cat /proc/sys/kernel/unprivileged_bpf_disabled 2>/dev/null)"
fi

printf 'Kernel release: %s\n' "$rel"
printf 'Base version:   %s\n' "$base"
printf 'unprivileged_bpf_disabled: %s\n' "$bpf_gate"
printf 'Assessment reason: %s\n' "$reason"

case "$status" in
  VULNERABLE)
    if [ "$bpf_gate" = "1" ] || [ "$bpf_gate" = "2" ]; then
      printf 'VULNERABLE\n'
      exit 1
    else
      printf 'VULNERABLE\n'
      exit 1
    fi
    ;;
  PATCHED)
    printf 'PATCHED\n'
    exit 0
    ;;
  *)
    printf 'UNKNOWN\n'
    exit 2
    ;;
esac

Sources

1. NVD CVE-2026-31413
2. Debian security tracker CVE-2026-31413
3. Ubuntu CVE-2026-31413 advisory
4. Linux kernel sysctl documentation (`unprivileged_bpf_disabled`)
5. Linux `bpf(2)` manual page
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS API documentation