> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index a656a8572bdb..d85869544dc8 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -2480,8 +2480,12 @@ static bool __bpf_prog_map_compatible(struct bpf_map
> *map,
> break;
> cookie = aux->cgroup_storage[i] ?
> aux->cgroup_storage[i]->cookie : 0;
> - ret = map->owner->storage_cookie[i] == cookie ||
> - !cookie;
> + /*
> + * Tail calls keep using the caller cgroup storage
> + * context, so prog-array members must use the same
> + * storage cookie.
> + */
> + ret = map->owner->storage_cookie[i] == cookie;
Does dropping the "!cookie" term here reject a configuration that was
previously valid and safe?
With the old check, a program that uses no cgroup local storage (cookie
== 0) could join a prog-array whose owner uses cgroup storage
(storage_cookie[i] != 0), because "!cookie" was true. With the new check,
"storage_cookie[i] == 0" is false for that owner, so the storage-less
program is now rejected with -EINVAL:
prog_fd_array_get_ptr() (kernel/bpf/arraymap.c)
bpf_prog_map_compatible() (kernel/bpf/core.c)
__bpf_prog_map_compatible()
The original fix in abad3d0bad72 ("bpf: Fix oob access in cgroup local
storage") appears to document this allowance as intended, describing case
(ii) as "allow the tail call combination if the second program was not
using any of the cgroup local storage maps."
The out-of-bounds access that fix targets happens when a program that
calls bpf_get_local_storage() runs under a mismatched-size entry-program
run context. bpf_get_local_storage() in kernel/bpf/cgroup.c reads the
entry program's pinned run context:
storage = this_cpu_read(bpf_cgroup_storage[stype]);
A program that uses no cgroup local storage never calls that helper, so
can it actually trigger the out-of-bounds access?
For the A -> B(no storage) -> C(storage) path in the commit message, would
C still need to match the owner cookie to join the prog-array, since
C's cookie is nonzero and "!cookie" is false for it? If so, is the bridge
path that this patch aims to close already blocked by the existing check
on C?
This change is Cc: stable and applies under CONFIG_CGROUP_BPF=y, so could
it break existing BPF applications that mix storage-using and storage-less
programs in a single prog-array?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26936884530
