Re: [PATCH bpf v2] bpf: fix percpu map update indexing with sparse CPU IDs

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The BPF_F_CPU map flag validation is vulnerable to out-of-bounds memory access (read/write) when the `cpu_possible_mask` is sparse. The validation incorrectly checks against `num_possible_cpus()` instead of verifying if the CPU ID is actually a valid possible CPU.
--

--- Patch [1]: [PATCH bpf v2] bpf: fix percpu map update indexing with sparse CPU IDs ---
commit 5d6a274a595d67867bb26dbd708c1d7e75d30170
Author: Hui Su <sh_def@163.com>

bpf: fix percpu map update indexing with sparse CPU IDs

This patch fixes an issue where percpu map updates incorrectly advance
the user value pointer using the physical CPU ID instead of a dense index.
This resolves out-of-bounds reads from the user buffer on systems with
sparse possible CPU masks.

Link: https://lore.kernel.org/lkml/20260813120250.796934-4-sh_def@163.com/

> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> index 248b4818178cd..cc3f8c25a28b5 100644
> --- a/kernel/bpf/arraymap.c
> +++ b/kernel/bpf/arraymap.c
> @@ -405,7 +405,7 @@ int bpf_percpu_array_update(struct bpf_map *map, void *key, void *value,

[ ... ]

> @@ -437,9 +437,10 @@ int bpf_percpu_array_update(struct bpf_map *map, void *key, void *value,
>  	}

[Severity: High]
This is a pre-existing issue, but since this patch focuses on sparse CPU
topologies, is the BPF_F_CPU flag validation also vulnerable to sparse
CPU masks?

Looking at bpf_map_check_op_flags() in include/linux/bpf.h, the validation
checks:

    if ((flags & BPF_F_CPU) && cpu >= num_possible_cpus())
        return -ERANGE;

Because num_possible_cpus() is a population count rather than a check
against cpu_possible_mask or nr_cpu_ids, could an invalid or impossible
physical CPU ID that is strictly less than num_possible_cpus() pass this
check?

If such a CPU ID passes validation, it appears it would be used immediately
above the modified code in bpf_percpu_array_update():

    if (map_flags & BPF_F_CPU) {
        cpu = map_flags >> 32;
        ptr = per_cpu_ptr(pptr, cpu);
        copy_map_value(map, ptr, value);

Can this cause per_cpu_ptr() to return an unmapped raw percpu offset
since __per_cpu_offset[cpu] would be 0 for an impossible CPU, resulting
in a page fault and kernel panic when dereferenced by copy_map_value()?

Should the validation in bpf_map_check_op_flags() be updated to use
cpu_possible(cpu) or check against nr_cpu_ids instead?

>  	for_each_possible_cpu(cpu) {
>  		ptr = per_cpu_ptr(pptr, cpu);
> -		val = (map_flags & BPF_F_ALL_CPUS) ? value : value + size * cpu;
> +		val = (map_flags & BPF_F_ALL_CPUS) ? value : value + off;
>  		copy_map_value(map, ptr, val);
>  		bpf_obj_cancel_fields(map, ptr);
> +		off += size;
>  	}
>  unlock:
>  	rcu_read_unlock();

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260813155131.1022745-3-sh_def@163.com?part=1