linux-stable.git/tools/objtool, branch linux-6.19.y Linux kernel stable tree x86-64: rename misleadingly named '__copy_user_nocache()' function 2026-04-22T11:30:50+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-03-30T17:39:09+00:00 d993e1723aa2a085aa0d72e70ea889031fc225b4 commit d187a86de793f84766ea40b9ade7ac60aabbb4fe upstream. This function was a masterclass in bad naming, for various historical reasons. It claimed to be a non-cached user copy. It is literally _neither_ of those things. It's a specialty memory copy routine that uses non-temporal stores for the destination (but not the source), and that does exception handling for both source and destination accesses. Also note that while it works for unaligned targets, any unaligned parts (whether at beginning or end) will not use non-temporal stores, since only words and quadwords can be non-temporal on x86. The exception handling means that it _can_ be used for user space accesses, but not on its own - it needs all the normal "start user space access" logic around it. But typically the user space access would be the source, not the non-temporal destination. That was the original intention of this, where the destination was some fragile persistent memory target that needed non-temporal stores in order to catch machine check exceptions synchronously and deal with them gracefully. Thus that non-descriptive name: one use case was to copy from user space into a non-cached kernel buffer. However, the existing users are a mix of that intended use-case, and a couple of random drivers that just did this as a performance tweak. Some of those random drivers then actively misused the user copying version (with STAC/CLAC and all) to do kernel copies without ever even caring about the exception handling, _just_ for the non-temporal destination. Rename it as a first small step to actually make it halfway sane, and change the prototype to be more normal: it doesn't take a user pointer unless the caller has done the proper conversion, and the argument size is the full size_t (it still won't actually copy more than 4GB in one go, but there's also no reason to silently truncate the size argument in the caller). Finally, use this now sanely named function in the NTB code, which mis-used a user copy version (with STAC/CLAC and all) of this interface despite it not actually being a user copy at all. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d187a86de793f84766ea40b9ade7ac60aabbb4fe upstream.

This function was a masterclass in bad naming, for various historical
reasons.

It claimed to be a non-cached user copy.  It is literally _neither_ of
those things.  It's a specialty memory copy routine that uses
non-temporal stores for the destination (but not the source), and that
does exception handling for both source and destination accesses.

Also note that while it works for unaligned targets, any unaligned parts
(whether at beginning or end) will not use non-temporal stores, since
only words and quadwords can be non-temporal on x86.

The exception handling means that it _can_ be used for user space
accesses, but not on its own - it needs all the normal "start user space
access" logic around it.

But typically the user space access would be the source, not the
non-temporal destination.  That was the original intention of this,
where the destination was some fragile persistent memory target that
needed non-temporal stores in order to catch machine check exceptions
synchronously and deal with them gracefully.

Thus that non-descriptive name: one use case was to copy from user space
into a non-cached kernel buffer.  However, the existing users are a mix
of that intended use-case, and a couple of random drivers that just did
this as a performance tweak.

Some of those random drivers then actively misused the user copying
version (with STAC/CLAC and all) to do kernel copies without ever even
caring about the exception handling, _just_ for the non-temporal
destination.

Rename it as a first small step to actually make it halfway sane, and
change the prototype to be more normal: it doesn't take a user pointer
unless the caller has done the proper conversion, and the argument size
is the full size_t (it still won't actually copy more than 4GB in one
go, but there's also no reason to silently truncate the size argument in
the caller).

Finally, use this now sanely named function in the NTB code, which
mis-used a user copy version (with STAC/CLAC and all) of this interface
despite it not actually being a user copy at all.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
objtool/klp: fix mkstemp() failure with long paths 2026-04-11T12:29:21+00:00 Joe Lawrence joe.lawrence@redhat.com 2026-03-10T20:37:41+00:00 3362980d8e02aa6e7d35fc7b2322fa8d84f7c25c [ Upstream commit 28e367a969b0c54c87ca655ec180715fe469fd14 ] The elf_create_file() function fails with EINVAL when the build directory path is long enough to truncate the "XXXXXX" suffix in the 256-byte tmp_name buffer. Simplify the code to remove the unnecessary dirname()/basename() split and concatenation. Instead, allocate the exact number of bytes needed for the path. Acked-by: Song Liu <song@kernel.org> Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com> Link: https://patch.msgid.link/20260310203751.1479229-3-joe.lawrence@redhat.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 28e367a969b0c54c87ca655ec180715fe469fd14 ]

The elf_create_file() function fails with EINVAL when the build directory
path is long enough to truncate the "XXXXXX" suffix in the 256-byte
tmp_name buffer.

Simplify the code to remove the unnecessary dirname()/basename() split
and concatenation.  Instead, allocate the exact number of bytes needed for
the path.

