linux.git/kernel/kallsyms.c, branch v6.18.22

kallsyms: prevent module removal when printing module name and buildid

2026-04-11T12:26:50+00:00

commit 3b07086444f80c844351255fd94c2cb0a7224df2 upstream.

kallsyms_lookup_buildid() copies the symbol name into the given buffer so
that it can be safely read anytime later.  But it just copies pointers to
mod->name and mod->build_id which might get reused after the related
struct module gets removed.

The lifetime of struct module is synchronized using RCU.  Take the rcu
read lock for the entire __sprint_symbol().

Link: https://lkml.kernel.org/r/20251128135920.217303-8-pmladek@suse.com
Signed-off-by: Petr Mladek 
Reviewed-by: Aaron Tomlin 
Cc: Alexei Starovoitov 
Cc: Daniel Borkman 
Cc: Daniel Gomez 
Cc: John Fastabend 
Cc: Kees Cook 
Cc: Luis Chamberalin 
Cc: Marc Rutland 
Cc: "Masami Hiramatsu (Google)" 
Cc: Petr Pavlu 
Cc: Sami Tolvanen 
Cc: Steven Rostedt (Google) 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

kallsyms: cleanup code for appending the module buildid

2026-04-11T12:26:50+00:00

commit 8e81dac4cd5477731169b92cff7c24f8f6635950 upstream.

Put the code for appending the optional "buildid" into a helper function,
It makes __sprint_symbol() better readable.

Also print a warning when the "modname" is set and the "buildid" isn't.
It might catch a situation when some lookup function in
kallsyms_lookup_buildid() does not handle the "buildid".

Use pr_*_once() to avoid an infinite recursion when the function is called
from printk().  The recursion is rather theoretical but better be on the
safe side.

Link: https://lkml.kernel.org/r/20251128135920.217303-5-pmladek@suse.com
Signed-off-by: Petr Mladek 
Cc: Aaron Tomlin 
Cc: Alexei Starovoitov 
Cc: Daniel Borkman 
Cc: Daniel Gomez 
Cc: John Fastabend 
Cc: Kees Cook 
Cc: Luis Chamberalin 
Cc: Marc Rutland 
Cc: "Masami Hiramatsu (Google)" 
Cc: Petr Pavlu 
Cc: Sami Tolvanen 
Cc: Steven Rostedt (Google) 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

kallsyms: clean up modname and modbuildid initialization in kallsyms_lookup_buildid()

2026-04-11T12:26:50+00:00

commit fda024fb64769e9d6b3916d013c78d6b189129f8 upstream.

The @modname and @modbuildid optional return parameters are set only when
the symbol is in a module.

Always initialize them so that they do not need to be cleared when the
module is not in a module.  It simplifies the logic and makes the code
even slightly more safe.

Note that bpf_address_lookup() function will get updated in a separate
patch.

Link: https://lkml.kernel.org/r/20251128135920.217303-3-pmladek@suse.com
Signed-off-by: Petr Mladek 
Cc: Aaron Tomlin 
Cc: Alexei Starovoitov 
Cc: Daniel Borkman 
Cc: Daniel Gomez 
Cc: John Fastabend 
Cc: Kees Cook 
Cc: Luis Chamberalin 
Cc: Marc Rutland 
Cc: "Masami Hiramatsu (Google)" 
Cc: Petr Pavlu 
Cc: Sami Tolvanen 
Cc: Steven Rostedt (Google) 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

kallsyms: clean up @namebuf initialization in kallsyms_lookup_buildid()

2026-04-11T12:26:50+00:00

commit 426295ef18c5d5f0b7f75ac89d09022fcfafd25c upstream.

Patch series "kallsyms: Prevent invalid access when showing module
buildid", v3.

We have seen nested crashes in __sprint_symbol(), see below.  They seem to
be caused by an invalid pointer to "buildid".  This patchset cleans up
kallsyms code related to module buildid and fixes this invalid access when
printing backtraces.

I made an audit of __sprint_symbol() and found several situations
when the buildid might be wrong:

  + bpf_address_lookup() does not set @modbuildid

  + ftrace_mod_address_lookup() does not set @modbuildid

  + __sprint_symbol() does not take rcu_read_lock and
    the related struct module might get removed before
    mod->build_id is printed.

This patchset solves these problems:

  + 1st, 2nd patches are preparatory
  + 3rd, 4th, 6th patches fix the above problems
  + 5th patch cleans up a suspicious initialization code.

