On 12/29/25 4:50 PM, Alexei Starovoitov wrote:
> On Mon, Dec 29, 2025 at 4:39 PM Ihor Solodrai <[email protected]> wrote:
>>
>> [...]
>>
>>
>> From 7c3b9cce97cc76d0365d8948b1ca36c61faddde3 Mon Sep 17 00:00:00 2001
>> From: Ihor Solodrai <[email protected]>
>> Date: Mon, 29 Dec 2025 15:49:51 -0800
>> Subject: [PATCH] BTF_OBJCOPY
>>
>> ---
>> Makefile | 6 +++++-
>> lib/Kconfig.debug | 1 +
>> scripts/gen-btf.sh | 10 +++++-----
>> scripts/link-vmlinux.sh | 2 +-
>> tools/testing/selftests/bpf/Makefile | 4 ++--
>> 5 files changed, 14 insertions(+), 9 deletions(-)
>
> All the makefile hackery looks like overkill and wrong direction.
>
> What's wrong with kernel/module/main.c change?
>
> Module loading already does a bunch of sanity checks for ELF
> in elf_validity_cache_copy().
>
> + if (sym[i].st_shndx >= info->hdr->e_shnum)
> is just one more.
>
> Maybe it can be moved to elf_validity*() somewhere,
> but that's a minor detail.
>
> iiuc llvm-objcopy affects only bpf testmod, so not a general
> issue that needs top level makefile changes.
AFAIU, the problem is that the llvm-objcopy bug is essentially
use-after-free [1], that may (or may not) corrupt st_shndx value of
some symbols when executing --update-section.
And so we can't trust this command anywhere in the kernel build, even
though it only manifested itself in a BPF test module.
With the gen-btf.sh changes ${OBJCOPY} --update-section is called for
all binaries with .BTF_ids: vmlinux and all modules.
The fix in module.c is an independent kernel bug, that is hopefully
fixed with the st_shndx check.
[1] https://github.com/llvm/llvm-project/issues/168060#issuecomment-3533552952
