[PATCH] lsm,bpf: fix security_bpf_prog_load() error handling

[Alexei Starovoitov]

On Sat, May 23, 2026 at 6:53 PM Paul Moore <paul at paul-moore.com> wrote:
>
> On May 23, 2026 11:25:55 AM Alexei Starovoitov
> <alexei.starovoitov at gmail.com> wrote:
> > On Sat, May 23, 2026 at 6:06 PM Paul Moore <paul at paul-moore.com> wrote:
> >> On Sat, May 23, 2026 at 12:00 PM Paul Moore <paul at paul-moore.com> wrote:
> >>>
> >>> If security_bpf_prog_load() fails there is no need to call into
> >>> security_bpf_prog_free() as the LSM will handle the cleanup of any partial
> >>> LSM state before returning to the caller with an error.  Thankfully this
> >>> isn't an issue with any of the existing code as the LSMs which currently
> >>> provide BPF hook callback implementations don't allocate any internal
> >>> state, but this is something we want to fix for potential future users.
> >>>
> >>> Cc: bpf at vger.kernel.org
> >>> Cc: linux-security-module at vger.kernel.org
> >>> Signed-off-by: Paul Moore <paul at paul-moore.com>
> >>> ---
> >>> kernel/bpf/syscall.c | 4 +---
> >>> 1 file changed, 1 insertion(+), 3 deletions(-)
> >>
> >> Alexei, I'm assuming you would prefer to take this via the BPF tree?
> >
> > Paul, I see that you're intentionally trying to piss me off.
> > It's not going to work :)
>
> I promise you that is not the case. I was looking at the sashiko results of
> the latest Hornet patch and it identified this potential issue in the error
> handling code that is an issue independent of Hornet. I posted the quick
> little patch above to fix the issue, and since the diffstat is solely in
> kernel/bpf/syscall.c I figured you would want to merge it via the BPF tree;
> if that is not the case let me know.

It's in a queue. You can monitor it here:
https://patchwork.kernel.org/project/netdevbpf/list/?series=&submitter=&state=&q=&archive=&delegate=121173

But please be advised that when submitters ignore issues
found by bots and maintainers agree with bot findings
we mark patches as changes requested.