linux-stable.git/scripts, branch v7.2.6

modpost: prevent leak when early return no suffix .o in read_symbols()

2026-09-14T11:40:21+00:00

[ Upstream commit 9a5b76027ed91680e10f90111d9cba300f96d1ab ]

The allocation for elf info symsearch and hdr from parse_elf() haven't
been released when return because of modname didn't have suffix ".o".
And it seems like the suffix ".o" check did not depends on parse_elf()
to succeed first. So, move the suffix ".o" check before checking
parse_elf() result to prevent resource leak when the modname didn't have
suffix ".o" and return early.

This is reported by Coverity Scan as "Resource leak".

Fixes: 8c9ce89c5b63 ("modpost: simplify mod->name allocation")
Signed-off-by: Robertus Diawan Chris 
Reviewed-by: Nathan Chancellor 
Link: https://patch.msgid.link/20260624044742.144852-1-robertusdchris@gmail.com
Signed-off-by: Nicolas Schier 
Signed-off-by: Sasha Levin

scripts/tags.sh: Prevent binary files appearing in cscope.files

2026-09-14T11:40:21+00:00

[ Upstream commit a9b93c34625a27bed5dc0f80ee2a359ceb955172 ]

When executing the command `make COMPILED_SOURCE=1 cscope`, the resulting
`cscope.files` file contains filenames with the extensions *.rlib, *.rmeta,
and *.so.

To fix this, modify the regular expression in the `all_compiled_sources()`
function so that only files with the extensions *.h, *.c, *.S, and *.rs are
accepted.

