Re: [PATCH] sched_ext: Fix NULL sched deref in select_cpu_and sub-sched error path

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch deliberately excludes `scx_bpf_dsq_insert_vtime()` from the fix, leaving a NULL pointer dereference and lockdep violation intact. The author incorrectly assumes that `@p is always the calling scheduler's own task in the contexts where it runs` because `SYSCALL` programs are rejected. However, `STRUCT_OPS` programs (such as `ops.enqueue` or `ops.dispatch`) are allowed to call this kfunc, and the BPF verifier only enforces the `KF_RCU` flag for `@p`. A `STRUCT_OPS` program can obtain an arbitrary task via `bpf_task_from_pid()` (e.g., an exited task or a CFS task) and legally pass it in. When a sub-scheduler is attached, the error path calls `scx_error(scx_task_sched(p), ...)`. Calling `scx_task_sched(p)` on an arbitrary task without its `pi_lock` or `rq_lock` triggers a lockdep warning, and if the task is not managed by sched_ext, it returns `NULL`. `scx_error()` then unconditionally dereferences this `NULL` pointer in `scx_vexit()`, oopsing the kernel.
--

commit ea8e652cd7b48dd94e0786bbc598c91806ffad36
Author: Wanwu Li <liwanwu@kylinos.cn>

sched_ext: Fix NULL sched deref in select_cpu_and sub-sched error path

This commit fixes a NULL pointer dereference in the error path of
scx_bpf_select_cpu_and() by using scx_task_sched_rcu(p). It deliberately
excludes scx_bpf_dsq_insert_vtime() from the fix based on the assumption
that it cannot be reached with a NULL task scheduler.

>     scx_bpf_dsq_insert_vtime() has the same error path but it is not reachable
>     with a NULL @p: SYSCALL programs are rejected for its kfunc set and @p is
>     always the calling scheduler's own task in the contexts where it runs, so
>     it is left unchanged.

[Severity: High]
This is a pre-existing issue, but is the assumption that @p is always the
calling scheduler's own task accurate here?

Although SYSCALL programs are rejected, struct_ops programs (such as
ops.enqueue or ops.dispatch) are allowed to call scx_bpf_dsq_insert_vtime()
in kernel/sched/ext/ext.c.

The BPF verifier only enforces the KF_RCU flag for the p argument, which
means a struct_ops program can obtain an arbitrary task via
bpf_task_from_pid() (e.g., an exited task or a task managed by CFS) and
legally pass it in.

If a sub-scheduler is attached, the error path in scx_bpf_dsq_insert_vtime()
calls scx_task_sched(p). Calling scx_task_sched(p) on an arbitrary task
without holding its pi_lock or rq_lock triggers a lockdep warning, and if the
task is not managed by sched_ext, it returns NULL.

The scx_error() function then unconditionally dereferences this NULL pointer
in scx_vexit(), oopsing the kernel.

Could scx_bpf_dsq_insert_vtime() also be updated to use the same
scx_task_sched_rcu(p) ?: sch fallback that this patch introduces?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902153640.144791-1-liwanwu@kylinos.cn?part=1