Acked-by: Song Liu <song@kernel.org>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Link: https://patch.msgid.link/20260310203751.1479229-3-joe.lawrence@redhat.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
objtool: Fix Clang jump table detection 2026-04-11T12:29:21+00:00 Josh Poimboeuf jpoimboe@kernel.org 2026-03-09T16:03:05+00:00 9f201c9722a9517d1b5d1242c2e3735b5aa924f6 [ Upstream commit 4e5019216402ad0b4a84cff457b662d26803f103 ] With Clang, there can be a conditional forward jump between the load of the jump table address and the indirect branch. Fixes the following warning: vmlinux.o: warning: objtool: ___bpf_prog_run+0x1c5: sibling call from callable instruction with modified stack frame Reported-by: Arnd Bergmann <arnd@arndb.de> Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com Link: https://patch.msgid.link/7d8600caed08901b6679767488acd639f6df9688.1773071992.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 4e5019216402ad0b4a84cff457b662d26803f103 ]

With Clang, there can be a conditional forward jump between the load of
the jump table address and the indirect branch.

Fixes the following warning:

  vmlinux.o: warning: objtool: ___bpf_prog_run+0x1c5: sibling call from callable instruction with modified stack frame

Reported-by: Arnd Bergmann <arnd@arndb.de>
Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com
Link: https://patch.msgid.link/7d8600caed08901b6679767488acd639f6df9688.1773071992.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
objtool: Handle Clang RSP musical chairs 2026-04-02T11:25:21+00:00 Josh Poimboeuf jpoimboe@kernel.org 2026-03-06T17:35:06+00:00 0702339ec6f10849408deb29660a1f5389cf8cbd [ Upstream commit 7fdaa640c810cb42090a182c33f905bcc47a616a ] For no apparent reason (possibly related to CONFIG_KMSAN), Clang can randomly pass the value of RSP to other registers and then back again to RSP. Handle that accordingly. Fixes the following warnings: drivers/input/misc/uinput.o: warning: objtool: uinput_str_to_user+0x165: undefined stack state drivers/input/misc/uinput.o: warning: objtool: uinput_str_to_user+0x165: unknown CFA base reg -1 Reported-by: Arnd Bergmann <arnd@arndb.de> Closes: https://lore.kernel.org/90956545-2066-46e3-b547-10c884582eb0@app.fastmail.com Link: https://patch.msgid.link/240e6a172cc73292499334a3724d02ccb3247fc7.1772818491.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 7fdaa640c810cb42090a182c33f905bcc47a616a ]

For no apparent reason (possibly related to CONFIG_KMSAN), Clang can
randomly pass the value of RSP to other registers and then back again to
RSP.  Handle that accordingly.

Fixes the following warnings:

  drivers/input/misc/uinput.o: warning: objtool: uinput_str_to_user+0x165: undefined stack state
  drivers/input/misc/uinput.o: warning: objtool: uinput_str_to_user+0x165: unknown CFA base reg -1

Reported-by: Arnd Bergmann <arnd@arndb.de>
Closes: https://lore.kernel.org/90956545-2066-46e3-b547-10c884582eb0@app.fastmail.com
Link: https://patch.msgid.link/240e6a172cc73292499334a3724d02ccb3247fc7.1772818491.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
objtool/klp: Disable unsupported pr_debug() usage 2026-04-02T11:25:21+00:00 Josh Poimboeuf jpoimboe@kernel.org 2026-02-10T21:50:10+00:00 b078f3c67137b8ffb91c65c9ebff04d348757161 [ Upstream commit e476bb277cf91b7ac3ea803ec78a4f0791bddec3 ] Instead of erroring out on unsupported pr_debug() (e.g., when patching a module), issue a warning and make it inert, similar to how unsupported tracepoints are currently handled. Reviewed-and-tested-by: Song Liu <song@kernel.org> Link: https://patch.msgid.link/3a7db3a5b7d4abf9b2534803a74e2e7231322738.1770759954.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e476bb277cf91b7ac3ea803ec78a4f0791bddec3 ]

Instead of erroring out on unsupported pr_debug() (e.g., when patching a
module), issue a warning and make it inert, similar to how unsupported
tracepoints are currently handled.

