CVE-2026-98376

What it actually does

Bypassing max_entries equality check during percpu array inner map replacement allows replacement map with smaller size; percpu_array_map_gen_lookup inlines stale larger index_mask as JIT immediate, enabling out-of-bounds pptrs[] access on subsequent lookups.

Why it matters to the business

Kernel memory corruption or crashes on Linux systems that use BPF programs with percpu arrays as inner maps, risking service disruption and potential privilege escalation in affected environments.

How an attack unfolds

Attacker loads a BPF program using a percpu array as an inner map, then replaces it at runtime with a map having fewer max_entries; the missing check lets the original larger index_mask remain in JIT code, so crafted lookups read or write beyond allocated pptrs[].

How to fix it

Apply the upstream kernel patch that assigns array_map_meta_equal to percpu_array_map_ops.map_meta_equal and includes the new selftest; rebuild and deploy the fixed kernel across all affected Linux distributions.

How to confirm the fix worked

Inspect kernel source to confirm percpu_array_map_ops.map_meta_equal now references array_map_meta_equal; execute the added selftest to verify replacement of differently-sized percpu arrays is rejected.

Typical attack path

1. Create percpu array map with large max_entries as inner map template
2. Load outer map and attach BPF program that performs lookups
3. Replace inner map with new percpu array having smaller max_entries
4. Trigger repeated lookups via the outer map to exercise stale index_mask
5. Observe or exploit resulting out-of-bounds memory access

How to detect it

Audit BPF map creation and update syscalls via kernel tracing or auditd; watch for percpu array replacements followed by lookup patterns; inspect kernel crash dumps for faults involving index_mask or pptrs arrays.

What your security team should do

• Prioritize kernel updates on systems running BPF workloads with inner maps
• Review and restrict unprivileged BPF map creation where possible
• Monitor kernel logs for map replacement events and unexpected OOB faults
• Test the provided selftest in CI pipelines before broad rollout