Re: [PATCH bpf-next v4 07/12] bpf: Unify referenced object tracking in verifier

Amery Hung <[email protected]> Thu, 7 May 2026 14:55:35 +0200
Newsgroups dev.linux.lists.sashiko,org.kernel.vger.bpf
Message-ID <CAMB2axNQ+W7OUa8vkuedT7hGebn0TS=-aA9FJd+ZvsFCWE1+sQ@mail.gmail.com>
On Wed, May 6, 2026 at 11:48 PM <[email protected]> wrote:
> >               }
> >               /* Track parent's id if the parent is a referenced object */
> > +             if (ref_obj && ref_obj->ref_obj_id) {
> > +                     if (ref_obj->cnt > 1) {
> > +                             verifier_bug(env, "function expects only one referenced object but got %d\n", ref_obj->cnt);
> > +                             return -EFAULT;
> > +                     }
> > +                     parent_id = ref_obj->id;
> > +             }
>
> Since ref_obj->cnt is determined by the number of referenced arguments
> provided by the BPF program, is it possible for a user to intentionally
> trigger this verifier_bug() by passing multiple referenced objects?
>
> Since verifier_bug() expands to BPF_WARN_ONCE(), triggering a warning
> via unprivileged or user-controlled input could be problematic if
> panic_on_warn is enabled.
>
> Would it be safer to gracefully reject the program using verbose() and
> returning -EINVAL, similar to how it is handled for release kfuncs earlier
> in this patch?

Ack. Will change to verbsoe().

>
> This same pattern appears in a few other places introduced by this patch: