> diff --git kernel/bpf/verifier.c kernel/bpf/verifier.c
> index 7ef324e384f4..da2ec0655b17 100644
> --- kernel/bpf/verifier.c
> +++ kernel/bpf/verifier.c
[ ... ]
> @@ -12653,12 +12653,12 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_call_arg_me
> !type_may_be_null(kf_arg_type)) {
> const char *expected_type;
>
> - expected_type = bpf_diag_fmt_btf_type(env, btf, ref_id);
> + expected_type = bpf_diag_fmt_btf_type(env, btf, args[i].type);
> verbose(env, "Possibly NULL pointer passed to trusted %s\n",
> reg_arg_name(env, argno));
> bpf_diag_call_arg_fmt(env, insn_idx, argno, func_name,
> "Add a NULL check and call the kfunc only on the non-NULL path.",
> - "the pointer may be NULL, but this kfunc requires a non-NULL pointer to %s",
> + "the pointer may be NULL, but this kfunc requires a non-NULL value of type %s",
> expected_type);
> return -EACCES;
> }
Switching from ref_id to args[i].type renders function pointer
parameters incorrectly. For kfuncs like bpf_task_work_schedule_signal()
that take a bpf_task_work_callback_t (which is itself a typedef to a
function pointer), btf_show_name() walks TYPEDEF -> PTR -> FUNC_PROTO,
collects the typedef name and adds one level of pointer indirection,
producing "bpf_task_work_callback_t *" instead of the correct parameter
type "bpf_task_work_callback_t".
For kfuncs like bpf_wq_set_callback() that take an unnamed function
pointer directly (PTR -> FUNC_PROTO), the FUNC_PROTO has no name, so
btf_show_name() produces the malformed "( *)".
Would it make sense to restrict the args[i].type formatting to object
pointers, or teach btf_show_name() not to add "*" for pointer typedefs
and unnamed FUNC_PROTO types? The other ref_id call sites later in the
same loop still use the pointee id, so the two conventions now coexist.
---
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/31921026518
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.