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

From: Harry Hsu

Date: Sun Aug 23 2026 - 01:00:49 EST


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