CVE-2026-98626

What it actually does

The flaw allows malformed CO-RE relocation metadata to poison non-relocatable instructions such as jumps, calls, exits, or register arithmetic before validity checks occur, potentially turning unresolved relocations into arbitrary instruction modifications instead of hard failures.

Why it matters to the business

Organizations running affected kernels face a small but non-zero risk that untrusted or attacker-supplied BPF programs could corrupt kernel verifier behavior, leading to stability issues or limited code-execution opportunities in eBPF-heavy environments such as observability, networking, or security tooling.

How an attack unfolds

An attacker crafts a BPF object file containing CO-RE relocation records that target invalid instruction offsets. When the kernel processes the relocation, bpf_core_patch_insn() poisons the instruction before checking its class and operand form, allowing the malformed record to overwrite control-flow or arithmetic instructions and bypass the relocation failure path.

How to fix it

Update to a Linux kernel containing the referenced fix that moves the poisoning step after class and operand-form validation. Rebuild and redeploy any custom BPF programs or distributions that embed the vulnerable CO-RE logic. Where immediate patching is not possible, restrict untrusted BPF loading via LSM or capability controls.

How to confirm the fix worked

Confirm the kernel source contains the updated bpf_core_patch_insn() logic that validates instruction class before calling bpf_core_poison_insn(), and that bpf_core_poison_insn() now handles both halves of ldimm64. Test by attempting to load a deliberately malformed CO-RE relocation and verifying that it produces a hard error rather than a poisoned instruction.

Typical attack path

1. Obtain or generate a BPF program with malicious CO-RE relocation metadata
2. Load the program via bpf() syscall or through a userspace loader such as libbpf
3. Trigger relocation processing in the kernel verifier or loader
4. Cause poisoning of a non-relocatable instruction to alter program semantics
5. Execute the resulting corrupted BPF program to achieve unintended verifier or runtime behavior

How to detect it

Review kernel audit logs and BPF verifier error messages for unexpected relocation failures or poisoning attempts. Examine system call traces involving bpf() with CO-RE relocation sections for malformed metadata patterns. No widespread exploitation has been observed.

What your security team should do

• Prioritize kernel updates for systems that accept untrusted BPF programs or use extensive CO-RE-based tooling
• Audit BPF loading policies and consider requiring CAP_BPF or LSM mediation
• Monitor upstream stable and distribution kernel releases for the backported fix
• Re-test critical BPF programs after upgrade to ensure relocation behavior remains unchanged