This is the backtrace, we have seen. But it is not really important.
The problems fixed by the patchset are obvious:

  crash64> bt [62/2029]
  PID: 136151 TASK: ffff9f6c981d4000 CPU: 367 COMMAND: "btrfs"
  #0 [ffffbdb687635c28] machine_kexec at ffffffffb4c845b3
  #1 [ffffbdb687635c80] __crash_kexec at ffffffffb4d86a6a
  #2 [ffffbdb687635d08] hex_string at ffffffffb51b3b61
  #3 [ffffbdb687635d40] crash_kexec at ffffffffb4d87964
  #4 [ffffbdb687635d50] oops_end at ffffffffb4c41fc8
  #5 [ffffbdb687635d70] do_trap at ffffffffb4c3e49a
  #6 [ffffbdb687635db8] do_error_trap at ffffffffb4c3e6a4
  #7 [ffffbdb687635df8] exc_stack_segment at ffffffffb5666b33
  #8 [ffffbdb687635e20] asm_exc_stack_segment at ffffffffb5800cf9
  ...


This patch (of 7)

The function kallsyms_lookup_buildid() initializes the given @namebuf by
clearing the first and the last byte.  It is not clear why.

The 1st byte makes sense because some callers ignore the return code and
expect that the buffer contains a valid string, for example:

  - function_stat_show()
    - kallsyms_lookup()
      - kallsyms_lookup_buildid()

The initialization of the last byte does not make much sense because it
can later be overwritten.  Fortunately, it seems that all called functions
behave correctly:

  -  kallsyms_expand_symbol() explicitly adds the trailing '\0'
     at the end of the function.

  - All *__address_lookup() functions either use the safe strscpy()
    or they do not touch the buffer at all.

Document the reason for clearing the first byte.  And remove the useless
initialization of the last byte.

Link: https://lkml.kernel.org/r/20251128135920.217303-2-pmladek@suse.com
Signed-off-by: Petr Mladek 
Reviewed-by: Aaron Tomlin 
Cc: Alexei Starovoitov 
Cc: Daniel Borkman 
Cc: John Fastabend 
Cc: Kees Cook 
Cc: Luis Chamberalin 
Cc: Marc Rutland 
Cc: "Masami Hiramatsu (Google)" 
Cc: Petr Pavlu 
Cc: Sami Tolvanen 
Cc: Steven Rostedt 
Cc: Daniel Gomez 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

kallsyms/ftrace: set module buildid in ftrace_mod_address_lookup()

2026-02-26T22:59:17+00:00

[ Upstream commit e8a1e7eaa19d0b757b06a2f913e3eeb4b1c002c6 ]

__sprint_symbol() might access an invalid pointer when
kallsyms_lookup_buildid() returns a symbol found by
ftrace_mod_address_lookup().

The ftrace lookup function must set both @modname and @modbuildid the same
way as module_address_lookup().

Link: https://lkml.kernel.org/r/20251128135920.217303-7-pmladek@suse.com
Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces")
Signed-off-by: Petr Mladek 
Reviewed-by: Aaron Tomlin 
Acked-by: Steven Rostedt (Google) 
Cc: Alexei Starovoitov 
Cc: Daniel Borkman 
Cc: Daniel Gomez 
Cc: John Fastabend 
Cc: Kees Cook 
Cc: Luis Chamberalin 
Cc: Marc Rutland 
Cc: "Masami Hiramatsu (Google)" 
Cc: Petr Pavlu 
Cc: Sami Tolvanen 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin

kallsyms/bpf: rename __bpf_address_lookup() to bpf_address_lookup()

2026-02-26T22:59:17+00:00

[ Upstream commit cd6735896d0343942cf3dafb48ce32eb79341990 ]

bpf_address_lookup() has been used only in kallsyms_lookup_buildid().  It
was supposed to set @modname and @modbuildid when the symbol was in a
module.

But it always just cleared @modname because BPF symbols were never in a
module.  And it did not clear @modbuildid because the pointer was not
passed.

The wrapper is no longer needed.  Both @modname and @modbuildid are now
always initialized to NULL in kallsyms_lookup_buildid().

Remove the wrapper and rename __bpf_address_lookup() to
bpf_address_lookup() because this variant is used everywhere.

