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

> bpf: Enforce cgroup storage map consistency for freplace attach
>
> When a BPF_PROG_TYPE_EXT program replaces a cgroup program, it
> executes with the target's runtime context, including the per-program
> cgroup storage descriptor attached to the cgroup prog item:
> bpf_get_local_storage() resolves the buffer via
> prog_item->cgroup_storage, so the extension's own storage map never
> provides storage at runtime. The verifier, however, bounds the
> extension's bpf_get_local_storage() accesses by the extension's own
> storage map.
>
> The prog-array path already enforces that programs sharing a
> runtime storage context reference identical storage maps (via the
> owner cookie matching added in commit abad3d0bad72 ("bpf: Fix oob
> access in cgroup local storage")), but the freplace path performs
> no such consistency check in bpf_freplace_check_tgt_prog(). An
> extension whose storage map differs from the target's therefore
> operates on a buffer whose size, flags and layout do not match its
> verified assumptions: a smaller target buffer leads to slab
> out-of-bounds access, and even equal-sized maps can bypass
> BPF_F_RDONLY_PROG or mismatch BPF_SPIN_LOCK fields.
>
> Reject the freplace attach with -EINVAL unless the extension
> references the exact same cgroup storage map as the target program,
> matching the cookie semantics of __bpf_prog_map_compatible().
>
> Fixes: 7d9c3427894f ("bpf: Make cgroup storages shared between programs on the same cgroup")

Does this Fixes tag point to the correct commit? Looking at the commit
history, 7d9c3427894f introduced storage map sharing between programs on
the same cgroup.

However, before that commit, bpf_cgroup_storage_assign() bound each
cgroup storage map to exactly one program. This meant a target program and
an extension that both used cgroup storage were guaranteed to reference
different maps - the mismatch this patch rejects was unavoidable.

The extension's bpf_get_local_storage() already resolved the buffer from
the runtime prog-array item rather than from its own map even before
7d9c3427894f, so the underlying behavior existed earlier.

The condition became reachable when dynamic program extensions were
introduced in be8704ff07d2 ("bpf: Introduce dynamic program extensions").
Since this is Cc'd to stable, should the Fixes tag reference be8704ff07d2
instead to direct the backport to the correct range?


---
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/32002984717