Re: [PATCH bpf-next v5 14/14] bpf: Report Policy helper and kfunc errors

Eduard Zingerman <[email protected]>
Newsgroups org.kernel.vger.bpf
Message-ID <[email protected]>
On Sat, 2026-08-15 at 07:20 +0000, [email protected] wrote:
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 64c5c31ed230..ff028a8c1cca 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> 
> [ ... ]
> 
> > @@ -2924,6 +2924,10 @@ static int add_subprogs(struct bpf_verifier_env *env)
> > 
> >  		if (!env->bpf_capable) {
> >  			verbose(env, "loading/calling other bpf or kernel functions are allowed for CAP_BPF and CAP_SYS_ADMIN\n");
> > +			bpf_diag_policy(
> > +				env, i, "BPF-to-BPF function call",
> > +				"loading or calling other BPF functions requires CAP_BPF or CAP_SYS_ADMIN",
> > +				"Load this program with the required capability, or avoid BPF-to-BPF function calls in unprivileged programs.");
> >  			return -EPERM;
> >  		}
> 
> Does the operation string here accurately describe both cases? This
> branch can fire for two types of instructions. The loop filter above
> checks:
> 
>     if (!bpf_pseudo_func(insn) && !bpf_pseudo_call(insn))
>             continue;
> 
> So it matches both actual BPF-to-BPF calls (bpf_pseudo_call) and
> ld_imm64 instructions that load a subprogram address for later use as
> a callback argument (bpf_pseudo_func).

Wording is fine.

...
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.