Re: [PATCH bpf-next v3] bpf: Fix stack out-of-bounds write in cgroup link update

[Andrii Nakryiko]

On Sun, Aug 23, 2026 at 10:04 PM Leon Hwang <leon.hwang@xxxxxxxxx> wrote:
>
> On 22/8/26 03:35, Andrii Nakryiko wrote:
> > On Fri, Aug 21, 2026 at 3:26 AM Leon Hwang <leon.hwang@xxxxxxxxx> wrote:
> [...]
> >>
> >> Any issue of checking CAP_NET_ADMIN for BPF_LINK_UPDATE?
> >>
> >> If no, checking CAP_NET_ADMIN for BPF_LINK_UPDATE looks okay.
> >>
> >
> > Why do we need extra capability checks during LINK_UPDATE if we
> > already performed the check during LINK_CREATE? If you pass link fd to
> > some process that doesn't have CAP_NET_ADMIN, but has link fd and
> > another validated prog fd, they should be able to update the
> > underlying program without extra checks, IMO.
> >
> What if a pinned link is updated by non-CAP_NET_ADMIN users? I (LLM)
> verified the case by the selftest [1]. Is this case allowed intentionally?

I (human) think that yes, it's allowed by checking CAP_NET_ADMIN on
initial LINK_CREATE for a given target and program (which fixes
program type), and after that FD ownership can be transferred and BPF
program can atomically be updated by whoever has that link FD (and new
program's FD).

But Leon, show a bit more respect to humans next time, please.

>
> [1] https://github.com/Asphaltt/bpf/commits/bpf/link-update-issue/v1/
>
> Thanks,
> Leon
>