# Re: \[PATCH v8 4/9\] livepatch: Call klp\_init\_patch\_early() earlier

- From: sashiko-bot@kernel.org
- Date: 2026-09-09 02:56:27 
- List: live-patching
- Page: https://ratatoskr.run/live-patching/2026/09/17534915
- Thread: https://ratatoskr.run/live-patching/2026/09/17534879/t.md

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

Pre-existing issues:
- [High] Fatal UAF / Kernel Panic on module unload due to unparented kobjects triggering delayed work in freed memory.
--

commit 92da60558ebea290d37fbe304d56429622a3eb02
Author: Yafang Shao [ref]

livepatch: Call klp_init_patch_early() earlier

Invoke klp_init_patch_early() during early initialization to avoid
mixing for_each_() and for_each_*_static() variants later in the code.

> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index c34306ecfb0bb..f088955de8557 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c

[ ... ]

> @@ -1152,10 +1145,17 @@ int klp_enable_patch(struct klp_patch *patch)
>  
>  	klp_init_patch_early(patch);
>  
> +	if (!klp_is_patch_compatible(patch)) {
> +		pr_err("Livepatch patch (%s) is not compatible with the already installed livepatches.\n",
> +			patch->mod->name);
> +		ret = -EINVAL;
> +		goto err;
> +	}
> +

[Severity: High]
This is a pre-existing issue, but moving the compatibility check after
klp_init_patch_early() makes it highly reachable when an incompatible
patch is loaded. Could this lead to a use-after-free and kernel panic
during module unload?

When klp_init_patch_early() runs, it calls kobject_init() for child obj
and func objects. However, their parent pointers are not set until later
in klp_init_patch() via kobject_add().

If klp_is_patch_compatible() fails here, the error path calls
klp_free_patch_start() which puts these unparented child kobjects. Under
CONFIG_DEBUG_KOBJECT_RELEASE, their release functions are scheduled
asynchronously with a random delay.

Because the children lack parent pointers, they do not hold a reference to
patch->kobj. As a result, klp_free_patch_finish() will complete immediately
when waiting on patch->finish, and module_put(patch->mod) allows the module
to unload, freeing the statically allocated obj and func structures.

Later, when delayed release functions like klp_kobj_release_object() finally
execute, they will dereference obj->dynamic in freed memory.

>  	ret = klp_init_patch(patch);
>  	if (ret)
>  		goto err;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909024324.16002-1-laoar.shao@gmail.com?part=4
```