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

On Fri, Jul 31, 2026 at 02:45:50AM +0000, [email protected] wrote:
> 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.
>
> [...]
>
> [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 repeated this same feedback a few times.

It seems reasonable.

I don't see why the bpf_landlock_put_ruleset's allowed calling context
can't be broadened out.

It's probably ok to allow it for all BPF_PROG_TYPE_LSM programs
(including non-sleepable ones) in addition to BPF_PROG_TYPE_SYSCALL, and
drop KF_SLEEPABLE in accordance with the security_policy_kptr_put docs
stating that the hook consumer cannot sleep.

Same goes for the bpf_landlock_ruleset dtor.

Justin

> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=12