Re: [PATCH v2 sched_ext/for-7.1-fixes] sched_ext: Fix ops->priv clobber on concurrent attach/detach

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Error paths in `scx_alloc_and_add_sched()` leave `ops->priv` as a dangling pointer, causing the new `-EBUSY` check to permanently brick the BPF map and exposing a Use-After-Free.
--

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

sched_ext: Fix ops->priv clobber on concurrent attach/detach

This commit addresses a NULL pointer dereference caused by a race condition
during concurrent attach and detach operations. It adds a check to reject
attempts to reuse a kdata that is still bound to a previous scheduler
instance.

> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c
> @@ -6733,6 +6733,19 @@ static void scx_root_enable_workfn(struct kthread_work *work)
>  		goto err_unlock;
>  	}
>  
> +	/*
> +	 * @ops->priv binds @ops to its scx_sched instance. It is set here by
> +	 * scx_alloc_and_add_sched() and cleared at the tail of bpf_scx_unreg(),
> +	 * which runs after scx_root_disable() has dropped scx_enable_mutex. If
> +	 * it's still non-NULL here, a previous attachment on @ops has not
> +	 * finished tearing down; proceeding would let the in-flight unreg's
> +	 * RCU_INIT_POINTER(NULL) clobber the @ops->priv we are about to assign.
> +	 */
> +	if (rcu_access_pointer(ops->priv)) {
> +		ret = -EBUSY;
> +		goto err_unlock;
> +	}

If scx_alloc_and_add_sched() fails during a subsequent attachment attempt,
does this leave ops->priv pointing to freed memory?

Looking at scx_alloc_and_add_sched(), the BPF operations map is bound to
the new scheduler instance early:

    rcu_assign_pointer(ops->priv, sch);

If a later initialization step in that function fails, such as allocating
cgrp_path or failing kobject_init_and_add, the error paths free sch via
kfree(sch) or kobject_put(&sch->kobj). However, the error paths do not
reset ops->priv to NULL.

Because ops->priv retains the dangling pointer to the freed memory, will
the new check added here permanently block any future attachments by always
returning -EBUSY?

Could this dangling ops->priv pointer also be accessed by a BPF program
running a sched_ext kfunc like scx_bpf_kick_cpu, resulting in a
use-after-free when scx_prog_sched() retrieves and dereferences it?

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