CVE-2026-98591

What it actually does

Unsigned subtraction in skb_pointer_if_linear allows underflow when offset exceeds skb_headlen, bypassing the linear-area bounds check and returning an arbitrary pointer of the form *(skb->data + off) that backs a dynptr with invalid memory.

Why it matters to the business

Attackers with the ability to load BPF programs can trigger kernel memory corruption on affected Linux systems, risking crashes, denial of service, or local privilege escalation across servers, containers, and network devices.

How an attack unfolds

An attacker loads a BPF program that uses skb-backed dynptrs, supplies an offset larger than skb_headlen to skb_pointer_if_linear, triggers the underflow so the bounds check passes, obtains an invalid pointer, and then uses the resulting dynptr to read or write outside intended skb bounds.

How to fix it

Upgrade the Linux kernel to a version containing the corrected skb_pointer_if_linear logic that uses safe u64 arithmetic and explicitly fails the check on potential underflow; rebuild and redeploy any custom kernels or distributions that embed the vulnerable code.

How to confirm the fix worked

Confirm the running kernel contains the bounds-check fix by inspecting the skb_pointer_if_linear implementation or by running regression tests that exercise skb-backed dynptr creation with offsets near skb_headlen; monitor for the absence of spurious pointer generation in BPF verifier or runtime logs.

Typical attack path

1. Obtain capability to load unprivileged or privileged BPF programs on the target host
2. Craft a BPF program that creates an skb-backed dynptr and invokes skb_pointer_if_linear with a carefully chosen offset
3. Trigger the underflow in the unsigned subtraction so the linear-area check erroneously succeeds
4. Receive an out-of-bounds pointer that backs the dynptr with invalid memory
5. Use the corrupted dynptr to perform reads or writes that corrupt kernel memory or leak data

How to detect it

Review kernel logs for oops or warnings mentioning skb_pointer_if_linear or dynptr; inspect audit logs for unusual BPF program loads or verifier rejections around dynptr creation; correlate with process execution of bpftool or custom loaders shortly before crashes.

What your security team should do

• Prioritize kernel updates on all systems that allow unprivileged BPF loading
• Restrict unprivileged BPF program loading via sysctl or LSM policies until patches are applied
• Audit production workloads for direct use of skb-backed dynptrs in custom BPF code
• Enable kernel hardening features such as lockdown mode and BPF JIT hardening