The issue has been introduced by commit 4f491bb6ea2a ("scripts/tags.sh:
collect compiled source precisely") which implemented the parsing of
compiled sources from *.cmd files instead of using the "find" command.

Fixes: 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely")
Signed-off-by: Sergei Litvin 
Acked-by: Miguel Ojeda 
Tested-by: Nicolas Schier 
Reviewed-by: Nicolas Schier 
Link: https://patch.msgid.link/20260714083331.69482-1-litvindev@gmail.com
[nsc: cleaned-up commit message line breaks and removed cc trailers]
Signed-off-by: Nicolas Schier 
Signed-off-by: Sasha Levin

objtool/klp: Fix symbol resolution for duplicate data symbols

2026-09-14T11:40:12+00:00

[ Upstream commit 15fa203ef91e8a303c322eaaa8ca01a6ddaf94dc ]

find_sympos() calculates a sympos used by livepatch to disambiguate
duplicately-named symbols.  For function symbols, there's a hack which
counts .text.unlikely symbols before other .text symbols, matching the
linker script's section ordering.

Not only is the hack fragile, data symbols can have the same problem.
So for example, adding a reference to pwq_cache in
ep_unregister_pollwait() can trigger a corrupt sympos and a relocation
to the wrong pwq_cache symbol in the livepatch module, resulting in a
crash or undefined behavior.

Remove the existing hack in favor of a fully deterministic solution,
using the new .klp.symid table to derive the symbol-to-id mapping from
the original vmlinux.o and the id-to-address mapping from the
corresponding vmlinux, which can then be used to determine the exact
sympos associated with the original vmlinux.

Modules don't need any special treatment: the .ko has the same
section/symbol ordering as the original whole-archive symbol table.

Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Reported-by: Ben Procknow 
Reported-by: Joe Lawrence 
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Ingo Molnar 
Cc: live-patching@vger.kernel.org
Link: https://lore.kernel.org/20260710153042.3156788-1-joe.lawrence@redhat.com
Link: https://lore.kernel.org/20260724221730.3126529-1-joe.lawrence@redhat.com
Link: https://patch.msgid.link/919785e3bf2245db02ff6391e735d9cb139170b1.1785727106.git.jpoimboe@kernel.org
Signed-off-by: Sasha Levin

objtool/klp: Add .klp.symid for sympos disambiguation

2026-09-14T11:40:11+00:00

[ Upstream commit 029223d301620bc4e1086696047b0d5d6eba5edd ]

Livepatch identifies a duplicate-named symbol by its position (sympos)
among same-named kallsyms entries, which for vmlinux are counted in
ascending address order in the final linked kernel.  That order can't be
reliably derived from vmlinux.o: the final link reorders sub-sections
(.text.unlikely*, .data..*, etc).

Bridge the gap with a new .klp.symid section which can be used to
correlate symbols between vmlinux.o and vmlinux so that klp-diff can
reliably determine the sympos.

The table can't survive --gc-sections: keeping it alive would keep every
duplicate-named symbol's section alive, so the reference kernel would
stop matching the one which ships.  klp-build rejects
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION instead.  Nothing is lost today:
x86_64 is the only HAVE_KLP_BUILD arch and doesn't select
HAVE_LD_DEAD_CODE_DATA_ELIMINATION, arm64 and s390 have never selected
it either, and on powerpc, it's still EXPERIMENTAL and disabled by every
distro kernel.

This is the build-time half of reliable vmlinux sympos computation;
"objtool klp diff" will consume the table in a subsequent commit.

Signed-off-by: Josh Poimboeuf 
Signed-off-by: Ingo Molnar 
Cc: live-patching@vger.kernel.org
Link: https://patch.msgid.link/64d50f077b569f47883c015cdb7079edb068efe8.1785727106.git.jpoimboe@kernel.org
Stable-dep-of: 15fa203ef91e ("objtool/klp: Fix symbol resolution for duplicate data symbols")
Signed-off-by: Sasha Levin

kbuild: rust: keep Rust objects out of Clang LTO with inline helpers

2026-09-07T15:36:32+00:00

commit 5febf432df1cfa5b25d99b54c32103fafbdd0eb9 upstream.

Under `CONFIG_LTO_CLANG` + `CONFIG_RUST_INLINE_HELPERS`, one may hit
`objtool` errors such as:

    vmlinux.o: error: objtool: _R..._3Gsp4boot+0xd6a:
    can't find jump dest instruction at .text._R..._3Gsp4boot+0x1dfd

The reason is that in such builds, the Clang invocation that compiles
the combined Rust plus helpers bitcode emits LLVM bitcode (again) --
the final code generation happens in the linker's LTO step, which the
`-mllvm` trap options passed to Clang do not reach.

This, in turn, means that unreachable traps are missing, and the
impossible paths do not merely fallthrough to the next symbol, but past
the end of their own section, since LTO builds place each function in
its own section.

Thus filter `CC_FLAGS_LTO` out of the Clang invocation, so that it always
emits machine code directly, with the traps in place.

Assisted-by: LLM
Cc: Gary Guo 
Cc: Boqun Feng 
Cc: Alice Ryhl 
Cc: Matthew Maurer 
Cc: Josh Poimboeuf 
Cc: Peter Zijlstra 
Cc: stable@vger.kernel.org
Fixes: 3a2486cc1da5 ("kbuild: rust: provide an option to inline C helpers into Rust")
Acked-by: Gary Guo 
Link: https://patch.msgid.link/20260816133233.197500-2-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

kbuild: rust: preserve unreachable traps with inline helpers

2026-09-07T15:36:32+00:00

commit 0bff7711c19ba05ff3b686554c5a2d503c3e9797 upstream.

When `CONFIG_RUST_INLINE_HELPERS` is enabled, it is possible to hit
`objtool` warnings like:

    vmlinux.o: warning: objtool: _R..._4cmdq12CommandToGsp4init()
    falls through to next function _R..._4core5array4iter8IntoIterRShKj3_EEEBa_()

`rustc` normally emits traps for unreachable paths. However, under
`CONFIG_RUST_INLINE_HELPERS=y`, `rustc` emits LLVM bitcode and Clang
performs final code generation after the helper bitcode is linked,
but Clang does not trap unreachable IR by default.

In turn, this means `objtool` follows compiler-generated impossible Rust
`enum` paths through alignment padding into the next function, resulting
in fallthrough warnings.

Thus pass the LLVM `trap-unreachable` option to the final Clang invocation
and suppress traps immediately after `noreturn` calls, which `objtool`
already recognizes as dead ends. The combination of both flags makes it
match `rustc`'s behavior.

Rust 1.85.0 (the minimum supported one) supports LLVM >= 18, and both
flags are available in LLVM 18.

Assisted-by: LLM
Cc: Gary Guo 
Cc: Boqun Feng 
Cc: Alice Ryhl 
Cc: Matthew Maurer 
Cc: Josh Poimboeuf 
Cc: Peter Zijlstra 
Cc: stable@vger.kernel.org
Fixes: 3a2486cc1da5 ("kbuild: rust: provide an option to inline C helpers into Rust")
Acked-by: Gary Guo 
Link: https://patch.msgid.link/20260816133233.197500-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

rust: rust_is_available: warn for `bindgen` < 0.72.1 && libclang >= 22

2026-09-07T15:36:31+00:00

commit dc01dfb37b34beeefcfe1c3055364d41a4070c7e upstream.

Starting with LLVM 22, `clang_getTypeDeclaration()` may return a forward
declaration instead of the type definition. This made `bindgen` generate
opaque types [1][2], which in turn made us fail with e.g.

    error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`
      --> rust/kernel/module_param.rs:78:46
       |
    78 |         let container = unsafe { &*((*param).__bindgen_anon_1.arg.cast::>()) };
       |                                              ^^^^^^^^^^^^^^^^ unknown field
       |
       = note: available field is: `_address`

This was fixed in `bindgen` 0.72.1 [3].

In order to clarify what is going on and avoid confusion [4][5], add
a warning to `rust_is_available.sh` about it when the versions match,
similar to past warnings like the one removed in:

  commit ae64324ad5c1 ("rust: rust_is_available: remove warning for `bindgen` < 0.69.5 && libclang >= 19.1")

In addition, even if the versions match, check if the issue appears to
not reproduce with the given binaries, to avoid a warning in such a case.

Finally, include tests.

[ Nathan, in parallel, updated the instructions of the LLVM+Rust
  kernel.org toolchains [6] so that `--version` is not passed to
  `cargo` for `bindgen`, and thus the latest `bindgen` is installed
  by default, which should help to avoid some of these situations.

  Thanks!

    - Miguel ]

Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Link: https://github.com/rust-lang/rust-bindgen/issues/3264 [1]
Link: https://github.com/Rust-for-Linux/linux/issues/353 [2] # "Missing fields in nested class with LLVM 22."
Link: https://github.com/rust-lang/rust-bindgen/pull/3278 [3]
Reported-by: Burak Emir 
Link: https://github.com/Rust-for-Linux/linux/issues/1247 [4]
Link: https://lore.kernel.org/rust-for-linux/CABwQupNfMAJOGqRM9ke6tj4f53dCCsBDKU7Vp+zf8mwk7bqt8Q@mail.gmail.com/ [5]
Link: https://mirrors.edge.kernel.org/pub/tools/llvm/rust/ [6]
Tested-by: Burak Emir 
Link: https://patch.msgid.link/20260719120514.159914-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

kbuild: rpm-pkg: Preserve BTF sections in kernel modules during debuginfo stripping

2026-07-29T23:21:42+00:00

After switching to the kernel's default package scripts for our local
kernel RPM builds, we noticed that module BTF entries were missing:

  $ ls /sys/kernel/btf/
  vmlinux    <<<< only vmlinux, no module BTF

Root cause: find-debuginfo.sh (from the debugedit package) prefers
eu-strip over strip when elfutils is installed, which is the common
case on RHEL 9. eu-strip removes non-allocated ELF sections, including
the .BTF section that contains BPF Type Format information for kernel
modules. Without .BTF, BPF tools (bpftool, bcc, bpftrace) cannot resolve
kernel types at runtime, and /sys/kernel/btf/ entries are not
created when modules are loaded.

Additionally, since commit 8646db238997 ("libbpf,bpf: Share BTF
relocate-related code with kernel"), modules contain a .BTF.base section
that maps distilled type IDs to vmlinux types. If .BTF.base is stripped,
btf_parse_module() falls back to vmlinux BTF directly, causing type ID
mismatches and rejecting the module's BTF entirely.

Fix by passing --keep-section .BTF and --keep-section .BTF.base via
_find_debuginfo_opts, which adds -K .BTF and -K .BTF.base to the
eu-strip/strip command, preserving both sections while allowing normal
debuginfo extraction to proceed.

After this change, all module BTF files are properly generated:

  $ ls /sys/kernel/btf/
  aesni_intel         drm                 i2c_i801            mfd_core
  ahci                drm_client_lib      i2c_mux             net_failover
  backlight           drm_kms_helper      i2c_smbus           pcspkr
  ccp                 drm_shmem_helper    input_leds          qemu_fw_cfg
  dm_log              failover            intel_rapl_common   sch_fq_codel
  dm_mirror           fat                 intel_rapl_msr      serio_raw
  dm_mod              fuse                irqbypass           sunrpc
  dm_region_hash      gf128mul            iTCO_wdt            vfat
  virtio_balloon      virtio_console      virtio_dma_buf      virtio_gpu
  virtio_net          virtio_rng          virtio_blk          vmlinux
  xfs

Suggested-by: Nathan Chancellor 
Signed-off-by: Yafang Shao 
Cc: Alan Maguire 
Link: https://patch.msgid.link/20260728024950.44946-1-laoar.shao@gmail.com
Signed-off-by: Nathan Chancellor

scripts/sorttable: Handle RISC-V patchable ftrace entries

2026-06-25T19:15:03+00:00

RISC-V uses -fpatchable-function-entry=8,4 when the compressed ISA is
enabled and -fpatchable-function-entry=4,2 otherwise. In both cases, the
patchable NOP area starts 8 bytes before the function symbol address.
The __mcount_loc entries therefore point at the patchable NOP area
associated with a function, while nm reports the function symbol at the
entry address used for the function range check.

After RISC-V selected HAVE_BUILDTIME_MCOUNT_SORT, sorttable started
applying that range check at build time. Without allowing entries just
before the reported function address, the mcount sorter treats valid
RISC-V ftrace callsites as invalid weak-function entries and writes
them back as zero. The resulting kernel boots with no ftrace entries,
breaking dynamic ftrace and users such as livepatch.

The failure is silent during the final link because zeroing weak-function
entries is an expected sorttable operation. At boot, those zero entries
are skipped by ftrace_process_locs(), so the only obvious symptom is that
the vmlinux ftrace table has lost valid callsites and ftrace users cannot
attach to them.

CONFIG_FTRACE_SORT_STARTUP_TEST also reports the table as sorted in this
state: it only checks that the __mcount_loc entries are in ascending
order, which a fully zeroed table trivially satisfies. The original
commit relied on this check and did not see the regression.

On an affected RISC-V QEMU boot with both CONFIG_FTRACE_SORT_STARTUP_TEST
and CONFIG_FTRACE_STARTUP_TEST enabled, the sort check still passes
while ftrace reports zero usable entries and the early selftests fail:

  [    0.000000] ftrace section at ffffffff8101da98 sorted properly
  [    0.000000] ftrace: allocating 0 entries in 128 pages
  [    0.054999] Testing tracer function: .. no entries found ..FAILED!
  [    0.172407] tracer: function failed selftest, disabling
  [    0.178186] Failed to init function_graph tracer, init returned -19

Handle RISC-V like arm64 for the function-range check and allow
patchable entries up to 8 bytes before the function address.

With this fix, a RISC-V QEMU smoke boot with ftrace startup tests shows
the vmlinux ftrace table is populated and dynamic ftrace still works:

  [    0.000000] ftrace: allocating 46749 entries in 184 pages
  [    0.051115] Testing tracer function: PASSED
  [    1.283782] Testing dynamic ftrace: PASSED
  [    6.275456] Testing tracer function_graph: PASSED

Fixes: 0ca1724b56af ("riscv: ftrace: select HAVE_BUILDTIME_MCOUNT_SORT")
Suggested-by: Steven Rostedt (Google) 
Reviewed-by: Steven Rostedt 
Reviewed-by: Shuai Xue 
Reviewed-by: Chen Pei 
Link: https://lore.kernel.org/all/20260527113028.4b21a5de@fedora/
Signed-off-by: Wang Han 
Reviewed-by: Martin Kaiser 
Link: https://patch.msgid.link/20260609063002.3943001-1-wanghan@linux.alibaba.com
Signed-off-by: Paul Walmsley

Merge tag 'kbuild-7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux

2026-06-25T16:06:12+00:00

Pull more Kbuild updates from Nathan Chancellor:

 - Link host programs with ld.lld when $(LLVM) is set to match user's
   expectations that LLVM will be used exclusively during the build
   process

 - Fix modpost warnings from static variable name promotion that can
   happen more aggressively with the recently merged distributed ThinLTO
   support

 - Add an optional warning for user-supplied Kconfig values that changed
   after processing, such as out of range values or options that have
   incorrect / missing dependencies

* tag 'kbuild-7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux:
  kconfig: add optional warnings for changed input values
  modpost: Ignore Clang LTO suffixes in symbol matching
  kbuild: Use ld.lld for linking host programs when LLVM is set