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

From: Josh Poimboeuf

Date: Sat Aug 08 2026 - 18:27:25 EST


On Fri, Aug 07, 2026 at 09:46:11PM +0000, sashiko-bot@xxxxxxxxxx wrote:
> 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?

I'm not convinced this is a realistic scenario (module having a global
symbol with the same name as an exported symbol), but as mentioned it's
a preexisting issue that can be fixed in a followup.

--
Josh