From: sashiko-bot@kernel.org
To: song@kernel.org, jikos@kernel.org, mbenes@suse.cz,
jpoimboe@kernel.org, joe.lawrence@redhat.com, pmladek@suse.com
Cc: live-patching@vger.kernel.org, "Yafang Shao" <laoar.shao@gmail.com>
Subject: Re: [PATCH v5 3/9] livepatch: Call klp_init_patch_early() earlier
Date: Sun, 09 Aug 2026 09:40:45 +0000 [thread overview]
Message-ID: <20260809094046.50ED31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260809091954.22930-4-laoar.shao@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] When CONFIG_DEBUG_KOBJECT_RELEASE is enabled, an error during patch initialization causes a Use-After-Free during module unload due to delayed kobject release.
--
--- Patch [3]: [PATCH v5 3/9] livepatch: Call klp_init_patch_early() earlier ---
commit ebdb1e39e8d2124754d0f852abe91968ee2bb0d7
Author: Yafang Shao <laoar.shao@gmail.com>
livepatch: Call klp_init_patch_early() earlier
This patch moves klp_init_patch_early() to an earlier stage during patch
initialization. This is intended 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 5d05d6fcbf57c..1908ebedf8734 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
[ ... ]
> @@ -1149,6 +1142,14 @@ 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 does moving klp_init_patch_early() before
klp_is_patch_compatible() make a delayed kobject release crash easier to hit
if the patch is incompatible?
When klp_init_patch_early() completes, it has called kobject_init() on the
patch->kobj, as well as all obj->kobj and func->kobj. If klp_is_patch_compatible()
fails and jumps to the err label, klp_free_patch_start() and klp_free_patch_finish()
are called.
klp_free_patch_start() drops the object and function kobject references:
kernel/livepatch/core.c:__klp_free_funcs() {
...
kobject_put(&func->kobj);
...
}
kernel/livepatch/core.c:__klp_free_objects() {
...
kobject_put(&obj->kobj);
...
}
However, klp_free_patch_finish() only waits for the patch kobject completion:
kernel/livepatch/core.c:klp_free_patch_finish() {
...
wait_for_completion(&patch->finish);
...
}
When CONFIG_DEBUG_KOBJECT_RELEASE is enabled, the kobject_put() on the
un-added objects queues a delayed work up to 4 seconds later to free the
kobjects. Because klp_free_patch_finish() doesn't wait for the child
kobjects, klp_enable_patch() can return and allow the module to unload,
freeing the klp_object and klp_func arrays before the delayed work accesses
them.
Can this result in a Use-After-Free during module unload?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260809091954.22930-1-laoar.shao@gmail.com?part=3
next prev parent reply other threads:[~2026-08-09 9:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-09 9:19 [PATCH v5 0/9] livepatch: Introduce replace set support Yafang Shao
2026-08-09 9:19 ` [PATCH v5 1/9] livepatch: Fix wrong index in funcs cleanup error path Yafang Shao
2026-08-09 9:28 ` sashiko-bot
2026-08-09 9:36 ` Yafang Shao
2026-08-09 9:19 ` [PATCH v5 2/9] livepatch: Make klp_find_func() non static Yafang Shao
2026-08-09 9:32 ` sashiko-bot
2026-08-09 9:39 ` Yafang Shao
2026-08-09 9:19 ` [PATCH v5 3/9] livepatch: Call klp_init_patch_early() earlier Yafang Shao
2026-08-09 9:40 ` sashiko-bot [this message]
2026-08-09 9:19 ` [PATCH v5 4/9] livepatch: Implement replace set for scoped atomic replace Yafang Shao
2026-08-09 9:33 ` sashiko-bot
2026-08-09 9:19 ` [PATCH v5 5/9] livepatch: Deprecate stack_order Yafang Shao
2026-08-09 9:19 ` [PATCH v5 6/9] selftests: livepatch: Adapt atomic replace tests to provides/obsoletes Yafang Shao
2026-08-09 9:33 ` sashiko-bot
2026-08-09 9:45 ` Yafang Shao
2026-08-09 9:19 ` [PATCH v5 7/9] selftests: livepatch: Add provides/obsoletes test scenarios Yafang Shao
2026-08-09 9:31 ` sashiko-bot
2026-08-09 9:19 ` [PATCH v5 8/9] selftests: livepatch: Add test for state ID conflict across provides Yafang Shao
2026-08-09 9:19 ` [PATCH v5 9/9] selftests: livepatch: Add test for function " Yafang Shao
2026-08-09 9:49 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260809094046.50ED31F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=laoar.shao@gmail.com \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=pmladek@suse.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=song@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox