[PATCH sched_ext/for-7.1-fixes] sched_ext: Clear ops->priv on scx_alloc_and_add_sched() error paths

[PATCH sched_ext/for-7.1-fixes] sched_ext: Clear ops->priv on scx_alloc_and_add_sched() error paths

[Andrea Righi]

scx_alloc_and_add_sched() can fail after @sch has been assigned to
ops->priv. In those cases @sch is torn down (either via kfree() through
the err_free_* chain or via kobject_put() -> scx_kobj_release() -> RCU
work), but @ops->priv is left pointing at the about-to-be-freed pointer.

With the recent -EBUSY gate in scx_root_enable_workfn() and
scx_sub_enable_workfn() that rejects an attach when @ops->priv is still
non-NULL, see commit bbf30b383cf6 ("sched_ext: Fix ops->priv clobber on
concurrent attach/detach"), a dangling @ops->priv permanently locks the
kdata out: every future attach attempt sees a stale binding and returns
-EBUSY even though no scheduler is actually attached.

Clear @ops->priv on the post-assign failure paths so that the kdata
returns to its pre-attach state when the function returns ERR_PTR().

Fixes: bbf30b383cf6 ("sched_ext: Fix ops->priv clobber on concurrent attach/detach")
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrea Righi <arighi@nvidia.com>
---
 kernel/sched/ext.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
index c49ada0a89c7f..1e635174a8bc7 100644
--- a/kernel/sched/ext.c
+++ b/kernel/sched/ext.c
@@ -6667,6 +6667,7 @@ static struct scx_sched *scx_alloc_and_add_sched(struct sched_ext_ops *ops,
 		ret = kobject_init_and_add(&sch->kobj, &scx_ktype, NULL, "root");
 
 	if (ret < 0) {
+		RCU_INIT_POINTER(ops->priv, NULL);
 		kobject_put(&sch->kobj);
 		return ERR_PTR(ret);
 	}
@@ -6674,6 +6675,7 @@ static struct scx_sched *scx_alloc_and_add_sched(struct sched_ext_ops *ops,
 	if (ops->sub_attach) {
 		sch->sub_kset = kset_create_and_add("sub", NULL, &sch->kobj);
 		if (!sch->sub_kset) {
+			RCU_INIT_POINTER(ops->priv, NULL);
 			kobject_put(&sch->kobj);
 			return ERR_PTR(-ENOMEM);
 		}
@@ -6681,6 +6683,7 @@ static struct scx_sched *scx_alloc_and_add_sched(struct sched_ext_ops *ops,
 #else	/* CONFIG_EXT_SUB_SCHED */
 	ret = kobject_init_and_add(&sch->kobj, &scx_ktype, NULL, "root");
 	if (ret < 0) {
+		RCU_INIT_POINTER(ops->priv, NULL);
 		kobject_put(&sch->kobj);
 		return ERR_PTR(ret);
 	}
@@ -6689,6 +6692,7 @@ static struct scx_sched *scx_alloc_and_add_sched(struct sched_ext_ops *ops,
 
 #ifdef CONFIG_EXT_SUB_SCHED
 err_free_lb_resched:
+	RCU_INIT_POINTER(ops->priv, NULL);
 	free_cpumask_var(sch->bypass_lb_resched_cpumask);
 #endif
 err_free_lb_cpumask:
-- 
2.54.0

Re: [PATCH sched_ext/for-7.1-fixes] sched_ext: Clear ops->priv on scx_alloc_and_add_sched() error paths

[Tejun Heo]

Hello,

On Mon, May 11, 2026 at 10:31:30AM +0200, Andrea Righi wrote:
> sched_ext: Clear ops->priv on scx_alloc_and_add_sched() error paths

Applied to sched_ext/for-7.1-fixes.

Thanks.

--
tejun

Re: [PATCH sched_ext/for-7.1-fixes] sched_ext: Clear ops->priv on scx_alloc_and_add_sched() error paths

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Use-After-Free in error path due to synchronous free of an RCU-published scheduler object.
--

commit d7deeed41c3e10702cde2a93eca3d9b6aba8924d
Author: Andrea Righi <arighi@nvidia.com>

sched_ext: Clear ops->priv on scx_alloc_and_add_sched() error paths

This commit addresses an issue where a failed attach leaves a dangling pointer
in ops->priv, preventing future attach attempts. It adds code to clear the
pointer on the failure paths in scx_alloc_and_add_sched() so the data returns
to its pre-attach state.

> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> index 1d7f206941f0c..535bbb678cc5b 100644
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c
> @@ -6824,6 +6824,7 @@ static struct scx_sched *scx_alloc_and_add_sched(struct scx_enable_cmd *cmd,
>  		ret = kobject_init_and_add(&sch->kobj, &scx_ktype, NULL, "root");
>  
>  	if (ret < 0) {
> +		RCU_INIT_POINTER(ops->priv, NULL);

Could this lead to a use-after-free for concurrent RCU readers?

The scheduler object is published to lockless RCU readers earlier in the
function via rcu_assign_pointer(ops->priv, sch).

If an initialization step fails after that point, the pointer is correctly
cleared here, but the object and its inner allocations are then synchronously
freed in the teardown chain (for example, via kobject_put() or kfree(sch))
without waiting for an RCU grace period. Concurrent BPF programs could still
be accessing the freed memory as RCU readers.

Would it be safer to defer the rcu_assign_pointer() publication until the
very end of the function, ensuring the object is only published once all
fallible initializations have succeeded? This might also naturally
eliminate the need to clear ops->priv on these error paths.

>  		kobject_put(&sch->kobj);
>  		return ERR_PTR(ret);
>  	}

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511083130.3174880-1-arighi@nvidia.com?part=1