Re: [RFC PATCH bpf-next v1 09/11] bpf: Let the comparator of bpf_rbtree_add unwind

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

On Wed Oct 28, 2026 at 2:21 AM CET, sashiko-bot wrote:
> [...]
> [Severity: High]
> Does the unwound path in __bpf_rbtree_add() leave node->owner poisoned with
> BPF_PTR_POISON when the object survives __bpf_obj_drop_impl()?

Right: with another reference holding the node, the drop left it with
its owner poisoned, and no add would take it again. The next version
unlinks it first, as bpf_rb_root_free() does.

> [...]
> [Severity: Critical]
> Can an unwinding comparator callback with a two-register return type clobber
> caller->regs[BPF_REG_2] in prepare_func_exit(), causing check_kfunc_call() to
> release the wrong reference ID and leave a dangling owning pointer to the
> dropped node?

Same as on 03/11: a callback hands over r0 alone in the next version, so
r2 stays the node the revisit releases.

> [...]