linux-stable.git/tools/objtool, branch v7.2.6

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

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

[ Upstream commit d8a2860b4a366bfa8acb3d64da2c546ea26d2091 ]

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
Signed-off-by: Sasha Levin

objtool/klp: Fix .kcfi_traps special section extraction

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

[ Upstream commit 7df1638df97b2aaaff4731b72d4940053257c952 ]

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 
Signed-off-by: Sasha Levin

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

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

[ Upstream commit 6656cf1e975aa152c082012b820efffaebd49979 ]

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 
Signed-off-by: Sasha Levin

objtool/klp: Fix relocations for EXPORT_SYMBOL_FOR_MODULES() symbols

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

[ Upstream commit 4cd3cfb8b54feca89a682720434092a87bfa4967 ]

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 
Signed-off-by: Sasha Levin

objtool/klp: Don't match local symbols against exports

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

[ Upstream commit 86a697572c6271083694025eefa8de518eeef623 ]

While cloning a reloc, klp diff calls find_export() to determine whether
the referenced symbol is exported.  That decides whether the reference
needs a klp reloc, which object the klp symbol belongs to, and whether
the symbol's data needs to be copied into the patch module.

But find_export() matches purely on symbol name, so a static function or
variable which happens to share its name with an export is mistaken for
a reference to that export:

  - klp_reloc_needed() creates a klp reloc pointing at the exporting
    module's symbol rather than the local one.  For a vmlinux export it
    skips the klp reloc altogether, leaving a normal reloc which the
    module loader resolves to the vmlinux symbol.

  - clone_reloc() treats the symbol as external and clones it without
    its data, leaving a dangling reference.

  - validate_special_section_klp_reloc() attributes a static branch or
    call key to the wrong module, and for a vmlinux export skips the
    unsupported-key check entirely.

Exports are always global, so ignore local symbols in find_export().

Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Acked-by: Song Liu 
Acked-by: Joe Lawrence 
Link: https://patch.msgid.link/dafc7c017d1f62e2190a20dc84a52fbfc4c70210.1786138493.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Sasha Levin

objtool/klp: Fix cross-module klp relocation section naming

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

[ Upstream commit 07f14d6af9d7791fdc2b44a3dd0693e42c71d2b8 ]

A klp relocation section is .klp.rela.., where objname
is the object being patched.

klp-build wrongly derives objname from where the referenced symbol
lives, not where it's referenced.  For a cross-module reference like
patched can_isotp code calling can.ko's can_rx_unregister(), that gives
.klp.rela.can..text rather than .klp.rela.can_isotp..text.  Unless the
patch happens to patch can.ko as well, the relocation never gets applied
and the call goes off into the weeds.

Name the intermediate section __klp_relocs. so post-link can
read the patched object's name from there.

Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Reported-by: Joe Lawrence 
Link: https://lore.kernel.org/20260720145658.1103243-2-joe.lawrence@redhat.com
Acked-by: Song Liu 
Acked-by: Joe Lawrence 
Link: https://patch.msgid.link/ee93a08f3e55e76ffa67d04e283917ddaa893f09.1786138493.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Sasha Levin

objtool/klp: Ignore replacement offset of empty x86 alternatives

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

[ Upstream commit 636f230ce21e2730072c58280f1fa0bed4a00eed ]

An x86 alternative with an empty replacement, e.g. the second entry of

  ALTERNATIVE_2("orig", "repl", ft1, "", ft2)

has a replacementlen of zero.  Its replacement offset still gets a
relocation, but the label it points at is the end of the previous
replacement, which is also the beginning of the *next* alternative's
replacement.  The value is meaningless; get_alt_entry() already ignores
it for that reason.

klp diff doesn't ignore it.  When such an alternative belongs to a
changed function, cloning its relocations drags in the unrelated
neighboring replacement, along with everything that replacement
references.  On an x86 clang/lto build an empty alternative in
meminfo_proc_show() pulled in the replacement of an alternative in
proc_kcore_init(), silently emitting a klp relocation against init text
which has long since been freed by the time the patch is applied.

Add arch_alt_ignore_new_reloc() and skip such relocations when cloning.
This has to be arch specific: on arm64 a zero-length replacement instead
identifies an alternative callback, whose replacement offset points at
the callback function and must be preserved.

Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Acked-by: Song Liu 
Acked-by: Joe Lawrence 
Link: https://patch.msgid.link/7a885b70974795c3417f3358869e62aafd4ef783.1786138493.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Sasha Levin

objtool/klp: Fix size of empty special section entries

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

[ Upstream commit 1ea786097cd79522b76cbd41beeb8f84ef3a76f4 ]

create_fake_symbols() sizes each ANNOTATE_DATA_SPECIAL entry from the
offset of the next annotation, falling back to the end of the section
for the last entry.  But the last entry is detected by a zero size,
which also happens for an *empty* entry: ALTERNATIVE(oldinstr, "", ft)
still annotates its zero-length replacement, at the same offset as the
next entry's annotation.

So every empty replacement gets a fake symbol spanning the entire rest
of .altinstr_replacement.  That's harmless today only because
find_symbol_containing() picks the smaller of two overlapping symbols.

Track whether a next annotation was found rather than inferring it from
the size.  A zero-length fake symbol is fine: find_symbol_containing()
skips those, so the properly sized symbol at the same offset still wins.

Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Acked-by: Song Liu 
Acked-by: Joe Lawrence 
Link: https://patch.msgid.link/913e691c5009397df832c7c9a18cd5cf71b42737.1786138493.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Sasha Levin

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

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

[ Upstream commit 3a83d9cd3d0e66c0ef99ce84f972ed26f50c990f ]

Testing klp-build with arm64 produced the following linker error during
the original kernel build:

  `__notrim.1' referenced in section `.klp.symid' of vmlinux.o: defined in discarded section `.no_trim_symbol' of vmlinux.o

symbol_get() puts a static __notrim[] in .no_trim_symbol, which GCC
names __notrim.1, __notrim.2, etc.  Two or more built-in translation
units calling symbol_get() thus produce duplicate names, resulting in
corresponding .klp.symid references which trigger the above error.

Add .no_trim_symbol to the discarded section list so its symbols don't
get symids.

Note this issue is not specific to arm64: it just needs two built-in
symbol_get() callers.  arm64 trips over it easily because it has KVM
always compiled in vmlinux, whereas on x86 it's typically a module.

Fixes: 029223d30162 ("objtool/klp: Add .klp.symid for sympos disambiguation")
Acked-by: Song Liu 
Acked-by: Joe Lawrence 
Link: https://patch.msgid.link/5a3cc4cded743167dd0878220201d80f7e48e5d7.1786138493.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf 
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