linux-kernel - Re: [PATCH v2] kernel/bpf/btf.c: reject to register duplicated kfunc

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] [day] [month] [year] [list]

Message-ID: <CAADnVQJEjhJH6+2cLJ0jM_fZ366oU3yoK1b5aMk=VgksXhJtoQ@mail.gmail.com>
Date: Thu, 29 Jan 2026 18:54:52 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Song Chen <chensong_2000@....cn>
Cc: Martin KaFai Lau <martin.lau@...ux.dev>, Alexei Starovoitov <ast@...nel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, Eduard <eddyz87@...il.com>, 
	Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>, 
	John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, 
	Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, 
	bpf <bpf@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] kernel/bpf/btf.c: reject to register duplicated kfunc

On Thu, Jan 29, 2026 at 6:18 PM Song Chen <chensong_2000@....cn> wrote:
>
> hi,
>
> my comments are in line, thanks.
>
> Song
>
> 在 2026/1/28 12:28, Alexei Starovoitov 写道:
> > On Thu, Jan 22, 2026 at 1:04 AM <chensong_2000@....cn> wrote:
> >>
> >> From: Song Chen <chensong_2000@....cn>
> >>
> >> I had an ebpf program which calls a kfunc defined and
> >> implemented in one of my kernel modules, they were working
> >> fine in 6.16, but was broken by libbpf in 6.19, the error
> >> message was:
> >>
> >> libbpf: extern (func ksym) 'bpf_strstr': func_proto [5]
> >> incompatible with vmlinux [94389]
> >>
> >> yes, the reason is there is a new added kfunc in kernel 6.19
> >> which happens to be the same name with my kfunc. However the
> >> error message is not obvious enough to address problem
> >> immediately.
> >
> > I don't quite understand what you're trying to say.
> > "broken by libbpf"?! You mean that kernel 6.19 got
> > new kfunc bpf_strstr() ?
> > Why libbpf error is relevant?
> > You mean you had your own custom .h file where
> > you defined your own kfunc from a custom module
> > and libbpf complained that your bpf_strstr() kfunc
> > definition doesn't match the kernel 6.19 ?
>
> let me explain:
>
> I had a module, defined a kfunc(bpf_strstr) in its c file and register
> it through register_btf_kfunc_id_set.I also had a ebpf program to use
> bpf_strstr in this module.
>
> They were working fine in kernel 6.16, but kernel 6.19 has its own
> bpf_strstr, so when i ran my ebpf program in kernel 6.19, libbpf broke
> it here:
>
> bpf_object__resolve_ksym_func_btf_id
>    --bpf_core_types_are_compat
>      --__bpf_core_types_are_compat
>
> yes, your understanding is pretty much correct.
>
> >
> > and your proposed solution is ...
> >
> >> Therefore, this patches searches duplicated kfunc in
> >> btf_vmlinux before a kernel module attempts to register kfuncs
> >> through register_btf_kfunc_id_set, it prints clear error message
> >> and returns error code if same name kfunc has already implemented
> >> and registered, then developer knows at the first place.
> >
> > Are you saying that the kernel module that supplied bpf_strstr
> > shouldn't be allowed to register its kfunc if kfunc with
> > the same name exists in vmlinux. So insmod will fail?
>
> yes, two kfuncs of bpf_strstr are registered in the system and one of
> them is never used, this is a problem.
>
> >
> > This is debatable. I guess we can add such sanity check,
>
> agree, even it's not a big deal.
>
> > but what about kfunc in module A with the same name as kfunc
> > in module B?
>
> It's in my plan, also go through "list_for_each_entry_safe(btf_mod, tmp,
> &btf_modules, list)", but i haven't gone that far yet, i can add it.

I'm not convinced that we should be doing it.

> > Currently libbpf tells kernel both btf FD and kfunc btf ID,
> > though there is a single namespace for all kfuncs from bpf
> > program pov the kernel and libbpf api-s allow a selection.
> >
> > Technically we can hack something in bpf.c to "namespace" kfuncs
> > and say that the kfunc "foo" is in the module "bar".
> > It won't be pretty in C, but possible in principle.
> >
> > Maybe a kfunc with the same name in the module should be allowed
> > to override a kfunc in the kernel.
> > It can be seen as livepatching of kfuncs.
> > imo that's a more interesting use case than helping
> > out-of-tree module to produce nicier error.

because ^^^ is what I think we should be doing instead.
Since it is more applicable and useful.

I'd like to hear what other folks are thinking.