user/sven/linux.git/security/lsm_init.c, branch next/master

lsm: add backing_file LSM hooks

2026-04-03T20:53:50Z

Stacked filesystems such as overlayfs do not currently provide the necessary mechanisms for LSMs to properly enforce access controls on the mmap() and mprotect() operations. In order to resolve this gap, a LSM security blob is being added to the backing_file struct and the following new LSM hooks are being created: security_backing_file_alloc() security_backing_file_free() security_mmap_backing_file() The first two hooks are to manage the lifecycle of the LSM security blob in the backing_file struct, while the third provides a new mmap() access control point for the underlying backing file. It is also expected that LSMs will likely want to update their security_file_mprotect() callback to address issues with their mprotect() controls, but that does not require a change to the security_file_mprotect() LSM hook. There are a three other small changes to support these new LSM hooks: * Pass the user file associated with a backing file down to alloc_empty_backing_file() so it can be included in the security_backing_file_alloc() hook. * Add getter and setter functions for the backing_file struct LSM blob as the backing_file struct remains private to fs/file_table.c. * Constify the file struct field in the LSM common_audit_data struct to better support LSMs that need to pass a const file struct pointer into the common LSM audit code. Thanks to Arnd Bergmann for identifying the missing EXPORT_SYMBOL_GPL() and supplying a fixup. Cc: stable@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-unionfs@vger.kernel.org Cc: linux-erofs@lists.ozlabs.org Reviewed-by: Amir Goldstein Reviewed-by: Serge Hallyn Reviewed-by: Christian Brauner Signed-off-by: Paul Moore

lsm: preserve /proc/sys/vm/mmap_min_addr when !CONFIG_SECURITY

2026-01-29T18:56:53Z

While reworking the LSM initialization code the /proc/sys/vm/mmap_min_addr handler was inadvertently caught up in the change and the procfs entry wasn't setup when CONFIG_SECURITY was not selected at kernel build time. This patch restores the previous behavior and ensures that the procfs entry is setup regardless of the CONFIG_SECURITY state. Future work will improve upon this, likely by moving the procfs handler into the mm subsystem, but this patch should resolve the immediate regression. Fixes: 4ab5efcc2829 ("lsm: consolidate all of the LSM framework initcalls") Reported-by: Lorenzo Stoakes Reviewed-by: Lorenzo Stoakes Tested-by: Lorenzo Stoakes Reviewed-by: Kees Cook Signed-off-by: Paul Moore

lsm: use unrcu_pointer() for current->cred in security_init()

2025-11-19T15:32:06Z

We need to directly allocate the cred's LSM state for the initial task when we initialize the LSM framework. Unfortunately, this results in a RCU related type mismatch, use the unrcu_pointer() macro to handle this a bit more elegantly. The explicit type casting still remains as we need to work around the constification of current->cred in this particular case. Reviewed-by: Xiu Jianfeng Signed-off-by: Paul Moore

lsm: add a LSM_STARTED_ALL notification event

2025-10-22T23:24:29Z

Add a new LSM notifier event, LSM_STARTED_ALL, which is fired once at boot when all of the LSMs have been started. Reviewed-by: Kees Cook Reviewed-by: Casey Schaufler Reviewed-by: John Johansen Signed-off-by: Paul Moore

lsm: consolidate all of the LSM framework initcalls

2025-10-22T23:24:28Z

The LSM framework itself registers a small number of initcalls, this patch converts these initcalls into the new initcall mechanism. Reviewed-by: Casey Schaufler Reviewed-by: John Johansen Signed-off-by: Paul Moore

lsm: introduce an initcall mechanism into the LSM framework

2025-10-22T23:24:24Z

Currently the individual LSMs register their own initcalls, and while this should be harmless, it can be wasteful in the case where a LSM is disabled at boot as the initcall will still be executed. This patch introduces support for managing the initcalls in the LSM framework, and future patches will convert the existing LSMs over to this new mechanism. Only initcall types which are used by the current in-tree LSMs are supported, additional initcall types can easily be added in the future if needed. Reviewed-by: Kees Cook Reviewed-by: Casey Schaufler Reviewed-by: John Johansen Reviewed-by: Mimi Zohar Signed-off-by: Paul Moore

lsm: group lsm_order_parse() with the other lsm_order_*() functions

2025-10-22T23:24:24Z

Move the lsm_order_parse() function near the other lsm_order_*() functions to improve readability. No code changes. Reviewed-by: Casey Schaufler Reviewed-by: John Johansen Reviewed-by: Mimi Zohar Signed-off-by: Paul Moore

lsm: output available LSMs when debugging

2025-10-22T23:24:23Z

This will display all of the LSMs built into the kernel, regardless of if they are enabled or not. Reviewed-by: Casey Schaufler Reviewed-by: John Johansen Reviewed-by: Mimi Zohar Signed-off-by: Paul Moore

lsm: cleanup the debug and console output in lsm_init.c

2025-10-22T23:24:23Z

Move away from an init specific init_debug() macro to a more general lsm_pr()/lsm_pr_cont()/lsm_pr_dbg() set of macros that are available both before and after init. In the process we do a number of minor changes to improve the LSM initialization output and cleanup the code somewhat. Reviewed-by: Casey Schaufler Reviewed-by: John Johansen Signed-off-by: Paul Moore

lsm: add/tweak function header comment blocks in lsm_init.c

2025-10-22T23:24:23Z

Add function header comments for lsm_static_call_init() and early_security_init(), tweak the existing comment block for security_add_hooks(). Reviewed-by: Casey Schaufler Reviewed-by: John Johansen Signed-off-by: Paul Moore