Re: [PATCH bpf-next v1 1/3] bpf: Fix dead error check on acquire_reference() in check_kfunc_call

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing error check on `acquire_reference()` in `do_check_common` allows BPF programs to bypass reference tracking and leak kernel resources.
--

commit 259ddea87c590cd0902d75313fa1c99925c708fb
Author: Amery Hung <ameryhung@gmail.com>

bpf: Fix dead error check on acquire_reference() in check_kfunc_call

This commit changes the type of the 'id' variable from a u32 to an int
so that negative error codes returned from acquire_reference() are
checked correctly instead of being treated as large positive integers.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 8ed484cb1a8a4..6446db9628aed 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -12817,9 +12817,10 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>  	struct bpf_kfunc_call_arg_meta meta;
>  	struct bpf_insn_aux_data *insn_aux;
>  	int err, insn_idx = *insn_idx_p;
> -	u32 i, nargs, ptr_type_id, id;
>  	const struct btf_param *args;
> +	u32 i, nargs, ptr_type_id;
>  	struct btf *desc_btf;
> +	int id;

[Severity: High]
This isn't a bug introduced by this patch, but since we are fixing a missing
error check on acquire_reference() here, could a similar issue exist in
do_check_common() when initializing struct_ops program arguments?

In kernel/bpf/verifier.c:do_check_common():

    /* Acquire references for struct_ops program arguments tagged with "__ref" */
    if (!subprog && env->prog->type == BPF_PROG_TYPE_STRUCT_OPS) {
        for (i = 0; i < aux->ctx_arg_info_size; i++)
            aux->ctx_arg_info[i].ref_id = aux->ctx_arg_info[i].refcounted ?
                              acquire_reference(env, 0, 0) : 0;
    }

Since acquire_reference() can return a negative error like -ENOMEM, assigning
it directly to aux->ctx_arg_info[i].ref_id (which is a u32) without checking
for errors seems like it would swallow the error code.

Does this allow the verifier to successfully accept a BPF program without
tracking the reference, potentially leading to a kernel resource leak when
the reference isn't released at runtime?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604220904.1032145-1-ameryhung@gmail.com?part=1