kernel/tools/objtool, branch linux-6.19.y

objtool: Fix another stack overflow in validate_branch()

2026-03-19T15:15:07Z

[ Upstream commit 9a73f085dc91980ab7fcc5e9716f4449424b3b59 ] The insn state is getting saved on the stack twice for each recursive iteration. No need for that, once is enough. Fixes the following reported stack overflow: drivers/scsi/qla2xxx/qla_dbg.o: error: SIGSEGV: objtool stack overflow! Segmentation fault Fixes: 70589843b36f ("objtool: Add option to trace function validation") Reported-by: Arnd Bergmann Closes: https://lore.kernel.org/90956545-2066-46e3-b547-10c884582eb0@app.fastmail.com Link: https://patch.msgid.link/8b97f62d083457f3b0a29a424275f7957dd3372f.1772821683.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin

objtool: Fix data alignment in elf_add_data()

2026-03-19T15:15:07Z

[ Upstream commit 356e4b2f5b80f757965f3f4d0219c81fca91b6f2 ] Any data added to a section needs to be aligned in accordance with the section's sh_addralign value. Particularly strings added to a .str1.8 section. Otherwise you may get some funky strings. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Link: https://patch.msgid.link/d962fc0ca24fa0825cca8dad71932dccdd9312a9.1772681234.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin

objtool/klp: Fix detection of corrupt static branch/call entries

2026-03-19T15:15:07Z

[ Upstream commit f9fb44b0ecefc1f218db56661ed66d4e8d67317d ] Patching a function which references a static key living in a kernel module is unsupported due to ordering issues inherent to late module patching: 1) Load a livepatch module which has a __jump_table entry which needs a klp reloc to reference static key K which lives in module M. 2) The __jump_table klp reloc does *not* get resolved because module M is not yet loaded. 3) jump_label_add_module() corrupts memory (or causes a panic) when dereferencing the uninitialized pointer to key K. validate_special_section_klp_reloc() intends to prevent that from ever happening by catching it at build time. However, it incorrectly assumes the special section entry's reloc symbol references have already been converted from section symbols to object symbols, causing the validation to miss corruption in extracted static branch/call table entries. Make sure the references have been properly converted before doing the validation. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Reported-by: Song Liu Reviewed-and-tested-by: Song Liu Link: https://patch.msgid.link/124ad747b751df0df1725eff89de8332e3fb26d6.1770759954.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin

kbuild: Leave objtool binary around with 'make clean'

2026-03-12T11:09:39Z

commit fdb12c8a24a453bdd6759979b6ef1e04ebd4beb4 upstream. The difference between 'make clean' and 'make mrproper' is documented in 'make help' as: clean - Remove most generated files but keep the config and enough build support to build external modules mrproper - Remove all generated files + config + various backup files After commit 68b4fe32d737 ("kbuild: Add objtool to top-level clean target"), running 'make clean' then attempting to build an external module with the resulting build directory fails with $ make ARCH=x86_64 O=build clean $ make -C build M=... MO=... ... /bin/sh: line 1: .../build/tools/objtool/objtool: No such file or directory as 'make clean' removes the objtool binary. Split the objtool clean target into mrproper and clean like Kbuild does and remove all generated artifacts with 'make clean' except for the objtool binary, which is removed with 'make mrproper'. To avoid a small race when running the objtool clean target through both objtool_mrproper and objtool_clean when running 'make mrproper', modify objtool's clean up find command to avoid using find's '-delete' command by piping the files into 'xargs rm -f' like the rest of Kbuild does. Cc: stable@vger.kernel.org Fixes: 68b4fe32d737 ("kbuild: Add objtool to top-level clean target") Reported-by: Michal Suchanek Closes: https://lore.kernel.org/20260225112633.6123-1-msuchanek@suse.de/ Reported-by: Rainer Fiebig Closes: https://lore.kernel.org/62d12399-76e5-3d40-126a-7490b4795b17@mailbox.org/ Acked-by: Josh Poimboeuf Acked-by: Peter Zijlstra (Intel) Reviewed-by: Nicolas Schier Tested-by: Nicolas Schier Link: https://patch.msgid.link/20260227-avoid-objtool-binary-removal-clean-v1-1-122f3e55eae9@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman

objtool/rust: add one more `noreturn` Rust function

2026-03-04T12:19:29Z

[ Upstream commit c431b00ca6afc5da3133636ecc34ee7edd38d6cc ] `objtool` with Rust 1.84.0 reports: rust/kernel.o: error: objtool: _RNvXNtNtCsaRPFapPOzLs_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix14from_str_radix() falls through to next function _RNvXNtNtCsaRPFapPOzLs_6kernel3str9parse_intaNtNtB2_7private12FromStrRadix16from_u64_negated() This is very similar to commit c18f35e49049 ("objtool/rust: add one more `noreturn` Rust function"), which added `from_ascii_radix_panic` for Rust 1.86.0, except that Rust 1.84.0 ends up needing `from_str_radix_panic`. Thus add it to the list to fix the warning. Cc: FUJITA Tomonori Fixes: 51d9ee90ea90 ("rust: str: add radix prefixed integer parsing functions") Reported-by: Alice Ryhl Link: https://rust-for-linux.zulipchat.com/#narrow/channel/291565/topic/x/with/572427627 Tested-by: Alice Ryhl Link: https://patch.msgid.link/20260206204336.38462-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin

