kernel/git/stable/linux.git/tools/objtool, branch master

Merge tag 'efi-next-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi

2026-08-23T16:24:34+00:00

Pull EFI updates from Ard Biesheuvel: - Set a timeout for EFI runtime service completions, and declare the firmware wedged if it is exceeded. Note that this requires special handling in case the firmware does return after all - Rate limit the efivarfs statfs() handler as the QueryVariableInfo() runtime service can be costly - Sanity check the size of struct properties_header on Mac/x86 - Tweak the prototype of efi_guid_to_str() * tag 'efi-next-for-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efivarfs: Rate limit statfs() handler efi: apple-properties: validate setup data header length efi: make efi_guid_to_str() take a const GUID pointer efi/runtime-wrappers: retire the worker if a wedged call ever returns efi/runtime-wrappers: honour EFI_RUNTIME_SERVICES in the non-blocking paths efi/runtime-wrappers: bound the wait for EFI runtime service calls efi/runtime-wrappers: check EFI_RUNTIME_SERVICES before using efi_rts_work efi/runtime-wrappers: handle queue_work() failure with goto exit efi/runtime-wrappers: factor out efi_rts_park_worker() efi: fix stale reference to efi_recover_from_page_fault()

efi/runtime-wrappers: factor out efi_rts_park_worker()

2026-08-20T11:45:04+00:00

x86's efi_crash_gracefully_on_page_fault() ends in an infinite schedule() loop so the kworker that faulted in firmware never runs efi_rts_wq again. A later change needs the same "park this worker forever" primitive on the runtime service timeout path, so factor the loop into a shared efi_rts_park_worker() and call it from the x86 page-fault handler. No functional change. Signed-off-by: Breno Leitao Signed-off-by: Ard Biesheuvel

Merge tag 'x86_alternatives_for_v7.3_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-19T01:11:25+00:00

Pull x86 alternatives update from Borislav Petkov: - Remove the smp_locks alternatives machinery which was used to patch out lock prefixes when running a SMP kernel on a uniprocessor machine * tag 'x86_alternatives_for_v7.3_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/alternative: Drop smp_locks glue

Merge tag 'objtool-core-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-18T19:18:33+00:00

Pull objtool updates from Ingo Molnar: - Fix various klp-build bugs reported by Joe Lawrence (Josh Poimboeuf, Joe Lawrence) - Misc fixes and cleanups (Puranjay Mohan, Thomas Huth and Ingo Molnar) * tag 'objtool-core-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: objtool/klp: Fix vmlinux klp relocations for EXPORT_SYMBOL_FOR_MODULES() objtool/klp: Fix .kcfi_traps special section extraction objtool/klp: Fix vmlinux .klp.symid link error for .exitcall.exit symbols objtool/klp: Fix line numbers in Module.symvers parse errors objtool/klp: Fix relocations for EXPORT_SYMBOL_FOR_MODULES() symbols objtool/klp: Allow new references to module exports objtool/klp: Don't match local symbols against exports objtool/klp: Fix cross-module klp relocation section naming objtool/klp: Explicitly disallow patching or referencing init code/data objtool/klp: Ignore replacement offset of empty x86 alternatives objtool/klp: Fix size of empty special section entries objtool/klp: Fix vmlinux .klp.symid link error for .no_trim_symbol symbols objtool/headers: Sync tools/include/linux/objtool_types.h with include/linux/objtool_types.h objtool: Replace __ASSEMBLY__ with __ASSEMBLER__ in header files objtool/klp: Fix symbol resolution for duplicate data symbols objtool/klp: Add .klp.symid for sympos disambiguation objtool/klp: Skip hidden directories when finding objects objtool/klp: Fix false module dependencies caused by dead relocs objtool/klp: Normalize Module.symvers paths to module names objtool/klp: Fix module name normalization for paths with dots

objtool/klp: Fix vmlinux klp relocations for EXPORT_SYMBOL_FOR_MODULES()

2026-08-17T08:53:55+00:00

