Re: [PATCH v2 sched_ext/for-7.3 19/36] sched_ext: Add per-shard cap delegation for sub-schedulers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Concurrent BPF execution can trigger a NULL pointer dereference in scx_bpf_sub_caps() during scheduler initialization.
--

commit 1c8e81a3938a3d80669e9d95ad976bab30a8473a
Author: Tejun Heo <tj@kernel.org>

sched_ext: Add per-shard cap delegation for sub-schedulers

This commit adds a framework for sub-scheduler capability delegation with
per-shard locking. The enable path is reordered so pshards are allocated
before the scheduler becomes reachable, and several new BPF kfuncs are
introduced to manage and query capabilities.

> diff --git a/kernel/sched/ext/sub.c b/kernel/sched/ext/sub.c
> index eb9056f21ce8a..36803b6df6318 100644
> --- a/kernel/sched/ext/sub.c
> +++ b/kernel/sched/ext/sub.c

[ ... ]

> @@ -737,6 +791,281 @@ __bpf_kfunc bool scx_bpf_sub_dispatch(u64 cgroup_id, const struct bpf_prog_aux *

[ ... ]

> +__bpf_kfunc s32 scx_bpf_sub_caps(u64 cgroup_id, u64 caps, struct scx_cmask *out__ign,
> +				 const struct bpf_prog_aux *aux)
> +{

[ ... ]

> +	/*
> +	 * The target's caps storage may not be set up yet (e.g. a self-read
> +	 * during ops.init_cids()).
> +	 */
> +	if (unlikely(!target->pshard)) {
> +		scx_error(sch, "scx_bpf_sub_caps() called before caps storage is initialized");
> +		return -ENODEV;
> +	}
> +
> +	ret = scx_cmask_ref_init(sch, out__ign, &ref);
> +	if (ret) {
> +		scx_error(sch, "invalid out (%d)", ret);
> +		return ret;
> +	}
> +
> +	for (si = ref.shard_first; si < ref.shard_end; si++) {
> +		const struct scx_cid_shard *shard = &scx_cid_shard_ranges[si];
> +		SCX_CMASK_DEFINE_SHARD(local_out, shard->base_cid, shard->nr_cids);
> +		u32 cap_bit;
> +
> +		scx_for_each_cap_bit(cap_bit, caps)
> +			scx_cmask_or(local_out, &target->pshard[si]->caps[cap_bit].cmask);

[Severity: High]
Can this lead to a NULL pointer dereference during scheduler initialization?

If a concurrent BPF syscall program calls scx_bpf_sub_caps() while
scx_alloc_pshards() is still executing, target->pshard could be non-NULL
but individual elements like target->pshard[si] might not be initialized yet.

In scx_root_enable_workfn(), the scheduler can be published via
rcu_assign_pointer(scx_root, sch) before scx_alloc_pshards() finishes
allocating the individual shard elements. 

The target->pshard array allocation would pass the check above, but 
dereferencing target->pshard[si]->caps[cap_bit] here could crash if that
specific index is still NULL.

Could the scheduler publication be delayed until all pshard array elements
are fully populated, or should this iteration verify each array element?

> +		scx_cmask_ref_copy(&ref, local_out);
> +	}
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706014058.439853-1-tj@kernel.org?part=19