Reviewed-and-tested-by: Song Liu <song@kernel.org>
Link: https://patch.msgid.link/3a7db3a5b7d4abf9b2534803a74e2e7231322738.1770759954.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
objtool: Use HOSTCFLAGS for HAVE_XXHASH test 2026-04-02T11:25:20+00:00 HONG Yifan elsk@google.com 2026-03-03T01:03:39+00:00 1786b6847e9061875f26a6124e1ca6e2d91fdd66 [ Upstream commit 32234049107d012703d50547e815f198f147968b ] Previously, HAVE_XXHASH is tested by invoking HOSTCC without HOSTCFLAGS. Consider the following scenario: - The host machine has libxxhash installed - We build the kernel with HOSTCFLAGS containing a --sysroot that does not have xxhash.h (for hermetic builds) In this case, HAVE_XXHASH is set to y, but when it builds objtool with HOSTCFLAGS, because the --sysroot does not contain xxhash.h, the following error is raised: <...>/common/tools/objtool/include/objtool/checksum_types.h:12:10: fatal error: 'xxhash.h' file not found 12 | #include <xxhash.h> | ^~~~~~~~~~ To resolve the error, we test HAVE_XXHASH by invoking HOSTCC with HOSTCFLAGS. Signed-off-by: HONG Yifan <elsk@google.com> Reviewed-by: Carlos Llamas <cmllamas@google.com> Link: https://patch.msgid.link/20260303010340.306164-1-elsk@google.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 32234049107d012703d50547e815f198f147968b ]

Previously, HAVE_XXHASH is tested by invoking HOSTCC without HOSTCFLAGS.

Consider the following scenario:

- The host machine has libxxhash installed
- We build the kernel with HOSTCFLAGS containing a --sysroot that does
  not have xxhash.h (for hermetic builds)

In this case, HAVE_XXHASH is set to y, but when it builds objtool with
HOSTCFLAGS, because the --sysroot does not contain xxhash.h, the
following error is raised:

<...>/common/tools/objtool/include/objtool/checksum_types.h:12:10: fatal error: 'xxhash.h' file not found
   12 | #include <xxhash.h>
      |          ^~~~~~~~~~

To resolve the error, we test HAVE_XXHASH by invoking HOSTCC with
HOSTCFLAGS.

Signed-off-by: HONG Yifan <elsk@google.com>
Reviewed-by: Carlos Llamas <cmllamas@google.com>
Link: https://patch.msgid.link/20260303010340.306164-1-elsk@google.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
objtool/klp: fix data alignment in __clone_symbol() 2026-04-02T11:25:13+00:00 Joe Lawrence joe.lawrence@redhat.com 2026-03-10T20:37:40+00:00 06164b31605429f3b1d820c93a3c0450980e3d4e [ Upstream commit 2f2600decb3004938762a3f2d0eba3ea9e01045b ] Commit 356e4b2f5b80 ("objtool: Fix data alignment in elf_add_data()") corrected the alignment of data within a section (honoring the section's sh_addralign). Apply the same alignment when klp-diff mode clones a symbol, adjusting the new symbol's offset for the output section's sh_addralign. Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files") Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com> Link: https://patch.msgid.link/20260310203751.1479229-2-joe.lawrence@redhat.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2f2600decb3004938762a3f2d0eba3ea9e01045b ]

Commit 356e4b2f5b80 ("objtool: Fix data alignment in elf_add_data()")
corrected the alignment of data within a section (honoring the section's
sh_addralign).  Apply the same alignment when klp-diff mode clones a
symbol, adjusting the new symbol's offset for the output section's
sh_addralign.

Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Link: https://patch.msgid.link/20260310203751.1479229-2-joe.lawrence@redhat.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
objtool: Fix another stack overflow in validate_branch() 2026-03-19T15:15:07+00:00 Josh Poimboeuf jpoimboe@kernel.org 2026-03-06T18:28:14+00:00 6cf3e0c4cd2f430e66dcbc97cfb9ecfa615936f7 [ 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 <arnd@arndb.de> 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 <jpoimboe@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <arnd@arndb.de>
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 <jpoimboe@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
objtool: Fix data alignment in elf_add_data() 2026-03-19T15:15:07+00:00 Josh Poimboeuf jpoimboe@kernel.org 2026-03-05T03:31:20+00:00 fa31c5b01bb47f155a5e9ecbe8dc9672032b60c8 [ 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 <jpoimboe@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <jpoimboe@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
objtool/klp: Fix detection of corrupt static branch/call entries 2026-03-19T15:15:07+00:00 Josh Poimboeuf jpoimboe@kernel.org 2026-02-10T21:50:09+00:00 0a701ede2dfffbbd16f65fb3e3f3aff31e3dbaf0 [ 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 <song@kernel.org> Reviewed-and-tested-by: Song Liu <song@kernel.org> Link: https://patch.msgid.link/124ad747b751df0df1725eff89de8332e3fb26d6.1770759954.git.jpoimboe@kernel.org Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <song@kernel.org>
Reviewed-and-tested-by: Song Liu <song@kernel.org>
Link: https://patch.msgid.link/124ad747b751df0df1725eff89de8332e3fb26d6.1770759954.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>