CVE-2026-98626: bpf: Restrict CO-RE poisoning to relocatable instructions
In the Linux kernel, the following vulnerability has been resolved:
bpf: Restrict CO-RE poisoning to relocatable instructions
CO-RE relocation records can name any instruction offset. When a relocation cannot be resolved, bpfcorepatchinsn() currently poisons its target before checking whether that instruction is a valid relocation target. Malformed metadata can therefore replace jumps, calls, exits, register-source arithmetic, or non-immediate loads instead of failing at the relocation step.
Handle poisoning only after the instruction has passed the same class and operand-form checks used for a resolved relocation. Route invalid forms through the existing diagnostic and return a hard error. Keep poisoning supported instructions, including both halves of a plain ldimm64, so an unresolved relocation in dead code remains valid.
Extend bpfcorepoisoninsn() to poison both halves of ldimm64, and return its status directly from each validated instruction case. This avoids routing the success path through a common label and leaves the helper free to report errors.
The shared relocation code applies this restriction to both libbpf and in-kernel CO-RE.
Affected Software
Event History
Frequently Asked Questions
What must an attacker control to trigger this issue?
An attacker needs to supply malformed CO-RE relocation metadata that names an instruction offset and causes relocation resolution to fail. The vulnerable handling can poison an instruction before confirming that it is a valid relocation target.
Which environments are affected by the shared relocation behavior?
The shared CO-RE relocation code is used by both libbpf and in-kernel CO-RE, so the restriction applies to both. The provided information does not identify affected kernel versions or configurations.
How can the corrected behavior be recognized?
For an unresolved relocation targeting an invalid instruction form, the relocation now follows the existing diagnostic path and returns a hard error rather than poisoning the instruction. Poisoning remains allowed only for validated supported targets, including both halves of a plain ldimm64 instruction.