kbuild: Add objtool to top-level clean target

2026-02-26T23:01:28Z

[ Upstream commit 68b4fe32d73789dea23e356f468de67c8367ef8f ] Objtool is an integral part of the build, make sure it gets cleaned by "make clean" and "make mrproper". Fixes: 442f04c34a1a ("objtool: Add tool to perform compile-time stack metadata validation") Reported-by: Jens Remus Closes: https://lore.kernel.org/15f2af3b-be33-46fc-b972-6b8e7e0aa52e@linux.ibm.com Signed-off-by: Josh Poimboeuf Tested-by: Jens Remus Link: https://patch.msgid.link/968faf2ed30fa8b3519f79f01a1ecfe7929553e5.1770759919.git.jpoimboe@kernel.org [nathan: use Closes: instead of Link: per checkpatch.pl] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin

Merge tag 'objtool-urgent-2026-02-07' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-02-07T16:21:21Z

Pull objtool fixes from Ingo Molnar:: - Bump up the Clang minimum version requirements for livepatch builds, due to Clang assembler section handling bugs causing silent miscompilations - Strip livepatching symbol artifacts from non-livepatch modules - Fix livepatch build warnings when certain Clang LTO options are enabled - Fix livepatch build error when CONFIG_MEM_ALLOC_PROFILING_DEBUG=y * tag 'objtool-urgent-2026-02-07' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool/klp: Fix unexported static call key access for manually built livepatch modules objtool/klp: Fix symbol correlation for orphaned local symbols livepatch: Free klp_{object,func}_ext data after initialization livepatch: Fix having __klp_objects relics in non-livepatch modules livepatch/klp-build: Require Clang assembler >= 20

objtool/klp: Fix unexported static call key access for manually built livepatch modules

2026-02-05T16:00:45Z

Enabling CONFIG_MEM_ALLOC_PROFILING_DEBUG with CONFIG_SAMPLE_LIVEPATCH results in the following error: samples/livepatch/livepatch-shadow-fix1.o: error: objtool: static_call: can't find static_call_key symbol: __SCK__WARN_trap This is caused an extra file->klp sanity check which was added by commit 164c9201e1da ("objtool: Add base objtool support for livepatch modules"). That check was intended to ensure that livepatch modules built with klp-build always have full access to their static call keys. However, it failed to account for the fact that manually built livepatch modules (i.e., not built with klp-build) might need access to unexported static call keys, for which read-only access is typically allowed for modules. While the livepatch-shadow-fix1 module doesn't explicitly use any static calls, it does have a memory allocation, which can cause CONFIG_MEM_ALLOC_PROFILING_DEBUG to insert a WARN() call. And WARN() is now an unexported static call as of commit 860238af7a33 ("x86_64/bug: Inline the UD1"). Fix it by removing the overzealous file->klp check, restoring the original behavior for manually built livepatch modules. Fixes: 164c9201e1da ("objtool: Add base objtool support for livepatch modules") Reported-by: Arnd Bergmann Acked-by: Song Liu Tested-by: Arnd Bergmann Link: https://patch.msgid.link/0bd3ae9a53c3d743417fe842b740a7720e2bcd1c.1770058775.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf

objtool/klp: Fix symbol correlation for orphaned local symbols

2026-02-05T16:00:45Z

When compiling with CONFIG_LTO_CLANG_THIN, vmlinux.o has __irf_[start|end] before the first FILE entry: $ readelf -sW vmlinux.o Symbol table '.symtab' contains 597706 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000000000 0 NOTYPE LOCAL DEFAULT 18 __irf_start 2: 0000000000000200 0 NOTYPE LOCAL DEFAULT 18 __irf_end 3: 0000000000000000 0 SECTION LOCAL DEFAULT 17 .text 4: 0000000000000000 0 SECTION LOCAL DEFAULT 18 .init.ramfs This causes klp-build warnings like: vmlinux.o: warning: objtool: no correlation: __irf_start vmlinux.o: warning: objtool: no correlation: __irf_end The problem is that Clang LTO is stripping the initramfs_data.o FILE symbol, causing those two symbols to be orphaned and not noticed by klp-diff's correlation logic. Add a loop to correlate any symbols found before the first FILE symbol. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Reported-by: Song Liu Acked-by: Song Liu Link: https://patch.msgid.link/e21ec1141fc749b5f538d7329b531c1ab63a6d1a.1770055235.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf

livepatch: Free klp_{object,func}_ext data after initialization

2026-02-05T16:00:45Z

The klp_object_ext and klp_func_ext data, which are stored in the __klp_objects and __klp_funcs sections, respectively, are not needed after they are used to create the actual klp_object and klp_func instances. This operation is implemented by the init function in scripts/livepatch/init.c. Prefix the two sections with ".init" so they are freed after the module is initializated. Signed-off-by: Petr Pavlu Acked-by: Joe Lawrence Acked-by: Miroslav Benes Reviewed-by: Aaron Tomlin Link: https://patch.msgid.link/20260123102825.3521961-3-petr.pavlu@suse.com Signed-off-by: Josh Poimboeuf