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

> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 6874ba1424af..dfea337ff25e 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c

[ ... ]

> @@ -4542,6 +4536,19 @@ static int bpf_prog_attach_check_attach_type(const struct bpf_prog *prog,
>  	}
>  }
>
> +static int bpf_prog_attach_check(const struct bpf_prog *prog,
> +				 enum bpf_attach_type attach_type)
> +{
> +	if (prog->type == BPF_PROG_TYPE_CGROUP_SKB &&
> +	    !bpf_token_capable(prog->aux->token, CAP_NET_ADMIN))
> +		/* cg-skb progs can be loaded by unpriv user.
> +		 * check permissions at attach time.
> +		 */
> +		return -EPERM;
> +
> +	return bpf_prog_attach_check_attach_type(prog, attach_type);
> +}
> +

This isn't a bug, but would a name that mentions the permission gate
read more clearly next to bpf_prog_attach_check_attach_type()?

The new helper bpf_prog_attach_check() sits near
bpf_prog_attach_check_attach_type() in the same file, and the two names
differ only by a suffix while the security-relevant difference is which
one enforces CAP_NET_ADMIN.

link_update() deliberately calls the longer-named, non-enforcing one
(bpf_prog_attach_check_attach_type), and bpf_prog_attach() plus
link_create() call the shorter, enforcing one (bpf_prog_attach_check).
A name like bpf_prog_attach_check_perm would make the choice at each of
the three call sites self-evident.

[ ... ]


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