Re: [PATCH] perf symbols: ignore livepatch symbols

[sashiko-bot@kernel.org]

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