Re: [PATCH v3 1/2] bpf: render CGROUP_LSM_NUM configurable as a KConfig

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Increasing CONFIG_CGROUP_LSM_NUM to its maximum value (300) causes an excessive stack allocation in cgroup_bpf_inherit(), which will trigger a FRAME_WARN build failure and risks stack overflow.
--

commit 33800a93ec2833bc433c78926307347450251cdb
Author: Paul Houssel <paulhoussel2@gmail.com>

bpf: render CGROUP_LSM_NUM configurable as a KConfig

This commit makes the maximum number of concurrently attachable per-cgroup
LSM hooks configurable at build time via the new CONFIG_CGROUP_LSM_NUM
option. It allows the value to be tuned from 0 to 300, replacing the
previous hardcoded limit of 10.

> diff --git a/include/linux/bpf-cgroup-defs.h b/include/linux/bpf-cgroup-defs.h
> index c9e6b26abab6d..9ab5ca3dbaba3 100644
> --- a/include/linux/bpf-cgroup-defs.h
> +++ b/include/linux/bpf-cgroup-defs.h

[ ... ]

>  #ifdef CONFIG_BPF_LSM
>  /* Maximum number of concurrently attachable per-cgroup LSM hooks. */
> -#define CGROUP_LSM_NUM 10
> +#define CGROUP_LSM_NUM CONFIG_CGROUP_LSM_NUM
>  #else
>  #define CGROUP_LSM_NUM 0
>  #endif

> diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
> index eb3de35734f09..050af0b72651d 100644
> --- a/kernel/bpf/Kconfig
> +++ b/kernel/bpf/Kconfig

[ ... ]

> +config CGROUP_LSM_NUM
> +	int "Maximum number of per-cgroup LSM hooks"
> +	depends on BPF_LSM
> +	depends on CGROUP_BPF
> +	range 0 300

If this is configured to the maximum value of 300, could this cause a
regression by overflowing the kernel stack in cgroup_bpf_inherit()?

In include/linux/bpf-cgroup-defs.h, MAX_CGROUP_BPF_ATTACH_TYPE scales
dynamically based on CGROUP_LSM_NUM. At 300, MAX_CGROUP_BPF_ATTACH_TYPE
grows to 328 (28 base hooks + 300).

In kernel/bpf/cgroup.c, cgroup_bpf_inherit() computes NR as
ARRAY_SIZE(cgrp->bpf.effective) and declares a local stack array:

kernel/bpf/cgroup.c:cgroup_bpf_inherit() {
        ...
        #define NR ARRAY_SIZE(cgrp->bpf.effective)
        struct bpf_prog_array *arrays[NR] = {};
        ...
}

On 64-bit architectures, this array of pointers would consume 2624 bytes
(328 * 8) on the stack. Does this exceed the standard CONFIG_FRAME_WARN
limits and risk build failures or runtime stack overflows?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260506150547.767315-1-paulhoussel2@gmail.com?part=1