CVE-2025-68208

What it actually does

The BPF verifier's widen_imprecise_scalars() function can perform out-of-bounds reads/writes on bpf_verifier_state->frame[*]->stack because it does not account for differing allocated_stack depths between an ancestor state (prev_st) and a queued descendant state (queued_st).

Why it matters to the business

Systems running affected kernels may experience crashes or allow local attackers to corrupt kernel memory when unprivileged or containerized eBPF programs are loaded, increasing risk of denial of service or privilege escalation on servers and appliances that use BPF.

How an attack unfolds

An attacker compiles an eBPF program containing a loop that calls the same function with varying stack usage; the verifier's state exploration reaches widen_imprecise_scalars() with mismatched stack depths, causing an out-of-bounds stack access during imprecise scalar widening.

How to fix it

Upgrade Linux kernel to version 6.6.117 or later (or the equivalent stable commit 64b12dca2b0abcb5fc0542887d18b926ea5cf711) and rebuild any custom kernels; restart affected systems or reload BPF programs after the update. For helm-fips (Chainguard) update to 3.17.0-r2.

How to confirm the fix worked

Confirm the running kernel contains commit 64b12dca2b0abcb5fc0542887d18b926ea5cf711 or is at least version 6.6.117; attempt to load a test eBPF program that exercises the previously vulnerable widen_imprecise_scalars() path and verify the verifier no longer crashes or reports an error.

Typical attack path

1. Load a crafted eBPF program via bpf() syscall or through a user-space component
2. Trigger verifier path that calls find_prev_entry() followed by push_stack() and widen_imprecise_scalars()
3. Cause ancestor and queued states to have different allocated_stack values
4. Trigger out-of-bounds access on verifier stack frames
5. Achieve kernel memory corruption or crash

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for verifier oops or stack-out-of-bounds messages around the time of BPF program loads; monitor audit logs for unusual bpf() syscalls from non-root processes.

What your security team should do

• Apply the kernel update within the next maintenance window
• Restrict unprivileged BPF loading via kernel.unprivileged_bpf_disabled=1 until patched
• Audit any workloads that load custom eBPF programs for compatibility after upgrade