> diff --git a/fs/bpf_fs_kfuncs.c b/fs/bpf_fs_kfuncs.c
> index e4e51a1d0de2..38b1b54d14c6 100644
> --- a/fs/bpf_fs_kfuncs.c
> +++ b/fs/bpf_fs_kfuncs.c

[ ... ]

> @@ -353,6 +354,97 @@ __bpf_kfunc int bpf_cgroup_read_xattr(struct cgroup 
> *cgroup, const char *name__s
>  }
>  #endif /* CONFIG_CGROUPS */
>
> +static int bpf_xattrs_used(const struct lsm_xattr_ctx *ctx)
> +{
> +     const size_t prefix_len = sizeof(XATTR_BPF_LSM_SUFFIX) - 1;
> +     int i, n = 0;
> +
> +     for (i = 0; i < *ctx->xattr_count; i++) {
> +             const char *name = ctx->xattrs[i].name;
> +
> +             if (name && !strncmp(name, XATTR_BPF_LSM_SUFFIX, prefix_len))
> +                     n++;
> +     }
> +     return n;
> +}
> +
> +static int __bpf_init_inode_xattr(struct lsm_xattr_ctx *xattr_ctx,
> +                               const char *name__str,
> +                               const struct bpf_dynptr *value_p)
> +{
> +     struct bpf_dynptr_kern *value_ptr = (struct bpf_dynptr_kern *)value_p;
> +     size_t name_len;
> +     void *xattr_value;
> +     struct xattr *xattr;
> +     struct xattr *xattrs;
> +     int *xattr_count;
> +     const void *value;
> +     u32 value_len;
> +
> +     if (!xattr_ctx || !name__str)
> +             return -EINVAL;
> +
> +     xattrs = xattr_ctx->xattrs;
> +     xattr_count = xattr_ctx->xattr_count;
> +     if (!xattrs || !xattr_count)
> +             return -EINVAL;
> +     if (bpf_xattrs_used(xattr_ctx) >= BPF_LSM_INODE_INIT_XATTRS)
> +             return -ENOSPC;

With only 1 xattr slot reserved (BPF_LSM_INODE_INIT_XATTRS = 1), can
multiple BPF LSM programs coexist safely? Paul Moore raised this concern
in v2, noting that with the BPF LSM only reserving a single xattr slot,
multiple loaded BPF LSM programs providing security_inode_init_security()
callbacks will be a problem.

Song Liu acknowledged this issue and noted that even a single BPF LSM
function may call the kfunc multiple times, which is also problematic.
He suggested increasing the default and introducing a realloc mechanism
for the worst case scenario.

The check at this point returns -ENOSPC if the slot is already used, but
is there proper coordination between multiple BPF programs to prevent
slot conflicts?

Reference: 
https://lore.kernel.org/bpf/cahc9vhsy5k5nqttfue4bscy1ur61v7ezw067vtcuydqejb1...@mail.gmail.com/

> +
> +     name_len = strlen(name__str);
> +     if (name_len == 0 || name_len > XATTR_NAME_MAX)
> +             return -EINVAL;
> +     if (strncmp(name__str, XATTR_BPF_LSM_SUFFIX,
> +                 sizeof(XATTR_BPF_LSM_SUFFIX) - 1))
> +             return -EPERM;
> +
> +     value_len = __bpf_dynptr_size(value_ptr);
> +     if (value_len == 0 || value_len > XATTR_SIZE_MAX)
> +             return -EINVAL;
> +
> +     value = __bpf_dynptr_data(value_ptr, value_len);
> +     if (!value)
> +             return -EINVAL;
> +
> +     /* Combine xattr value + name into one allocation. */
> +     xattr_value = kmalloc(value_len + name_len + 1, GFP_KERNEL);
> +     if (!xattr_value)
> +             return -ENOMEM;
> +
> +     memcpy(xattr_value, value, value_len);
> +     memcpy(xattr_value + value_len, name__str, name_len);
> +     ((char *)xattr_value)[value_len + name_len] = '\0';
> +
> +     xattr = lsm_get_xattr_slot(xattr_ctx);
> +     if (!xattr) {
> +             kfree(xattr_value);
> +             return -ENOSPC;
> +     }
> +
> +     xattr->value = xattr_value;
> +     xattr->name = (const char *)xattr_value + value_len;
> +     xattr->value_len = value_len;
> +
> +     return 0;
> +}

[ ... ]

> diff --git a/include/linux/bpf_lsm.h b/include/linux/bpf_lsm.h
> index 643809cc78c3..b97a3d79529d 100644
> --- a/include/linux/bpf_lsm.h
> +++ b/include/linux/bpf_lsm.h
> @@ -19,6 +19,9 @@
>  #include <linux/lsm_hook_defs.h>
>  #undef LSM_HOOK
>
> +/* max bpf xattrs per inode */
> +#define BPF_LSM_INODE_INIT_XATTRS 1
> +

[ ... ]


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25639388555

Reply via email to