Re: [PATCH v2 bpf] bpf: Enforce cgroup storage map consistency for freplace attach

On Mon, 17 Aug 2026, [email protected] wrote:
> Does this Fixes tag point to the correct commit?
>
> [...] should the Fixes tag reference be8704ff07d2 instead to direct
> the backport to the correct range?

The analysis is largely correct: before 7d9c3427894f, the extension
could already observe the target's storage. bpf_get_local_storage()
resolved the buffer through a per-CPU pointer set from the prog array
item in the run loop (bpf_cgroup_storage_set(_item->cgroup_storage)
in include/linux/bpf.h), bpf_cgroup_storage_assign() enforced 1:1
map-to-prog binding so an extension and its target could never share
a map, and be8704ff07d2 made EXT programs inherit the target's
verifier ops without excluding cgroup targets. So the freplace +
mismatched-storage combination was technically reachable since v5.6.

I kept 7d9c3427894f anyway, for three reasons:

1. abad3d0bad72 ("bpf: Fix oob access in cgroup local storage"), the
   analogous fix for the tail-call vector of the same
   verifier-vs-runtime-context confusion, uses Fixes: 7d9c3427894f.
   Identical tags keep the backport sets of both fixes aligned.

2. All currently maintained stable trees (5.10+) contain both
   be8704ff07d2 and 7d9c3427894f, so the tag choice does not change
   which kernels receive this fix in practice.

3. 7d9c3427894f introduced the shared prog_item->cgroup_storage
   runtime model that both this changelog and abad3d0bad72 describe;
   the pre-7d9c3427894f per-CPU mechanism was superseded by it.

That said, if maintainers prefer be8704ff07d2 for strict
reachability accuracy, I can respin with the tag changed.

Thanks,
Aohan