[PATCH bpf-next v3 2/6] bpf: Verify signed loader metadata at load time

Alexei Starovoitov alexei.starovoitov at gmail.com
Thu Jul 2 22:33:04 UTC 2026


On Thu Jul 2, 2026 at 3:05 PM PDT, Paul Moore wrote:
>
> As I mentioned previously, the security_bpf_prog_load() hook should
> not be moved.  Its placement was deliberate, and moving it as you've
> done in this patch creates a security regression. 

not true.

> Without this patch,
> for processes where SELinux is preventing BPF programs from being
> loaded, it is able to do so before the process allocates a potentially
> very large chunk of kernel memory, up to one million BPF instructions.

only when signature verification is requested and the hash over insns
is what your hornet thingy did too.
So no regression whatsoever. Exact same behavior.

> With this patch, even in cases where SELinux will prevent the BPF
> program load operation, it is not able to do so before the process
> triggers a potential sizable memory allocation, opening the door for a
> local DoS attack.

Not true either. Worst case is 1M which is 8Mbyte.
Not even close to anything DoS worthy.

> In an effort to work with you on this, I did bring up two alternative
> solutions: a new LSM hook for the signature verification, or the use
> of the existing security_bpf_prog() hook. 

Sorry we're not going to add new hook because Paul has
non-technical grudge against bpf.

> While I don't like to do this, you haven't given me much of a choice;
> the security regression can not be ignored:
>
>  Nacked-by: Paul Moore (don't move bpf_prog_load LSM hook) <paul at paul-moore.com>

of course. will keep it and let Linus decide during the merge window.



More information about the Linux-security-module-archive mailing list