On Mon, Sep 7, 2026 at 3:08 PM Leon Hwang <[email protected]> wrote:
>
> On 2026/9/7 10:36, [email protected] wrote:
> >> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> >> index c7bc9ba9b331..b394a37eecb4 100644
> >> --- a/kernel/bpf/syscall.c
> >> +++ b/kernel/bpf/syscall.c
> >> @@ -4481,14 +4481,9 @@ static int bpf_prog_attach_check_attach_type(const 
> >> struct bpf_prog *prog,
> >>      case BPF_PROG_TYPE_CGROUP_SOCK_ADDR:
> >>      case BPF_PROG_TYPE_CGROUP_SOCKOPT:
> >>      case BPF_PROG_TYPE_SK_LOOKUP:
> >> +    case BPF_PROG_TYPE_LSM:
> >>              return attach_type == prog->expected_attach_type ? 0 : 
> >> -EINVAL;
> >
> > Does adding BPF_PROG_TYPE_LSM to this arm also relax the check on the
> > BPF_LINK_CREATE path?
> >
> > Before this patch, BPF_PROG_TYPE_LSM fell into the default arm:
> >
> >       default:
> >               ptype = attach_type_to_prog_type(attach_type);
> >               if (ptype == BPF_PROG_TYPE_UNSPEC || ptype != prog->type)
> >                       return -EINVAL;
> >               return 0;
> >
> > Since attach_type_to_prog_type() returns BPF_PROG_TYPE_LSM only for
> > BPF_LSM_MAC and BPF_LSM_CGROUP (kernel/bpf/syscall.c:4457, 4463), an LSM
> > program could only ever be accepted for those two attach types.
> >
> > The new arm drops that constraint and accepts any attach_type as long as it
> > equals prog->expected_attach_type. The other members of that arm are safe
> > because bpf_prog_load_check_attach() restricts their expected_attach_type
> > to a set that all maps back to the same prog type. BPF_PROG_TYPE_LSM is the
> > one type in that arm with no such restriction: bpf_prog_load_check_attach()
> > (kernel/bpf/syscall.c:2766 onwards) has no LSM case and falls into
> > `default: return 0`, so prog->expected_attach_type is entirely
> > userspace-controlled for LSM programs.
>
>
> Good catch.
>
> Since there's no expected_attach_type check for lsm prog, a lsm prog can
> have BPF_TRACE_ITER expected_attach_type, and creates a lsm link via
> BPF_LINK_CREATE with this patch. Such lsm prog cannot create a lsm link
> via BPF_LINK_CREATE without this patch.
>
> The new case BPF_PROG_TYPE_LSM in bpf_prog_attach_check_attach_type()
> relaxes the prog->type check when adding expected_attach_type check.
>
> I think we can add expected_attach_type check for lsm prog in
> bpf_prog_load_check_attach(). See below diff. The diff will restrict a
> lsm prog with these two expected_attach_type, BPF_LSM_MAC and
> BPF_LSM_CGROUP.
>

+1, skipping LSM progs in bpf_prog_load_check_attach() is counterintuitive
and the reason why we missed this edge case in the first place. It's
better to add
the missing checks than adjust the refactoring.

pw-bot: cr

> Thanks,
> Leon
>
> ---
>
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 6874ba1424af..4b56e82ff3b9 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -2830,6 +2830,16 @@ bpf_prog_load_check_attach(enum bpf_prog_type
> prog_type,
>                 if (expected_attach_type == BPF_NETFILTER)
>                         return 0;
>                 return -EINVAL;
> +       case BPF_PROG_TYPE_LSM:
> +               switch (expected_attach_type) {
> +               case BPF_LSM_MAC:
> +               case BPF_LSM_CGROUP:
> +                       return 0;
> +               default:
> +                       return -EINVAL;
> +               }
>         case BPF_PROG_TYPE_SYSCALL:
>         case BPF_PROG_TYPE_EXT:
>                 if (expected_attach_type)
>
> > [...]
>

Reply via email to