Re: [PATCH bpf-next 3/3] bpf, cgroup: Protect cgroup_bpf state with its own mutex

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Medium] bpf: lost error codes in __cgroup_bpf_query() [1]
--

commit 20190389f8922442abed742617dfa9e59bf26340
Author: Shakeel Butt <shakeel.butt@linux.dev>

bpf, cgroup: Protect cgroup_bpf state with its own mutex

This commit introduces a dedicated cgroup_bpf_mutex to protect cgroup BPF
state so that operations not modifying the hierarchy do not have to contend
on cgroup_mutex.

> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 334237096759f..ae082ac86130b 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c

[ ... ]

> @@ -1518,7 +1565,7 @@ static int __cgroup_bpf_query(struct cgroup *cgrp, const union bpf_attr *attr,
>  	for (atype = from_atype; atype <= to_atype && total_cnt; atype++) {
>  		if (effective_query) {
>  			effective = rcu_dereference_protected(cgrp->bpf.effective[atype],
> -							      lockdep_is_held(&cgroup_mutex));
> +							      cgroup_bpf_held());
>  			cnt = min_t(int, bpf_cgroup_array_length(effective, atype), total_cnt);
>  			ret = bpf_cgroup_array_copy_to_user(effective, prog_ids, cnt, atype);
>  		} else {

[Severity: Medium]
This problem wasn't introduced by this patch, but can assigning ret from
bpf_cgroup_array_copy_to_user() drop an earlier -ENOSPC or -EFAULT error
[1]?

Before the loop, __cgroup_bpf_query() sets ret = -ENOSPC when
attr->query.prog_cnt < total_cnt:

kernel/bpf/cgroup.c:__cgroup_bpf_query() {
	...
	if (attr->query.prog_cnt < total_cnt) {
		total_cnt = attr->query.prog_cnt;
		ret = -ENOSPC;
	}

	for (atype = from_atype; atype <= to_atype && total_cnt; atype++) {
		if (effective_query) {
			...
			ret = bpf_cgroup_array_copy_to_user(effective, prog_ids, cnt, atype);
	...
}

When effective_query is set, bpf_cgroup_array_copy_to_user() overwrites
ret with 0 when the truncated slice fits in the array, or a later
iteration (for BPF_LSM_CGROUP) can overwrite an earlier -EFAULT, causing
__cgroup_bpf_query() to return 0 on truncated or faulted queries.

[1] https://sashiko.dev/#/bug/linux-20442c38-bcc8-440c-9711-1977ea6cd04b

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261112172721.440275-1-shakeel.butt@linux.dev?part=3