Re: [PATCH] sched_ext: Validate cid override before updating tables

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Splitting the `cpu_to_cid` array validation and update into two loops introduces a critical double-fetch TOCTOU vulnerability, allowing an out-of-bounds kernel memory write.
--

--- Patch [1]: [PATCH] sched_ext: Validate cid override before updating tables ---
commit 3a1a6d6109297fa0a7f1d91d2dccc68df1527d12
Author: zhidao su (Xiaomi) <[email protected]>

sched_ext: Validate cid override before updating tables

This patch splits the validation and table updates in scx_bpf_cid_override()
into separate loops. This prevents partial table updates if the validation
fails midway through the user-supplied mapping.

> diff --git a/kernel/sched/ext/cid.c b/kernel/sched/ext/cid.c
> index af83084ec740a..e398e3f209bd4 100644
> --- a/kernel/sched/ext/cid.c
> +++ b/kernel/sched/ext/cid.c
> @@ -329,6 +329,11 @@ __bpf_kfunc void scx_bpf_cid_override(const s32 *cpu_to_cid, u32 cpu_to_cid__sz,
>  			scx_error(sch, "cid %d assigned to multiple cpus", c);
>  			return;
>  		}
> +	}
> +
> +	for_each_possible_cpu(cpu) {
> +		s32 c = cpu_to_cid[cpu];
> +
>  		scx_cpu_to_cid_tbl[cpu] = c;
>  		scx_cid_to_cpu_tbl[c] = cpu;
>  	}

[Severity: High]
Can the contents of cpu_to_cid change concurrently between these two loops in
scx_bpf_cid_override()?

If cpu_to_cid points to shared memory, such as a BPF map, could another thread
or BPF program modify cpu_to_cid[cpu] after it passes the validation in the
first loop?

If this happens, the second loop would fetch the unvalidated value and use it
as an index for scx_cid_to_cpu_tbl[c], potentially resulting in an
out-of-bounds write.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1