linux-kernel - Re: [PATCH bpf-next] libbpf: Ignore the modules that failed to load BTF object

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: <5f7583bd-2b62-46a3-b500-35c33111accb@oracle.com>
Date: Tue, 28 Oct 2025 18:21:08 +0000
From: Alan Maguire <alan.maguire@...cle.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Bixuan Cui <cuibixuan@...o.com>
Cc: ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
        martin.lau@...ux.dev, bpf@...r.kernel.org,
        linux-kernel@...r.kernel.org, eddyz87@...il.com, song@...nel.org,
        yonghong.song@...ux.dev, john.fastabend@...il.com, kpsingh@...nel.org,
        sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org
Subject: Re: [PATCH bpf-next] libbpf: Ignore the modules that failed to load
 BTF object

On 28/10/2025 18:05, Andrii Nakryiko wrote:
> On Tue, Oct 28, 2025 at 6:57 AM Bixuan Cui <cuibixuan@...o.com> wrote:
>>
>> Register kfunc in self-developed module but run error in other modules:
>>     libbpf: btf: type [164451]: referenced type [164446] is not FUNC_PROTO
>>     libbpf: failed to load module [syscon_reboot_mode]'s BTF object #2: -22
>>
>> It is usually skipping the error does not affect the search for the next module.
>>
>> Then ignoring the failed modules, load the bpf process:
>>     libbpf: btf: type [164451]: referenced type [164446] is not FUNC_PROTO
>>     libbpf: failed to load module [syscon_reboot_mode]'s BTF object #3: -22
>>     libbpf: extern (func ksym) 'bpf_kfunc': resolved to bpf_module [164442]
>>     ...
>>
>> Signed-off-by: Bixuan Cui <cuibixuan@...o.com>
>> ---
>>  tools/lib/bpf/libbpf.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>> index 711173acbcef..0fa0d89da068 100644
>> --- a/tools/lib/bpf/libbpf.c
>> +++ b/tools/lib/bpf/libbpf.c
>> @@ -5702,7 +5702,8 @@ static int load_module_btfs(struct bpf_object *obj)
>>                 if (err) {
>>                         pr_warn("failed to load module [%s]'s BTF object #%d: %d\n",
>>                                 name, id, err);
>> -                       goto err_out;
>> +                       close(fd);
>> +                       continue;
>>                 }
> 
> It's not an expected condition to have kernel module with corrupted
> BTF, so I don't think we should be doing this.
> 
> pw-bot: cr
>

Would be good to understand this failure better. If the module is being
built out-of-tree with relatively new pahole, it will have a .BTF.base
section and a .BTF section; the .BTF.base section allows the module to
carry stable references to vmlinux BTF types which then get fixed up to
the real vmlinux BTF id references when the module is loaded. It is
possible there are bugs in that code however, so it woul be good to
figure that out. bpftool should dump BTF for your module using the
.BTF.base section as base, so

bpftool btf dump file mymod.ko

should work (provided "objdump -h mymod.ko" shows a .BTF.base and .BTF
section).  If it does, the BTF id relocation may be breaking and we
might need to do further digging to understand where. It should relocate
BTF kfunc ids also, but again there may be a bug lurking here.

If the BTF is loading into the kernel, comparing

bpftool btf dump -B /sys/kernel/btf file /sys/kernel/btf/mymod

...to the .ko BTF would be valuable.

If your module only has a .BTF section and no .BTF.base section, it is
possible it did not get (re)built against an updated vmlinux and has
outdated type id references as a result.

Alan