BPF cgroup link update fixed for stack out-of-bounds write

The Linux kernel BPF cgroup link path is getting a fix for a stack out-of-bounds write that could happen when replacing the program on an active link.

Sanghyun Park found that link updates checked only the BPF program type. Several cgroup hooks share a type while using different runtime contexts and verifier contracts. A UDP6 sock_addr program could therefore replace a UDP4 program and write past a four-byte address field into neighboring fields of a stack-local cookie structure. The same gap let an LSM_MAC program replace an LSM_CGROUP program despite incompatible return semantics.

The change validates the replacement against the link's attach type, reusing existing per-type rules and comparing LSM expected attach types explicitly because both flavors share one program type. Legacy non-enforcing CGROUP_SKB ingress and egress replacements stay allowed. CGROUP_SKB still skips CAP_NET_ADMIN on load and checks it only at attach; once a link exists, updates remain controlled by the link file descriptor, so the update path keeps attach-type validation without rechecking that capability.

On the BPF list, Leon Hwang asked whether CAP_NET_ADMIN should also apply on update and whether the cgroup-only gate around the new checks could be dropped so create and update share the same attach-type validation.