netdev - Re: [PATCH bpf-next v6 1/6] bpf: Allow verifier to fixup kernel module kfuncs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <ea0d6de3aa0a0370e1ac7328db2b09ead3f8ce1effa9a04f37fb09e1f87a5643@mail.kernel.org>
Date: Fri, 14 Nov 2025 23:06:17 +0000 (UTC)
From: bot+bpf-ci@...nel.org
To: ameryhung@...il.com,bpf@...r.kernel.org
Cc: netdev@...r.kernel.org,alexei.starovoitov@...il.com,andrii@...nel.org,daniel@...earbox.net,tj@...nel.org,martin.lau@...nel.org,ameryhung@...il.com,kernel-team@...a.com,ast@...nel.org,andrii@...nel.org,daniel@...earbox.net,martin.lau@...nel.org,eddyz87@...il.com,yonghong.song@...ux.dev,clm@...a.com,ihor.solodrai@...ux.dev
Subject: Re: [PATCH bpf-next v6 1/6] bpf: Allow verifier to fixup kernel module kfuncs

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 99d62d765..d7702b9c6 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -22416,8 +22416,7 @@ static int fixup_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>
>  	if (!bpf_jit_supports_far_kfunc_call())
>  		insn->imm = BPF_CALL_IMM(desc->addr);
> -	if (insn->off)
> -		return 0;
> +

Are the special kfunc comparisons below safe for module kfuncs?

The code after this change compares desc->func_id against
special_kfunc_list[] entries without checking desc->offset. Since
special_kfunc_list[] contains BTF IDs from kernel BTF, and module kfuncs
have BTF IDs from their own module BTF, could a module kfunc with a BTF
ID that happens to match a special kernel kfunc ID be incorrectly
processed?

In fixup_kfunc_call():
  desc = find_kfunc_desc(env->prog, insn->imm, insn->off);
  [...]
  if (desc->func_id == special_kfunc_list[KF_bpf_obj_new_impl] || ...)

The desc->func_id contains a BTF-local ID (set at line 3373), while
special_kfunc_list[] contains kernel BTF IDs. Module BTF IDs start from
1 independently, so collision is architecturally possible.

During verification, check_special_kfunc() at line 13691 checks "if
(meta->btf != btf_vmlinux) return 0;" which prevents aux_data fields
like kptr_struct_meta from being set for module kfuncs. But at fixup
time, if a module kfunc's BTF ID collides with a special kernel kfunc
ID, won't it enter these paths and read uninitialized aux_data fields?

Would adding "desc->offset == 0 &&" or "insn->off == 0 &&" to the
comparisons at lines 22420, 22437, 22460, 22481 ensure we only match
kernel kfuncs?

>  	if (desc->func_id == special_kfunc_list[KF_bpf_obj_new_impl] ||
>  	    desc->func_id == special_kfunc_list[KF_bpf_percpu_obj_new_impl]) {
>  		struct btf_struct_meta *kptr_struct_meta = env->insn_aux_data[insn_idx].kptr_struct_meta;

[ ... ]

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