[PATCH] Add LoadPin support for eBPF program loading

[Alex Roberts]

>This patch is pointless.
This was supposed to an RFC, but b4 complained when adding presubject "[RFC]".

Sorry about the bot build errors, tested against WSL config. Is there a standard config to build against for patches?

>- [High] The LoadPin eBPF trust mechanism can be trivially bypassed
>using standard system interpreters like the dynamic linker (`ld.so`).
>- [High] The LoadPin eBPF trust mechanism can be bypassed by a
>privileged attacker using prctl(PR_SET_MM_EXE_FILE).

As the intent was an RFC, is there any value in pursuing LoadPin for eBPF or is it so trivially bypassable its not worth it?

________________________________________
From: Alexei Starovoitov <alexei.starovoitov at gmail.com>
Sent: Friday, June 12, 2026 10:20 AM
To: David Windsor <dwindsor at gmail.com>
Cc: alex.roberts109 at outlook.com <alex.roberts109 at outlook.com>; Kees Cook <kees at kernel.org>; Paul Moore <paul at paul-moore.com>; James Morris <jmorris at namei.org>; Serge E . Hallyn <serge at hallyn.com>; LKML <linux-kernel at vger.kernel.org>; LSM List <linux-security-module at vger.kernel.org>; bpf <bpf at vger.kernel.org>; Alexei Starovoitov <ast at kernel.org>; KP Singh <kpsingh at kernel.org>
Subject: Re: [PATCH] Add LoadPin support for eBPF program loading
 
On Thu, Jun 11, 2026 at 5:08 PM David Windsor <dwindsor at gmail.com> wrote:
>
> On Thu, Jun 11, 2026 at 01:59:10PM -0500, Alex Roberts wrote:
> > +static int loadpin_bpf_prog_load(struct bpf_prog *prog, union bpf_attr *attr,
> > +                               struct bpf_token *token, bool is_kernel)
> > +{
> > +     int res = 0;
> > +     struct file *exe_file = NULL;
> > +     struct mm_struct *mm = current->mm;
> > +
> > +     if (is_kernel || !mm)
> > +             return 0;
> > +
> > +     exe_file = get_mm_exe_file(mm);
> > +     if (!exe_file)
> > +             return 0;
> > +
> > +     res = loadpin_check(exe_file, READING_EBPF);
>
> Why are we checking current here? IIUC this will be whoever calls
> bpf(2), which would be the loader, which would then be able to load bpf
> programs from an untrusted source.
>
> In the kmod case loadpin_check() sees the .ko itself.

See sashiko comments:
- [High] The LoadPin eBPF trust mechanism can be trivially bypassed
using standard system interpreters like the dynamic linker (`ld.so`).
- [High] The LoadPin eBPF trust mechanism can be bypassed by a
privileged attacker using prctl(PR_SET_MM_EXE_FILE).

and the bot is correct.
This patch is pointless.