[BUG] bpf, lsm: new first argument in 7.4 inode hooks silently breaks BPF LSMs

[BUG] bpf, lsm: new first argument in 7.4 inode hooks silently breaks BPF LSMs

[roblabla]

Resubmitting as plain text. Sorry for the noise.

Hello,
First of all, I'm sorry if I'm sending this email to the wrong mailing lists, it's my first time reporting a linux issue ^^'.

In commit 16959c469f232f5c76cfb628297cafbf6dbdba79 (lsm: expose mount idmaps to inode hooks), merged in 7.4-rc1, a new argument was added in position 0 of various inode-related `security_` functions. Specifically, it added this argument to inode_create, inode_link, inode_symlink, inode_mkdir, inode_mknod and inode_permission.

This has the immediate effect of breaking eBPF LSM programs relying on these hooks that were compiled with BPF CO-RE and using BPF_CORE_READ. Those programs don't simply stop loading (which would be fine enough) - instead, they will misinterpret the argument from one type to another, which can cause them to behave erratically. This has already bitten me in the past, when inode_setattr got a similar argument change in Linux 6.9. This caused our eBPF LSM to misbehave and deny actions that should have been ordinarily accepted, leading to huge production outages on our customers' machines.

Here's a simple reproducer that shows the problem (full repro with the loader, makefile and run.sh is at https://github.com/roblabla/kernel-7.4-bpf-bug-reproducer):

```
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <bpf/bpf_core_read.h>

char LICENSE[] SEC("license") = "GPL";

#define EPERM 1
#define NAME_LEN 32

static const char forbidden[] = "forbidden";

SEC("lsm/inode_create")
int BPF_PROG(deny_forbidden, struct inode *dir, struct dentry *dentry)
{
    char name[NAME_LEN] = {};
    const unsigned char *name_ptr;
    unsigned long dir_ino;

    dir_ino = BPF_CORE_READ(dir, i_ino);
    name_ptr = BPF_CORE_READ(dentry, d_name.name);
    bpf_probe_read_kernel_str(name, sizeof(name), name_ptr);

    bpf_printk("inode_create: dir ino=%lu name='%s'", dir_ino, name);

    for (int i = 0; i < sizeof(forbidden); i++)
        if (name[i] != forbidden[i])
            return 0;

    bpf_printk("inode_create: denied '%s'", name);
    return -EPERM;
}
```

Compile it under a kernel before 7.4 release, then run it on mainline. Here's the output:

- run on 7.1-rc7:  touch forbidden: DENIED   (dir ino=59 name='forbidden')
- run on 7.4-rc1:  touch forbidden: created  (dir ino=0 name='')

Before Linux 7.4, this program will properly deny the creation of any file named "forbidden". But in 7.4, the name_ptr BPF_CORE_READ will read garbage, and the check will fail. This is a bit of a contrived example, of course, but should show that there's a real problem in the way we handle eBPF loading in the face of changing signatures, that is prone to causing big compatibility issues.

Now, I'm not sure how the Linux Kernel treats eBPF LSM hooks - if they're considered part of the userspace that shouldn't be broken. My understanding is that kprobes are not part of the Linux Kernel stability guarantees, for rather obvious reasons (they allow watching the internals of the kernel) - but I'm not sure if this extends to the LSM Hooks. I assume not. Still, this kind of breakage is really painful for us, and I hope we can find a solution.

Could we fix this type of breakage by making sure new arguments are only added at the _end_ of the LSM hooks signatures, such that eBPF written for an older version of the kernel do not start misinterpreting arguments? eBPFs don't care about having "too few" arguments in the hook, so this would solve the situation.

Separately, I think the current lack of error handling in case of argument mismatch should really be improved. Could we perhaps have a mechanism such that the kernel (or maybe libbpf?) could check the arguments of the eBPF program, and refuse loading if it mismatches what the kernel expects?

Thanks,
roblabla

Re: [BUG] bpf, lsm: new first argument in 7.4 inode hooks silently breaks BPF LSMs

[Paul Moore]

On Fri, Nov 6, 2026 at 8:39 AM roblabla <linux@roblab.la> wrote:
>
> Hello,
> First of all, I'm sorry if I'm sending this email to the wrong mailing lists, it's my first time reporting a linux issue ^^'.

Hi,

It looks like you sent this email to the right people/lists, well done
on the first hurdle :)

> In commit 16959c469f232f5c76cfb628297cafbf6dbdba79 (lsm: expose mount idmaps to inode hooks), merged in 7.4-rc1, a new argument was added in position 0 of various inode-related `security_` functions. Specifically, it added this argument to inode_create, inode_link, inode_symlink, inode_mkdir, inode_mknod and inode_permission.
>
> This has the immediate effect of breaking eBPF LSM programs relying on these hooks that were compiled with BPF CO-RE and using BPF_CORE_READ.

...

> Now, I'm not sure how the Linux Kernel treats eBPF LSM hooks - if they're considered part of the userspace that shouldn't be broken. My understanding is that kprobes are not part of the Linux Kernel stability guarantees, for rather obvious reasons (they allow watching the internals of the kernel) - but I'm not sure if this extends to the LSM Hooks. I assume not. Still, this kind of breakage is really painful for us, and I hope we can find a solution.

Like kprobes, the LSM hooks are intentionally not part of any stable
API promise.  While we try not to needlessly churn the LSM hooks, we
reserve the right to modify parameters, the LSM callbacks associated
with a hook, and even the basic hook semantics from one kernel release
to another.  The reasoning is very similar to that of kprobes: the LSM
hooks are linked to kernel internals and thus need the ability to
change as the kernel changes.

LSMs that need to provide a stable API must provide an abstraction
layer between the LSM hook callbacks and their stable API.  The LSM
framework is not responsible for the stability of individual LSM APIs.

> Could we fix this type of breakage by making sure new arguments are only added at the _end_ of the LSM hooks signatures,

I'm sorry, but I can't make that promise at the LSM framework layer.
It is impossible to predict how the kernel internals will continue to
evolve and thus I can't promise how the LSM hooks and callbacks will
need to change as a result.

Regarding the specifics of how the BPF LSM has dealt with this in the
past, and any plans for the future, I'll let others speak to that;
hopefully they will have some tricks you can use to make these
transitions easier.

--
paul-moore.com