Re: [PATCH bpf v3 4/7] bpf: Restrict CO-RE poisoning to relocatable instructions

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Mon Sep 14, 2026 at 10:21 PM CEST, Alexei Starovoitov wrote:
> On Mon, Sep 14, 2026 at 12:54 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
>>
>> On Mon, Sep 14, 2026 at 6:17 AM Kumar Kartikeya Dwivedi
>> <memxor@gmail.com> wrote:
>> >
>> > check_subprogs() verifies that each subprogram ends in an exit or an
>> > unconditional jump before in-kernel CO-RE relocations are applied.
>> > An unresolved relocation can then replace that terminal instruction with
>> > an invalid helper call. The resulting fall-through into another subprogram
>> > breaks the CFG invariant used by postorder and stack liveness analysis,
>> > which can write past their per-subprogram arrays.
>> >
>> > Handle instruction poisoning after the instruction has passed the same
>> > class and operand-form checks used for a resolved relocation. This rejects
>> > relocations targeting jumps, calls, exits, register-source arithmetic, or
>> > non-immediate loads before they can alter the control flow. Keep poisoning
>> > supported instructions, including both halves of a plain ldimm64, so an
>> > unresolved relocation in dead code remains valid.
>> >
>> > The shared relocation code applies this restriction to both libbpf and
>> > in-kernel CO-RE.
>> >
>> > Fixes: efcda22aa541 ("bpf: compute instructions postorder per subprogram")
>> > Reported-by: Nicholas Carlini <npc@anthropic.com>
>> > Suggested-by: Nicholas Carlini <npc@anthropic.com>
>> > Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
>> > ---
>> >  tools/lib/bpf/relo_core.c | 28 +++++++++++++++++-----------
>> >  1 file changed, 17 insertions(+), 11 deletions(-)
>> >
>>
>> Kumar, can you please see if we can move check_core_relo() to right
>> after bpf_prepare_btf_info() instead of trying to guard against
>> malicious CO-RE relocation? I think what CO-RE logic is doing here
>> with poisoning is correct, it marks instruction as invalid because
>> CO-RE relocation couldn't be resolved/applied/whatever. That's sane
>> generic behavior, IMO.
>>
>> The fact that this breaks subprog validation is more of a sign that we
>> do this CO-RE application too late, perhaps?
>>
>> Also looking at current bpf_check_btf_info() logic, seems like we'll
>> skip CO-RE relocations altogether if we don't have
>> func_info/line_info, which is... fine, I guess, in modern world. But
>> it certainly is a bit orthogonal. So check_core_relo() seems like a
>> stand-alone step to me, which hopefully can be done very-very early,
>> so that no matter what patching we did will be properly validated by
>> verifier.
>
> Let's do both:
> - move bpf_check_btf_info() right after bpf_prepare_btf_info()

This won't be a copy paste, since it depends on various checks on subprogs we
would end up skipping, but let me see how we can split some of the steps and
whether that ends up looking too bad.

> - check that relo applies to relocatable insns only
>   and hard error if it's not.

Ok.