From: sashiko-bot@kernel.org
To: "Yafang Shao" <laoar.shao@gmail.com>,
jpoimboe@kernel.org, jikos@kernel.org, mbenes@suse.cz,
pmladek@suse.com, joe.lawrence@redhat.com, song@kernel.org
Cc: live-patching@vger.kernel.org
Subject: Re: [PATCH v12 4/9] livepatch: Call klp_init_patch_early() earlier
Date: Fri, 16 Oct 2026 05:47:02 +0000 [thread overview]
Message-ID: <sashiko-outbox-173836@kernel.org> (raw)
In-Reply-To: <20261016053708.47089-5-laoar.shao@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] livepatch: UAF on module unload if klp_is_patch_compatible() fails with DEBUG_KOBJECT_RELEASE
--
commit bd925cd8bf4694e6331eda23e1ebe254ec598efe
Author: Yafang Shao <laoar.shao@gmail.com>
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. This prepares
the code for an upcoming patch.
> 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
> @@ -1145,13 +1145,6 @@ int klp_enable_patch(struct klp_patch *patch)
>
> mutex_lock(&klp_mutex);
>
> - if (!klp_is_patch_compatible(patch)) {
> - pr_err("Livepatch patch (%s) is not compatible with the already installed livepatches.\n",
> - patch->mod->name);
> - mutex_unlock(&klp_mutex);
> - return -EINVAL;
> - }
> -
> if (!try_module_get(patch->mod)) {
> mutex_unlock(&klp_mutex);
> return -ENODEV;
> @@ -1159,6 +1152,13 @@ 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: Medium]
Can this sequence lead to a use-after-free regression during module unload if
CONFIG_DEBUG_KOBJECT_RELEASE is enabled?
If klp_is_patch_compatible() fails, we jump to err. This triggers kobject
teardown for objects that were initialized but never linked to a parent:
err:
klp_free_patch_start(patch);
...
klp_free_patch_finish(patch);
Because the child kobjects lack a parent linkage at this early stage, waiting
on patch->finish completes without waiting for the child kobjects to be fully
released.
If CONFIG_DEBUG_KOBJECT_RELEASE is enabled, the release is delayed. The
function returns and the livepatch module is unloaded, freeing its static
memory. Later, the delayed release work executes:
kernel/livepatch/core.c:klp_kobj_release_object()
obj = container_of(kobj, struct klp_object, kobj);
if (obj->dynamic)
Accessing obj->dynamic here would cause a use-after-free on the freed module
memory.
Should we ensure all child kobjects are fully released before returning, or
handle the initialization state differently?
> + }
> +
> ret = klp_init_patch(patch);
> if (ret)
> goto err;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261016053708.47089-1-laoar.shao@gmail.com?part=4
next prev parent reply other threads:[~2026-10-16 5:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 5:36 [PATCH v12 0/9] livepatch: Add support for scoped atomic replace Yafang Shao
2026-10-16 5:37 ` [PATCH v12 1/9] selftests/livepatch: Clarify test module file names Yafang Shao
2026-10-16 5:37 ` [PATCH v12 2/9] selftests/livepatch: Adapt atomic replace tests to provides/obsoletes Yafang Shao
2026-10-16 5:37 ` [PATCH v12 3/9] livepatch: Make klp_find_func() non static Yafang Shao
2026-10-16 5:37 ` [PATCH v12 4/9] livepatch: Call klp_init_patch_early() earlier Yafang Shao
2026-10-16 5:47 ` sashiko-bot [this message]
2026-10-16 7:49 ` Yafang Shao
2026-10-16 5:37 ` [PATCH v12 5/9] livepatch: Implement provides and obsoletes for scoped atomic replace Yafang Shao
2026-10-16 5:48 ` sashiko-bot
2026-10-16 7:46 ` Yafang Shao
2026-10-16 5:37 ` [PATCH v12 6/9] livepatch: Deprecate stack_order Yafang Shao
2026-10-16 5:37 ` [PATCH v12 7/9] selftests/livepatch: Add provides/obsoletes test scenarios Yafang Shao
2026-10-16 5:37 ` [PATCH v12 8/9] selftests/livepatch: Add state test for provides/obsoletes Yafang Shao
2026-10-16 5:37 ` [PATCH v12 9/9] selftests/livepatch: Add function " Yafang Shao
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=sashiko-outbox-173836@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.