mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Leon Hwang <leon.hwang@linux.dev>
To: bot+bpf-ci@kernel.org, sanghyun.park.cnu@gmail.com,
	ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	eddyz87@gmail.com, memxor@gmail.com, bpf@vger.kernel.org
Cc: john.fastabend@gmail.com, martin.lau@linux.dev, song@kernel.org,
	yonghong.song@linux.dev, jolsa@kernel.org, emil@etsalapatis.com,
	ihor.solodrai@linux.dev, shuah@kernel.org, sdf@fomichev.me,
	pulehui@huawei.com, suchitkarunakaran@gmail.com,
	xukuohai@huawei.com, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, martin.lau@kernel.org,
	mason@kernel.org
Subject: Re: [PATCH bpf-next v6 1/2] bpf: Validate program attach type during link update
Date: Mon, 7 Sep 2026 23:08:30 +0800	[thread overview]
Message-ID: <a44630a1-4965-4020-afb9-ba5b1a7848e6@linux.dev> (raw)
In-Reply-To: <514a0c26ff5e0322fe0442d07142cafc7dda338a3ce2c5b7e9437dd994cb0ba1@mail.kernel.org>

On 2026/9/7 10:36, bot+bpf-ci@kernel.org 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.

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	other threads:[~2026-09-07 15:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-07  1:50 Sanghyun Park
2026-09-07  1:50 ` [PATCH bpf-next v6 2/2] selftests/bpf: Cover attach type checks in " Sanghyun Park
2026-09-07  2:36 ` [PATCH bpf-next v6 1/2] bpf: Validate program attach type during " bot+bpf-ci
2026-09-07 15:08   ` Leon Hwang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a44630a1-4965-4020-afb9-ba5b1a7848e6@linux.dev \
    --to=leon.hwang@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bot+bpf-ci@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mason@kernel.org \
    --cc=memxor@gmail.com \
    --cc=pulehui@huawei.com \
    --cc=sanghyun.park.cnu@gmail.com \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=suchitkarunakaran@gmail.com \
    --cc=xukuohai@huawei.com \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®