[BUG] sched_ext: sub-scheduler kfuncs use struct scx_sched beyond the RCU read side under sleepable ops

[BUG] sched_ext: sub-scheduler kfuncs use struct scx_sched beyond the RCU read side under sleepable ops

[Guikun Yang]

Hi Tejun,

The four sub-scheduler kfuncs scx_bpf_sub_grant(), scx_bpf_sub_revoke(),
scx_bpf_sub_caps() and scx_bpf_sub_kill_bstr() obtain the child
scheduler through scx_find_sub_sched(), which is an
rhashtable_lookup() call.  rhashtable_lookup() is the _fast variant:
it takes and releases the RCU read lock internally, so the returned
struct scx_sched * is only valid inside the caller's own RCU read-side
critical section.

The kfuncs themselves only take guard(irqsave)() (sub.c:2323).  They do
not hold an RCU read lock and take no reference on the scheduler, yet
they use the returned pointer for their whole body, for example in
scx_bpf_sub_grant():

	struct scx_pshard *pps = parent->pshard[si];
	struct scx_pshard *cps = child->pshard[si];
	...
	scoped_guard (raw_spinlock, &pps->lock) {
		guard(raw_spinlock_nested)(&cps->lock);
		...
		scx_cmask_for_each_cid(cid, changed_cids)
			queue_sync_ecaps(child, cid);

These four kfuncs are registered in scx_kfunc_ids_any (ext.c:10868),
and the context filter unconditionally admits in_any:

	if (in_any || in_idle || in_cid)
		return 0;

so they are callable from every sched_ext op, including the ops that
bpf_scx_check_member() (ext.c:8194) explicitly allows to be sleepable:
init_task, cgroup_init, cgroup_exit, cgroup_prep_move,
cgroup_set_bandwidth, cpu_online, cpu_offline, init_cids, init, exit,
sub_attach, sub_detach.

A sleepable struct_ops program holds no normal RCU read lock.  The
sleepable trampoline only takes rcu_read_lock_trace() and
migrate_disable() (kernel/bpf/trampoline.c:1446), and the framework
documents this at ext.c:10567:

	/* KF_RCU covers only @p - a sleepable program holds no RCU lock */

On the teardown side, sub-scheduler destruction drains only normal RCU:

	/*
	 * All tasks are moved off of @sch but there may still be on-going
	 * operations (e.g. ops.select_cpu()).  Drain them by flushing RCU.
	 * ...
	 */
	synchronize_rcu_expedited();
	scx_disable_bypass_dsp(sch);
	scx_unlink_sched(sch);

(sub.c:1626) and the release runs from scx_kobj_release() via
queue_rcu_work() into scx_sched_free_rcu_work(), which ends in
scx_free_pshards() (kfree of the pshard array, sub.c:135).

There is no synchronize_rcu_tasks_trace(), call_rcu_tasks_trace() or
kfree_rcu_tasks anywhere under kernel/sched/ext/.  A normal RCU
grace period does not wait for rcu_read_lock_trace() sections, so a
sleepable op running inside the teardown window keeps using the freed
scheduler object.

Trigger sequence:

1. The parent scheduler implements ops.cgroup_set_bandwidth as a
   sleepable program (explicitly allowed).  Its caller,
   scx_group_set_bandwidth() (ext.c:5044), only holds
   scx_cgroup_ops_rwsem, not scx_enable_mutex, so it can run
   concurrently with sub-scheduler teardown.

2. The op calls scx_bpf_sub_grant(child_cgroup_id, ...) (or
   sub_caps/sub_revoke/sub_kill_bstr).  The kfunc resolves "child"
   once in sub_cap_preamble() (sub.c:2270) and then dereferences it
   throughout.

3. Concurrently the sub-scheduler is torn down (its dispatch calls
   scx_bpf_sub_kill_bstr() which goes through scx_exit_bstr(), or the
   sub-scheduler itself calls scx_bpf_exit(), or a scx_error() fires).
   synchronize_rcu_expedited() does not stop the sleepable op; the
   reference count reaches zero, scx_kobj_release() queues
   scx_sched_free_rcu_work(), and scx_free_pshards() kfrees
   child->pshard[].

4. The still-running sleepable op reads the freed child->pshard[si],
   takes its raw spinlock, writes caps_updated and the delivery list,
   and calls queue_sync_ecaps(child, cid), which also reads
   child->pcpu after free_percpu().  A sleepable program only has
   migrate_disable(); it can be preempted, so the window is wide.

Impact: kernel use-after-free.  Under KASAN this is a clean
slab-use-after-free on struct scx_pshard and on the scheduler object.
In production the corrupted raw spinlock and list nodes lead to
arbitrary later crashes.  Loading a sched_ext program requires
privileges, so this is not an unprivileged attack surface, but the
kernel is crashing on an API-legal call sequence.

I verified against linux-next (2026-10-23 snapshot of
kernel/sched/ext/sub.c, 3198 lines vs 2682 in 7.3.0-rc7): the four
kfuncs are still in scx_kfunc_ids_any, the sleepable whitelist is
unchanged, scx_group_set_bandwidth() still takes no scx_enable_mutex,
and there is still no tasks-trace RCU anywhere in the directory.  The
new nr_ecaps_reports/ecaps_report_wait mechanism (7.4 series) covers
per-cpu ecaps reporting, not this path.

For contrast, the DSQ iterator (bpf_iter_scx_dsq_new) has exactly this
problem and solves it with KF_RCU_PROTECTED plus the verifier's
MEM_RCU handling, which makes sleepable programs wrap the iterator in
bpf_rcu_read_lock().  The sub kfuncs take a cgroup id (an integer), so
the verifier has nothing to track and there is no equivalent
enforcement.

Possible fixes (for you to pick from):

  1. Take a kobject reference on the resolved scheduler and drop it on
     return (kobject_get/kobject_put).  The pshard free happens after
     the kobject refcount reaches zero, so holding a reference closes
     the window.

  2. Move the sub kfuncs out of scx_kfunc_ids_any into a group
     constrained by the per-op allow table, and drop the relevant ops
     from the sleepable whitelist.

  3. Make scx_group_set_bandwidth()/scx_group_set_weight()/
     scx_group_set_idle() hold scx_enable_mutex while calling the op,
     serializing sleepable cgroup ops with teardown.  This fits the
     existing design (the other sleepable ops already run under
     scx_enable_mutex) at the cost of a global mutex on top of the
     percpu rwsem.

Full analysis with line references against 7.3.0-rc7:

  sub.c:95      scx_find_sub_sched() - rhashtable_lookup()
  sub.c:2270    sub_cap_preamble() - child resolved here
  sub.c:2323    guard(irqsave)() in scx_bpf_sub_grant()
  sub.c:2346    child->pshard[si] usage loop
  sub.c:2570    scx_bpf_sub_caps() same pattern
  ext.c:8194    bpf_scx_check_member() sleepable whitelist
  ext.c:10567   "KF_RCU covers only @p" comment
  ext.c:10868   scx_kfunc_ids_any registration
  ext.c:10975   scx_kfunc_context_filter() in_any passthrough
  ext.c:5519    scx_kobj_release() -> queue_rcu_work()
  ext.c:5492    scx_sched_free_rcu_work() -> scx_free_pshards()
  trampoline.c:1446 __bpf_prog_enter_sleepable()

Thanks,
Guikun Yang

Re: [BUG] sched_ext: sub-scheduler kfuncs use struct scx_sched beyond the RCU read side under sleepable ops

[Tejun Heo]

Hello, Guikun.

On Sat, Oct 24, 2026 at 03:47:07PM +0800, Guikun Yang wrote:
> The four sub-scheduler kfuncs scx_bpf_sub_grant(), scx_bpf_sub_revoke(),
> scx_bpf_sub_caps() and scx_bpf_sub_kill_bstr() obtain the child
> scheduler through scx_find_sub_sched(), which is an
> rhashtable_lookup() call.  rhashtable_lookup() is the _fast variant:
> it takes and releases the RCU read lock internally, so the returned
> struct scx_sched * is only valid inside the caller's own RCU read-side
> critical section.

There's no use-after-free here.

rhashtable_lookup() isn't the _fast variant. It requires the caller to
be in an RCU read-side critical section. rhashtable_lookup_fast() is the
one that wraps itself in rcu_read_lock()/rcu_read_unlock().

> The kfuncs themselves only take guard(irqsave)() (sub.c:2323).  They do
> not hold an RCU read lock and take no reference on the scheduler, yet
> they use the returned pointer for their whole body, for example in
> scx_bpf_sub_grant():

scx_bpf_sub_grant(), scx_bpf_sub_revoke() and scx_bpf_sub_caps() do
guard(irqsave)() before the lookup, and the lookup and every use of the
child happen inside that IRQ-disabled region. scx_bpf_sub_kill_bstr()
takes guard(rcu)() explicitly.

Since v5.0, a region with IRQs disabled is an RCU read-side critical
section, and synchronize_rcu(), synchronize_rcu_expedited() and
call_rcu()/queue_rcu_work() wait for it (see the comment above
synchronize_rcu() in kernel/rcu/tree.c). Whether the sleepable program
holds an RCU lock of its own doesn't matter.

> There is no synchronize_rcu_tasks_trace(), call_rcu_tasks_trace() or
> kfree_rcu_tasks anywhere under kernel/sched/ext/.  A normal RCU
> grace period does not wait for rcu_read_lock_trace() sections, so a
> sleepable op running inside the teardown window keeps using the freed
> scheduler object.

scx_unlink_sched() removes the sched from scx_sched_hash before the last
reference is dropped, and scx_kobj_release() frees it through
queue_rcu_work(). So the grace period before the free waits for any
kfunc that found the sched in the hash.

Thanks.

--
tejun