Re: [RFC PATCH v1] module: Fix kernel panic when a symbol st_shndx is out of bounds

On 12/29/25 4:50 PM, Alexei Starovoitov wrote:

On Mon, Dec 29, 2025 at 4:39 PM Ihor Solodrai [off-list ref] wrote:

quoted

On 12/29/25 1:29 PM, Nathan Chancellor wrote:

quoted

Hi Ihor,

On Mon, Dec 29, 2025 at 12:40:10PM -0800, Ihor Solodrai wrote:

quoted

I think the simplest workaround is this one: use objcopy from binutils
instead of llvm-objcopy when doing --update-section.

There are just 3 places where that happens, so the OBJCOPY
substitution is going to be localized.

Also binutils is a documented requirement for compiling the kernel,
whether with clang or not [1].

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/changes.rst?h=v6.18#n29

This would necessitate always specifying a CROSS_COMPILE variable when
cross compiling with LLVM=1, which I would really like to avoid. The
LLVM variants have generally been drop in substitutes for several
versions now so some groups such as Android may not even have GNU
binutils installed in their build environment (see a recent build
fix [1]).

I would much prefer detecting llvm-objcopy in Kconfig (such as by
creating CONFIG_OBJCOPY_IS_LLVM using the existing check for
llvm-objcopy in X86_X32_ABI in arch/x86/Kconfig) and requiring a working
copy (>= 22.0.0 presuming the fix is soon merged) or an explicit opt
into GNU objcopy via OBJCOPY=...objcopy for CONFIG_DEBUG_INFO_BTF to be
selectable.

I like the idea of opt into GNU objcopy, however I think we should
avoid requiring kbuilds that want CONFIG_DEBUG_INFO_BTF to change any
configuration (such as adding an explicit OBJCOPY= in a build command).

I drafted a patch (pasted below), introducing BTF_OBJCOPY which
defaults to GNU objcopy. This implements the workaround, and should be
easy to update with a LLVM version check later after the bug is fixed.

This bit:

@@ -391,6 +391,7 @@ config DEBUG_INFO_BTF
        depends on PAHOLE_VERSION >= 122
        # pahole uses elfutils, which does not have support for Hexagon relocations
        depends on !HEXAGON
+       depends on $(success,command -v $(BTF_OBJCOPY))

Will turn off DEBUG_INFO_BTF if relevant GNU objcopy happens to not be
installed.

However I am not sure this is the right way to fail here. Because if
the kernel really does need BTF (which is effectively all kernels
using BPF), then we are breaking them anyways just downstream of the
build.

An "objcopy: command not found" might make some pipelines red, but it
is very clear how to address.

Thoughts?


From 7c3b9cce97cc76d0365d8948b1ca36c61faddde3 Mon Sep 17 00:00:00 2001
From: Ihor Solodrai <ihor.solodrai@linux.dev>
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.

By the way, we don't have to put BTF_OBJCOPY variable in the top level
Makefile.  It can be defined in Makefile.btf, which is included only
with CONFIG_DEBUG_INFO_BTF=y

We have to define BTF_OBJCOPY in the top-level makefile *if* we want
CONFIG_DEBUG_INFO_BTF to depend on it, and get disabled if BTF_OBJCOPY
is not set/available.

I was trying to address Nathan's concern, that some kernel build
environments might not have GNU binutils installed, and kconfig should
detect that.  IMO putting BTF_OBJCOPY in Makefile.btf is more
appropriate, assuming the BTF_OBJCOPY variable is at all an acceptable
workaround for the llvm-objcopy bug.