linux-kernel - Re: [PATCH bpf] bpf: 'fix' for undefined future potential exploits of BPF_PROG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQJXdRiNpDAqoKotq5PrbCVbQbztzK_QDbLMJqZzcmy6zw@mail.gmail.com>
Date: Fri, 2 Jan 2026 16:14:46 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Maciej Żenczykowski <maze@...gle.com>
Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Linux Network Development Mailing List <netdev@...r.kernel.org>, "David S . Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, BPF Mailing List <bpf@...r.kernel.org>, 
	John Fastabend <john.fastabend@...il.com>
Subject: Re: [PATCH bpf] bpf: 'fix' for undefined future potential exploits of BPF_PROG_LOAD

On Wed, Dec 31, 2025 at 4:57 PM Maciej Żenczykowski <maze@...gle.com> wrote:
>
> On Thu, Jan 1, 2026 at 1:07 AM Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
> >
> > On Wed, Dec 31, 2025 at 3:21 PM Maciej Żenczykowski <maze@...gle.com> wrote:
> > >
> > > Over the years there's been a number of issues with the eBPF
> > > verifier/jit/codegen (incl. both code bugs & spectre related stuff).
> > >
> > > It's an amazing but very complex piece of logic, and I don't think
> > > it's realistic to expect it to ever be (or become) 100% secure.
> > >
> > > For example we currently have KASAN reporting buffer length violation
> > > issues on 6.18 (which may or may not be due to eBPF subsystem, but are
> > > worrying none-the-less)
> > >
> > > Blocking bpf(BPF_PROG_LOAD, ...) is the only sure fire way to guarantee
> > > the inability to exploit the eBPF subsystem.
> > > In comparison other eBPF operations are pretty benign.
> > > Even map creation is usually at most a memory DoS, furthermore it
> > > remains useful (even with prog load disabled) due to inner maps.
> > >
> > > This new sysctl is designed primarily for verified boot systems,
> > > where (while the system is booting from trusted/signed media)
> > > BPF_PROG_LOAD can be enabled, but before untrusted user
> > > media is mounted or networking is enabled, BPF_PROG_LOAD
> > > can be outright disabled.
> > >
> > > This provides for a very simple way to limit eBPF programs to only
> > > those signed programs that are part of the verified boot chain,
> > > which has always been a requirement of eBPF use in Android.
> > >
> > > I can think of two other ways to accomplish this:
> > > (a) via sepolicy with booleans, but it ends up being pretty complex
> > >     (especially wrt verifying the correctness of the resulting policies)
> > > (b) via BPF_LSM bpf_prog_load hook, which requires enabling additional
> > >     kernel options which aren't necessarily worth the bother,
> > >     and requires dynamically patching the kernel (frowned upon by
> > >     security folks).
> > >
> > > This approach appears to simply be the most trivial.
> >
> > You seem to ignore the existence of sysctl_unprivileged_bpf_disabled.
> > And with that the CAP_BPF is the only way to prog_load to work.
>
> I am actually aware of it, but we cannot use sysctl_unprivileged_bpf_disabled,
> because (last I checked) it disables map creation as well,

yes, because we had bugs in maps too. prog_load has a bigger
bug surface, but map_create can have issues too.

> which we do
> want to function
> as less privileged (though still partially priv) daemons/users (for
> inner map creation)...
>
> Additionally the problem is there is no way to globally block CAP_BPF...
> because CAP_SYS_ADMIN (per documentation, and backwards compatibility)
> implies it, and that has valid users.
>
> > I suspect you're targeting some old kernels.
>
> I don't believe so.  How are you suggesting we globally block BPF_PROG_LOAD,
> while there will still be some CAP_SYS_ADMIN processes out of necessity,
> and without blocking map creation?

Sounds like you don't trust root, yet believe that map_create is safe
for unpriv?!
I cannot recommend such a security posture to anyone.
Use LSM to block prog_load or use bpf token with userns for fine grained access.