Re: [PATCH v2 1/1] objtool/klp: compute sympos during checksum phase

Josh Poimboeuf <[email protected]> Fri, 24 Jul 2026 17:09:08 -0700
Newsgroups org.kernel.vger.live-patching
Message-ID <upsllhkhwyezml3pnq7fv7j2ulawp3avj4ftoh4hnzu4yieshs@bwnbzzeac3c3>
On Fri, Jul 24, 2026 at 10:27:44PM +0000, [email protected] wrote:
> > +		/* Match our compilation unit's filename against sorted entries */
> > +		sym_file_name = sym->file ? sym->file->name : NULL;
> > +		for (i = 0; i < nr; i++) {
> > +			bool match;
> > +
> > +			if (sym_file_name && entries[i].file_name)
> > +				match = !strcmp(sym_file_name, entries[i].file_name);
> > +			else if (!sym_file_name && !entries[i].file_name)
> > +				match = true;
> > +			else
> > +				match = false;
> > +
> > +			if (match) {
> > +				pos = i + 1;
> > +				break;
> > +			}
> > +		}
> 
> [Severity: High]
> If an object file contains multiple identical local symbols with the same name
> and from the same source file, will they all get assigned the exact same
> sympos value?
> 
> Because the outer loop processes each symbol independently and the inner
> matching loop breaks on the first match without tracking consumed matches,
> it appears all identical intra-file duplicates will continually match the first
> available entry in the sorted list and be assigned the same position.
> 
> Could this break livepatch target disambiguation if multiple identical 
> symbols in the same compilation unit share the same sympos?

Indeed, and not only are there intra-file duplicates, there are also
*inter* file duplicates with (same STT_FILE+sym), as STT_FILE is just
the basename, not the full path.  And those duplicates do exist.  So I
think we will need a more deterministic way to correlate vmlinux <->
vmlinux.o.  I think I have an idea how to do that, will write something
up.

-- 
Josh