From: sashiko-bot@kernel.org
To: "Thiébaud Weksteen" <tweek@google.com>
Cc: bpf@vger.kernel.org, selinux@vger.kernel.org
Subject: Re: [PATCH bpf-next 4/5] selinux: Add BPF_LOADER_LOAD_FD syscall permission
Date: Thu, 13 Aug 2026 00:41:35 +0000 [thread overview]
Message-ID: <20260813004136.2A2E01F00A3F@smtp.kernel.org> (raw)
In-Reply-To: <20260813002618.3755631-5-tweek@google.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] The SELinux access control check for BPF_LOADER_LOAD_FD is completely bypassed if the bpf_token_perms policy capability is enabled, leading to Privilege Escalation.
Pre-existing issues:
- [High] BPF_LOADER_LOAD_FD fails unconditionally with -EINVAL if CONFIG_BPF_JIT is disabled.
--
--- Patch [4]: [PATCH bpf-next 4/5] selinux: Add BPF_LOADER_LOAD_FD syscall permission ---
commit aa42284da62cb224bfd501dfd4306e6584b6a8e1
Author: Thiébaud Weksteen <tweek@google.com>
selinux: Add BPF_LOADER_LOAD_FD syscall permission
Add the BPF_LOADER_LOAD_FD permission to gate the bpf syscall command of
the same name.
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index e7c5993f69545..b4ff5ea5306df 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -7196,6 +7196,10 @@ static int selinux_bpf(int cmd, union bpf_attr *attr,
> ret = avc_has_perm(sid, sid, SECCLASS_BPF, BPF__PROG_LOAD,
> NULL);
> break;
> + case BPF_LOADER_LOAD_FD:
> + ret = avc_has_perm(sid, sid, SECCLASS_BPF, BPF__LOADER_LOAD_FD,
> + NULL);
> + break;
[Severity: High]
Is it possible this check can be completely bypassed if the bpf_token_perms
policy capability is enabled?
Looking at selinux_bpf() earlier in this file, there is an early return:
if (selinux_policycap_bpf_token_perms())
return 0;
Because BPF_LOADER_LOAD_FD doesn't have a fine-grained SELinux hook later on,
this early return skips the access control check.
Furthermore, loader_load_fd() internally calls kern_sys_bpf() which executes
the inner map creations and program loads with is_kernel = true:
return __sys_bpf(cmd, KERNEL_BPFPTR(attr), attr_size, KERNEL_BPFPTR(NULL), 0);
This passes the kernel SID (SECINITSID_KERNEL) to the fine-grained hooks
instead of the user's SID:
ssid = kernel ? SECINITSID_KERNEL : bpfsec->sid;
Will this allow a user with CAP_BPF to bypass their SELinux constraints and
load arbitrary programs as the kernel?
[Severity: High]
This isn't a bug introduced by this patch, but will BPF_LOADER_LOAD_FD fail
unconditionally if CONFIG_BPF_JIT is disabled?
Looking at loader_load_fd() in kernel/bpf/syscall.c, it unconditionally calls:
err = kern_sys_bpf(BPF_PROG_TEST_RUN, &sattr, sizeof(sattr));
However, in kern_sys_bpf(), the BPF_PROG_TEST_RUN case is compiled out when
CONFIG_BPF_JIT is disabled:
#ifdef CONFIG_BPF_JIT
case BPF_PROG_TEST_RUN:
This causes it to fall through to the default handler which returns -EINVAL for
BPF_PROG_TEST_RUN, breaking the feature entirely on non-JIT configurations.
> default:
> ret = 0;
> break;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813002618.3755631-1-tweek@google.com?part=4
next prev parent reply other threads:[~2026-08-13 0:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 0:26 [PATCH bpf-next 0/5] bpf: Introduce LOADER_LOAD_FD Thiébaud Weksteen
2026-08-13 0:26 ` [PATCH bpf-next 1/5] fs/kernel_read_file,selinux: Add BPF_LOADER constant Thiébaud Weksteen
2026-08-13 0:36 ` sashiko-bot
2026-08-13 1:25 ` bot+bpf-ci
2026-08-13 0:26 ` [PATCH bpf-next 2/5] bpf: Introduce BPF_LOADER_LOAD_FD command Thiébaud Weksteen
2026-08-13 0:42 ` sashiko-bot
2026-08-13 1:40 ` bot+bpf-ci
2026-08-13 0:26 ` [PATCH bpf-next 3/5] selinux: use kernel sid in security_bpf_* Thiébaud Weksteen
2026-08-13 0:40 ` sashiko-bot
2026-08-13 1:25 ` bot+bpf-ci
2026-08-13 0:26 ` [PATCH bpf-next 4/5] selinux: Add BPF_LOADER_LOAD_FD syscall permission Thiébaud Weksteen
2026-08-13 0:41 ` sashiko-bot [this message]
2026-08-13 0:26 ` [PATCH bpf-next 5/5] selftests/bpf: add loader_load_fd tests Thiébaud Weksteen
2026-08-13 0:36 ` sashiko-bot
2026-08-13 1:25 ` bot+bpf-ci
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=20260813004136.2A2E01F00A3F@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=selinux@vger.kernel.org \
--cc=tweek@google.com \
/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