[akpm@linux-foundation.org: fix loongarch]
Link: https://lkml.kernel.org/r/20251128135920.217303-6-pmladek@suse.com
Fixes: 9294523e3768 ("module: add printk formats to add module build ID to stacktraces")
Signed-off-by: Petr Mladek 
Acked-by: Alexei Starovoitov 
Cc: Aaron Tomlin 
Cc: Daniel Borkman 
Cc: Daniel Gomez 
Cc: John Fastabend 
Cc: Kees Cook 
Cc: Luis Chamberalin 
Cc: Marc Rutland 
Cc: "Masami Hiramatsu (Google)" 
Cc: Petr Pavlu 
Cc: Sami Tolvanen 
Cc: Steven Rostedt (Google) 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin

kallsyms: Fix wrong "big" kernel symbol type read from procfs

2026-01-02T11:57:09+00:00

commit f3f9f42232dee596d15491ca3f611d02174db49c upstream.

Currently when the length of a symbol is longer than 0x7f characters,
its type shown in /proc/kallsyms can be incorrect.

I found this issue when reading the code, but it can be reproduced by
following steps:

  1. Define a function which symbol length is 130 characters:

    #define X13(x) x##x##x##x##x##x##x##x##x##x##x##x##x
    static noinline void X13(x123456789)(void)
    {
        printk("hello world\n");
    }

  2. The type in vmlinux is 't':

    $ nm vmlinux | grep x123456
    ffffffff816290f0 t x123456789x123456789x123456789x12[...]

  3. Then boot the kernel, the type shown in /proc/kallsyms becomes 'g'
     instead of the expected 't':

    # cat /proc/kallsyms | grep x123456
    ffffffff816290f0 g x123456789x123456789x123456789x12[...]

The root cause is that, after commit 73bbb94466fd ("kallsyms: support
"big" kernel symbols"), ULEB128 was used to encode symbol name length.
That is, for "big" kernel symbols of which name length is longer than
0x7f characters, the length info is encoded into 2 bytes.

kallsyms_get_symbol_type() expects to read the first char of the
symbol name which indicates the symbol type. However, due to the
"big" symbol case not being handled, the symbol type read from
/proc/kallsyms may be wrong, so handle it properly.

Cc: stable@vger.kernel.org
Fixes: 73bbb94466fd ("kallsyms: support "big" kernel symbols")
Signed-off-by: Zheng Yejian 
Acked-by: Gary Guo 
Link: https://patch.msgid.link/20241011143853.3022643-1-zhengyejian@huaweicloud.com
Signed-off-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

bpf: Clean up individual BTF_ID code

2025-07-17T01:34:42+00:00

Use BTF_ID_LIST_SINGLE(a, b, c) instead of
BTF_ID_LIST(a)
BTF_ID(b, c)

Signed-off-by: Feng Yang 
Link: https://lore.kernel.org/r/20250710055419.70544-1-yangfeng59949@163.com
Signed-off-by: Alexei Starovoitov

kallsyms: Remove KALLSYMS_ABSOLUTE_PERCPU

2025-02-18T09:16:04+00:00

x86-64 was the only user.

Signed-off-by: Brian Gerst 
Signed-off-by: Ingo Molnar 
Reviewed-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Link: https://lore.kernel.org/r/20250123190747.745588-16-brgerst@gmail.com

kallsyms: Match symbols exactly with CONFIG_LTO_CLANG

2024-08-15T16:33:35+00:00

With CONFIG_LTO_CLANG=y, the compiler may add .llvm. suffix to
function names to avoid duplication. APIs like kallsyms_lookup_name()
and kallsyms_on_each_match_symbol() tries to match these symbol names
without the .llvm. suffix, e.g., match "c_stop" with symbol
c_stop.llvm.17132674095431275852. This turned out to be problematic
for use cases that require exact match, for example, livepatch.

Fix this by making the APIs to match symbols exactly.

Also cleanup kallsyms_selftests accordingly.

Signed-off-by: Song Liu 
Fixes: 8cc32a9bbf29 ("kallsyms: strip LTO-only suffixes from promoted global functions")
Tested-by: Masami Hiramatsu (Google) 
Reviewed-by: Masami Hiramatsu (Google) 
Acked-by: Petr Mladek 
Reviewed-by: Sami Tolvanen 
Reviewed-by: Luis Chamberlain 
Link: https://lore.kernel.org/r/20240807220513.3100483-3-song@kernel.org
Signed-off-by: Kees Cook