Re: [PATCH v3 6/9] objtool/klp: Don't match local symbols against exports

[sashiko-bot]

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

Pre-existing issues:
- [High] Unexported global symbols that share a name with an export are incorrectly matched against the global exports list, causing misrouted livepatch relocations.
--

--- Patch [6]: [PATCH v3 6/9] objtool/klp: Don't match local symbols against exports ---
commit 91941e947fdde72be13c7760463244a153a175ce
Author: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>

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

This commit updates find_export() in klp-diff.c to ignore local symbols.
This addresses an issue where static functions or variables that share a
name with an export are incorrectly treated as export references during
livepatch generation.

> diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c
> --- a/tools/objtool/klp-diff.c
> +++ b/tools/objtool/klp-diff.c
> @@ -1101,6 +1101,9 @@ static struct export *find_export(struct symbol *sym)
>  {
>  	struct export *export;
>  
> +	if (is_local_sym(sym))
> +		return NULL;
> +
>  	hash_for_each_possible(exports, export, hash, str_hash(sym->name)) {
>  		if (!strcmp(export->sym, sym->name))
>  			return export;

[Severity: High]
This is a pre-existing issue, but does this still leave unexported global
symbols vulnerable to incorrect matching?

If a module contains an unexported global symbol that shares its name with
an unrelated exported symbol, it will bypass the is_local_sym() check.

When the module is livepatched and klp-diff processes a relocation to this
internal symbol, find_export() will perform a string match and return the
unrelated export. Would this cause a KLP relocation to incorrectly point to
the external module's export instead of the internal symbol?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1786138493.git.jpoimboe@xxxxxxxxxx?part=6