Re: [PATCH] livepatch: Fix stack check for aliased old_func

Harry Hsu <[email protected]>
Newsgroups gmane.linux.kernel
Message-ID <[email protected]>
On Fri 2026-08-21 17:27:10, Petr Mladek wrote:
> This might fix klp_check_stack_func() for A. But not for B. B won't
> be the last entry so that klp_check_stack_func() would use
> the list_next_entry() and will check for A on stack instead of
> the original function.
>
> Another _big problem_ is in klp_ftrace_handler(). It would use A
> in PATCHED state and B in UNPATCHED. But it is not clear whether
> A or B should be used in the PATCHED state. And it should use
> the original code in UNPATCHED state.
>
> IMHO, we must catch this situation when preparing livepatches
> and when enabling the livepatch. A single livepatch must never
> create two entries on any ops->func_stack.
>
> IMHO, we should catch the duplicate (aliased) entries in
> klp_init_object_loaded() and return -EINVAL when they are found.
>
> I do not see any other solution. We could not decide which
> struct klp_func should be used for the redirection when
> more of them point to the same original function.

You're right, thanks for pointing this out. list_is_last() only
patches over the stack-check symptom for A and still leaves B wrong,
and it does nothing for the klp_ftrace_handler() ambiguity you
describe - there's really no sound way to pick between A and B once
they're both live entries backed by the same old_func.

Rejecting the duplicate at load time is the right fix. I'll send a
v2 that detects aliased old_func addresses within the same klp_object
in klp_init_object_loaded() and returns -EINVAL when found, instead
of touching klp_check_stack_func().

Thanks,
Harry
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.