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: