On Fri, Jun 5, 2026 at 12:27 PM [off-list ref] wrote:

quoted

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 7d27ba396d32..a741bf447931 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;

      /* skip for now, but return error when we find this in fixup_kfunc_call */
      if (!insn->imm)

This patch fixes the missing error check in check_kfunc_call(), but
could a similar issue exist in do_check_common() when initializing
struct_ops program arguments?

Looking at do_check_common(), there's a similar pattern where
acquire_reference() is called:

kernel/bpf/verifier.c:do_check_common() {
    ...
    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 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?

This is fixed in the next patch

---
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/27034008594