CVE-2026-98589

What it actually does

The BPF verifier failed to reject cases where PTR_TO_PACKET registers were passed into subprograms capable of mutating packet memory via pskb_* helpers; such pointers were treated as stable PTR_TO_MEM across the call boundary, allowing subsequent accesses to invalidated regions after a packet resize or reallocation.

Why it matters to the business

Systems relying on untrusted or complex eBPF packet-processing programs face elevated risk of kernel memory corruption, crashes, or local privilege escalation, particularly on hosts that permit unprivileged BPF loading.

How an attack unfolds

An attacker authors a BPF program that forwards a packet pointer into a subprogram performing a mutating helper call; the verifier incorrectly models the pointer as valid for the entire subprogram lifetime, enabling out-of-bounds or use-after-invalidation accesses that can be turned into arbitrary read/write or denial of service.

How to fix it

Apply the upstream kernel commit that adds the verifier check rejecting PTR_TO_PACKET arguments to mutating subprograms; rebuild and deploy the patched kernel on all affected hosts.

How to confirm the fix worked

Confirm the presence of the new verifier rejection logic by inspecting the kernel source for the added check on packet pointers across subprogram boundaries, or run existing BPF selftests that exercise the disallowed pattern and verify they now fail to load.

Typical attack path

1. Identify or create a BPF program that passes a packet pointer to a mutating subprogram
2. Load the program via the bpf() syscall with appropriate privileges
3. Attach the program to a packet-processing hook (e.g., XDP, tc, or cgroup)
4. Inject or receive packets that trigger the subprogram path
5. Trigger memory corruption through subsequent accesses to the now-invalid packet region

How to detect it

Monitor kernel logs for BPF verifier load failures or warnings related to packet pointer handling; review audit logs of bpf() syscalls for programs that previously would have been accepted but are now rejected.

What your security team should do

• Prioritize kernel updates on systems that allow unprivileged BPF or run complex packet-processing programs
• Temporarily disable unprivileged BPF loading via the unprivileged_bpf_disabled sysctl where feasible
• Audit existing BPF programs for any that pass packet pointers into subprograms performing packet mutations