[PATCH] perf symbols: ignore livepatch symbols

[PATCH] perf symbols: ignore livepatch symbols

[Joe Lawrence]

Livepatch modules contain special symbols (prefixed by ".klp.sym.") that
act as relocation placeholders.  Once resolved, they point to the same
addresses as the original kernel symbols they reference. [1]

These special symbols confuse the 'vmlinux symtab matches kallsyms' perf
test as kallsyms may report multiple symbols sharing a single kernel
address.  For example:

  kallsyms (without livepatch)
  ----------------------------
  ffffffff81a41110 T __pfx_arch_release_task_struct
> ffffffff81a41120 T arch_release_task_struct
  ffffffff81a41140 T __pfx_exit_thread
  ffffffff81a41150 T exit_thread

  kallsyms (with livepatch loaded)
  ---------------------------------
  ffffffff81a41110 T __pfx_arch_release_task_struct
> ffffffff81a41120 T arch_release_task_struct
  ffffffff81a41140 T __pfx_exit_thread
  ffffffff81a41150 T exit_thread
> ffffffff81a41120 w .klp.sym.vmlinux.arch_release_task_struct,0  [kpatch_5_14_0_570_94_1_1_3]

When perf loads kallsyms, both symbols are inserted into the
symbol table at the same address, corrupting symbol end-address
calculations and causing test failures.

Filter out symbols prefixed with ".klp.sym." when loading kallsyms, as
they alias existing kernel symbols.

Link: https://docs.kernel.org/livepatch/module-elf-format.html#livepatch-symbols [1]
Reported-and-tested-by: Ben Procknow <bprockno@redhat.com>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
---
 tools/perf/util/symbol.c | 4 ++++
 1 file changed, 4 insertions(+)

From Ben's tests:

  Without patch:
  ./tools/perf/perf test 1
   1: vmlinux symtab matches kallsyms                                 : FAILED!

  With patch:
  ./tools/perf/perf test 1
   1: vmlinux symtab matches kallsyms                                 : Ok

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index fcaeeddbbb6b..eeaed3f5cf50 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -774,6 +774,10 @@ static int map__process_kallsym_symbol(void *arg, const char *name,
 	if (name[0] == '$')
 		return 0;
 
+	/* Ignore livepatch symbols */
+	if (strstarts(name, ".klp.sym."))
+		return 0;
+
 	/*
 	 * module symbols are not sorted so we add all
 	 * symbols, setting length to 0, and rely on
-- 
2.54.0

Re: [PATCH] perf symbols: ignore livepatch symbols

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Out-of-bounds write of a null terminator in kallsyms__parse() stack array.
- [High] Livepatch symbols (.klp.sym.*) corrupt module boundaries in kcore_copy, leading to silently omitted module memory and bogus mappings.
--

commit 2ebd0b4f62f44ca82022b5aeb4aaa75ac016e938
Author: Joe Lawrence <joe.lawrence@redhat.com>

    perf symbols: ignore livepatch symbols
    
    Livepatch modules contain special symbols (prefixed by ".klp.sym.") that
    act as relocation placeholders. Once resolved, they point to the same
    addresses as the original kernel symbols they reference. These special
    symbols confuse the 'vmlinux symtab matches kallsyms' perf test as
    kallsyms may report multiple symbols sharing a single kernel address.
    
    Link: https://docs.kernel.org/livepatch/module-elf-format.html#livepatch-symbols [1]

> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index fcaeeddbbb6b9..eeaed3f5cf50d 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -774,6 +774,10 @@ static int map__process_kallsym_symbol(void *arg, const char *name,
>  	if (name[0] == '$')
>  		return 0;
>  
> +	/* Ignore livepatch symbols */
> +	if (strstarts(name, ".klp.sym."))
> +		return 0;
> +

[Severity: High]
This isn't a bug introduced by this patch, but does kcore_copy__process_kallsyms()
need a similar filter for livepatch symbols?

Livepatch symbols contain a module name bracket (e.g., "[kpatch...]") but
their address points to the core kernel space. In symbol-elf.c, this appears
to trick the module boundary tracking:

tools/perf/util/symbol-elf.c:kcore_copy__process_kallsyms() {
    ...
	if (strchr(name, '[')) {
		if (!kci->first_module_symbol || start < kci->first_module_symbol)
			kci->first_module_symbol = start;
		if (start > kci->last_module_symbol)
			kci->last_module_symbol = start;
		return 0;
	}
    ...
}

Because the livepatch symbol address is in the core kernel range, does this
incorrectly lower kci->first_module_symbol to the core kernel address space
instead of the module vmalloc space, omitting module memory and creating a
bogus mapping?


[Severity: Critical]
This is a pre-existing issue, but while reviewing the kallsyms parsing I
noticed a potential out-of-bounds write when reading symbol names:

tools/lib/symbol/kallsyms.c:kallsyms__parse() {
    ...
		char symbol_name[KSYM_NAME_LEN + 1];

		[ ... ]

		for (i = 0; i < sizeof(symbol_name); i++) {
			ch = io__get_char(&io);
			if (ch < 0 || ch == '\n')
				break;
			symbol_name[i]  = ch;
		}
		symbol_name[i]  = '\0';
    ...
}

If a symbol name in kallsyms is longer than KSYM_NAME_LEN characters and
doesn't have a newline or EOF, the loop increments i up to sizeof(symbol_name)
(which is KSYM_NAME_LEN + 1). When the loop terminates without breaking, it
writes '\0' at symbol_name[sizeof(symbol_name)], which is one byte past the
end of the array.

Can this corrupt the stack if an untrusted user provides a crafted --kallsyms
file to perf?

>  	/*
>  	 * module symbols are not sorted so we add all
>  	 * symbols, setting length to 0, and rely on

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260624201254.472576-1-joe.lawrence@redhat.com?part=1