Thread (23 messages) flat view 23 messages, 2 authors, 2026-08-10

Re: [PATCH v5 3/9] livepatch: Call klp_init_patch_early() earlier

From: sashiko-bot@kernel.org
Date: 2026-08-09 09:40:51

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 [off-list ref]

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.
quoted hunk ↗ jump to hunk
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
[ ... ]
quoted hunk ↗ jump to hunk
@@ -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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help