When a module function references a vmlinux symbol which is exported with EXPORT_SYMBOL_FOR_MODULES(), a patch to that function needs to use a klp reloc. Currently, livepatch fails to load such a module: livepatch: invalid access to vmlinux symbol 'get_task_policy' from module-specific livepatch relocation section livepatch: failed to initialize patch 'livepatch_test' for module 'testmod' (-22) livepatch: patch 'livepatch_test' failed for module 'testmod', refusing to load module 'testmod' klp diff puts all klp relocs in __klp_relocs., so post-link names the section .klp.rela.., which the kernel rejects for vmlinux symbols. Commit 07f14d6af9d77 ("objtool/klp: Fix cross-module klp relocation section naming") changed the meaning of objname in the klp rela section name to be where the referenced symbol is referenced rather than where it lives. That premise only holds for symbols in a module: the relocs get applied when the patched module gets patched, and the module dependency guarantees the referenced module is loaded by then. A vmlinux symbol needs the opposite. It's always resolvable, and it has to be applied when the patch module loads, before the module loader initializes the patch module's special sections, which may reference it. That's why livepatch rejects vmlinux symbols in module-specific sections. Use "vmlinux" as the section objname when the referenced symbol lives in vmlinux. This moves such klp relocs from .klp.rela.kvm..text to .klp.rela.vmlinux..text. Fixes: 07f14d6af9d77 ("objtool/klp: Fix cross-module klp relocation section naming") Reported-by: Dylan Hatch Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Acked-by: Song Liu Link: https://patch.msgid.link/f8e3b9fae109903a6aafb2a33310e4afdcebf58e.1786761327.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/CADBMgpz7iWC0=t=_gE-tfvv0mTPq4kg0qQ2zgPH8DVPE6eQ9Kw@mail.gmail.com

objtool/klp: Fix .kcfi_traps special section extraction

2026-08-12T20:52:07+00:00

create_fake_symbols() creates a symbol per entry for special sections. It does so in two steps: first for the sections which have ANNOTATE_DATA_SPECIAL annotations, then for the rest, using entsize or the reloc count to infer the entry size. The second step skips the sections already handled by the first one by looking for a symbol at offset 0. That heuristic is too fuzzy: with Clang and CONFIG_CFI, it misfires on .kcfi_traps because Clang emits a .Ltmp* assembler-local label at the start of the section, so no symbols are created and clone_special_sections() extracts nothing. klp-build still reports SUCCESS, but the livepatch module has no __kcfi_traps section and the traps for the patched functions are lost. Look for the actual fake symbols created by the first step instead. Fixes: da4326573ae8d ("objtool/klp: Fix kCFI trap handling") Reported-by: Joe Lawrence Closes: https://lore.kernel.org/r/akQNqlfFC0T5pcMa@redhat.com Acked-by: Song Liu Link: https://patch.msgid.link/8faaead205b219607b6fc2359ae743be824056eb.1786230311.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf

objtool/klp: Fix vmlinux .klp.symid link error for .exitcall.exit symbols

2026-08-12T20:33:32+00:00

Building a kernel via klp-build fails to link: `__exitcall_aes_mod_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o `__exitcall_dax_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o `__exitcall_hid_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o `__exitcall_usb_serial_module_exit' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.exitcall.exit' of vmlinux.o module_exit() on a built-in emits a static __exitcall_$fn pointer into .exitcall.exit, which vmlinux.lds.h discards unconditionally via EXIT_CALL. When two built-in translation units define a module_exit() function of the same name, the resulting local symbols collide, symid_needed() sees a duplicate and emits a .klp.symid entry for each, referencing symbols the linker then throws away. Same-named module_exit() functions are not rare: dax_exit drivers/dax/device.c, drivers/dax/fsdev.c hid_exit drivers/hid/hid-core.c, drivers/hid/usbhid/hid-core.c aes_mod_exit arch/arm64/crypto/aes-ce-ccm-glue.c, lib/crypto/aes.c usb_serial_module_exit module_usb_serial_driver() expands to this fixed name in each of its ~49 users The last one makes the collision structural rather than accidental: any kernel with two built-in USB serial drivers has it. This is not arch specific either; it only requires the objects to be built in rather than modular, which is why a monolithic config trips it while a typical distro config does not. Add .exitcall.exit to the discarded section list so its symbols don't get symids. This is the same failure mode as "objtool/klp: Fix vmlinux .klp.symid link error for .no_trim_symbol symbols", for another unconditionally discarded allocated section. Fixes: 029223d30162 ("objtool/klp: Add .klp.symid for sympos disambiguation") Signed-off-by: Puranjay Mohan Link: https://patch.msgid.link/m24igzlbxf.fsf@kernel.org Signed-off-by: Josh Poimboeuf

