Re: [PATCH bpf-next v5 1/3] selftests/bpf: Restrict bpf_set_retval argument in sk_bypass_prot_mem

[bot+bpf-ci]

> diff --git a/tools/testing/selftests/bpf/progs/sk_bypass_prot_mem.c b/tools/testing/selftests/bpf/progs/sk_bypass_prot_mem.c
> index 09a00d11ffcc..bae5283fca6b 100644
> --- a/tools/testing/selftests/bpf/progs/sk_bypass_prot_mem.c
> +++ b/tools/testing/selftests/bpf/progs/sk_bypass_prot_mem.c

[ ... ]

> @@ -97,6 +98,7 @@ int sock_create(struct bpf_sock *ctx)
>  	return 1;
>
>  err:
> +	set_if_not_errno_or_zero(err, -EFAULT);
>  	bpf_set_retval(err);
>  	return 0;
>  }

Could this cause a verifier bounds violation when multiple programs are
attached to a boolean LSM hook?

When do_refine_retval_range() calls bpf_lsm_get_retval_range() for a
boolean LSM hook, it strictly refines the register bounds to [0, 1].

However, if multiple programs are attached to the same cgroup hook via
BPF_F_ALLOW_MULTI, they run sequentially in bpf_prog_run_array_cg().
If the first program returns 0 (within the [0, 1] bounds),
bpf_prog_run_array_cg() translates this into an error code:

kernel/bpf/cgroup.c:bpf_prog_run_array_cg() {
    ...
    if (!func_ret && !IS_ERR_VALUE((long)run_ctx.retval))
        run_ctx.retval = -EPERM;
    ...
}

When the next BPF program in the array executes and calls bpf_get_retval(),
it receives the current run_ctx.retval, which is now -EPERM (-1).

Since the verifier statically assumes bpf_get_retval() will only return
0 or 1, could receiving -1 at runtime allow bypassing verifier checks and
performing out-of-bounds memory accesses?

This concern was raised by sashiko-bot on lore in v5:
https://lore.kernel.org/bpf/20260605144232.95A141F00893@xxxxxxxxxxxxxxx


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27021279696