Re: [PATCH bpf-next 12/13] landlock: Document the BPF kfunc interface

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The kfunc filter excessively restricts `bpf_landlock_put_ruleset`, contradicting the documented intent and severely limiting ruleset lifecycle management.
--

--- Patch [12]: [PATCH bpf-next 12/13] landlock: Document the BPF kfunc interface ---
commit f2d332c72e5178d7fb211de4b8685c5f171ac8da
Author: Justin Suess <utilityemal77@gmail.com>

landlock: Document the BPF kfunc interface

This commit adds documentation for the new Landlock BPF kfuncs. It describes
how a syscall program can acquire a ruleset from a file descriptor and pass it
via a map to a sleepable LSM BPF program for enforcement on an execution.

> diff --git a/Documentation/security/landlock.rst b/Documentation/security/landlock.rst
> index c5186526e76f6..01197c7580ec0 100644
> --- a/Documentation/security/landlock.rst
> +++ b/Documentation/security/landlock.rst
> @@ -129,6 +129,31 @@ The reasoning is:
>    restrictions, because access within the same scope is already
>    allowed based on ``LANDLOCK_ACCESS_FS_RESOLVE_UNIX``.
>  
> +BPF kfuncs
> +==========
> +
> +BPF programs can apply a userspace-created Landlock ruleset to an
> +execution.  A syscall program (``BPF_PROG_TYPE_SYSCALL``), running in
> +the context of the process that set the ruleset up, acquires the
> +ruleset from its file descriptor and typically hands it over through
> +a map kptr field; a sleepable LSM BPF program attached to the
> +``bprm_creds_for_exec`` or ``bprm_creds_from_file`` hooks then
> +enforces it on an execution.
> +
> +This can be used to inspect the runtime context of a pending execution,
> +and enforce a Landlock policy through BPF.
> +
> +The restriction is staged in the Landlock blob of the
> +credentials prepared for the execution and committed past the exec
> +point of no return, so a failed execution leaves the calling task
> +untouched.  The ``landlock_restrict_self(2)`` flags apply, with the
> +exception of ``LANDLOCK_RESTRICT_SELF_TSYNC``.
> +
> +.. kernel-doc:: kernel/bpf/bpf_lsm.c
> +    :identifiers: bpf_landlock_get_ruleset_from_fd
> +                  bpf_landlock_put_ruleset
> +                  bpf_landlock_restrict_binprm

[Severity: Medium]
Does the kfunc filter excessively restrict bpf_landlock_put_ruleset,
contradicting the documented intent?

Looking at bpf_landlock_kfunc_filter() in kernel/bpf/bpf_lsm.c, it appears
to apply -EACCES to bpf_landlock_put_ruleset for most program types and hooks:

kernel/bpf/bpf_lsm.c:bpf_landlock_kfunc_filter() {
	if (!btf_id_set8_contains(&bpf_landlock_kfunc_ids, kfunc_id))
		return 0;

	switch (prog->type) {
// ...
	case BPF_PROG_TYPE_LSM:
// ...
		if (!btf_id_set_contains(&bpf_landlock_kfunc_hooks,
					 prog->aux->attach_btf_id))
			return -EACCES;

		return 0;
	default:
		return -EACCES;
	}
}

This prevents BPF programs of types other than SYSCALL or two specific
sleepable LSM hooks from legitimately dropping a reference to a
bpf_landlock_ruleset they acquire from a map via bpf_kptr_xchg().

The verifier forces the program to drop the acquired reference, but rejects
the call to bpf_landlock_put_ruleset().

Additionally, looking at bpf_landlock_kfunc_ids:

kernel/bpf/bpf_lsm.c:
BTF_ID_FLAGS(func, bpf_landlock_put_ruleset, KF_RELEASE | KF_SLEEPABLE)

The KF_SLEEPABLE flag seems to prevent calling the release kfunc from
non-sleepable programs, even though the underlying release mechanism
(security_policy_kptr_put) is designed to support non-sleepable contexts.

Could this severely limit ruleset lifecycle management by making the kptr
functionally unusable across most BPF program types?

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