objtool/klp: Fix line numbers in Module.symvers parse errors

2026-08-11T23:10:58+00:00

read_exports() reports the offending line number when it fails to parse Module.symvers. The counter is initialized to 1 but never incremented, so every error blames line 1 regardless of where the bad line is. Acked-by: Joe Lawrence Acked-by: Song Liu Link: https://patch.msgid.link/133e16bb0c7cb916f10bbfb017eba525449ad1d6.1786138493.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf

objtool/klp: Fix relocations for EXPORT_SYMBOL_FOR_MODULES() symbols

2026-08-11T23:10:51+00:00

EXPORT_SYMBOL_FOR_MODULES() puts a symbol in a "module:" namespace, which the module loader grants access to by matching the importing module's name against that list. klp_reloc_needed() only creates a klp reloc for module-owned exports; a vmlinux export gets a normal reloc. For a vmlinux symbol exported with EXPORT_SYMBOL_FOR_MODULES(), using a normal reloc results in a modpost failure in klp-build: ERROR: modpost: module livepatch-foo uses symbol mpol_shared_policy_lookup from namespace module:kvm, but does not import it. And the modpost error is correct: even with that error removed, the patch module would fail to load: livepatch_foo: module uses symbol (mpol_shared_policy_lookup) from namespace module:kvm, but does not import it. livepatch_foo: Unknown symbol mpol_shared_policy_lookup (err -22) Treat it like an unexported symbol by using a klp reloc. Note this only affects "module:" namespaces. Ordinary namespaced exports continue to work with normal relocs thanks to copy_import_ns(), which propagates the patched object's import_ns tags to the patch module. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Reported-by: Joe Lawrence Link: https://lore.kernel.org/6a6608f4-0a05-4d75-8b7f-edddfac9c5d4@redhat.com Acked-by: Joe Lawrence Acked-by: Song Liu Link: https://patch.msgid.link/fe5a00818e06ec613344d41d5944de054fcd8832.1786138493.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf

objtool/klp: Allow new references to module exports

2026-08-11T23:10:51+00:00

klp_reloc_needed() returns true for module exports to support late-module patching. However, clone_reloc_klp() unconditionally rejects symbols without a twin (i.e., new references added by the patch), even when the symbol is a known export from Module.symvers. Relax the check: allow new references to exported symbols by only erroring on !twin when there is no export. The export metadata from Module.symvers provides sufficient context to emit the klp-relocation without a twin. For a module export that isn't sufficient on its own though, as the resulting klp relocation will only be resolved at patch-enable time if the exporting module is loaded. If the original (unpatched) module already depends on the exporting module, the dependency is safe: the module loader ensures the dependency is satisfied before the patched module can be loaded, so the klp relocation target will exist. However, if the patch introduces a reference to a module that the original doesn't depend on, there is no such guarantee. The exporting module could be absent or could be unloaded at any time, leading to a relocation failure or use-after-free. So also add a build-time check: when a new symbol reference (no twin) targets a module export, verify that the original module already has at least one UNDEF symbol resolving to that same exporting module. If not, error out with a diagnostic message. Signed-off-by: Joe Lawrence Acked-by: Song Liu Acked-by: Joe Lawrence Link: https://patch.msgid.link/e0d725acb4774747f0e271308b4ca33daae2d5db.1786138493.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf