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

[Leon Hwang <leon.hwang@linux.dev>]

On 25/8/26 04:10, Andrii Nakryiko wrote:
> On Sun, Aug 23, 2026 at 10:04 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> On 22/8/26 03:35, Andrii Nakryiko wrote:
>>> On Fri, Aug 21, 2026 at 3:26 AM Leon Hwang <leon.hwang@linux.dev> 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).

Got it. Thanks for the explanation.

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

Sorry about that. Understand your concern.

Thanks,
Leon

> [...]