* Re: [PATCH] lsm: hold cred_guard_mutex for lsm_set_self_attr()
From: John Johansen @ 2026-06-13 23:29 UTC (permalink / raw)
To: Paul Moore, Stephen Smalley, selinux
Cc: omosnace, casey, serge, linux-security-module
In-Reply-To: <b99c011e6d988fb98ad017265115b323@paul-moore.com>
On 5/14/26 13:47, Paul Moore wrote:
> On May 13, 2026 Stephen Smalley <stephen.smalley.work@gmail.com> wrote:
>>
>> Just as proc_pid_attr_write() already does before calling the LSM
>> hook. This only matters for SELinux and AppArmor which check
>> whether the process is being ptraced and if so, whether to
>> allow the transition.
>>
>> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
>> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
>> ---
>> security/lsm_syscalls.c | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> Thanks Stephen. I'm going to merge this into lsm/stable-7.1 now, but
> hold on to it until next week before sending it to Linus. While I
> can't see why John would have any objections to this, the extra time
> should give him a chance to respond.
>
you would think?
well finally getting this far back the backlog (sorry)
no objections
^ permalink raw reply
* [PATCH] KEYS: avoid filesystem reclaim while holding keyring->sem
From: Mohammed EL Kadiri @ 2026-06-14 15:00 UTC (permalink / raw)
To: dhowells, jarkko, paul
Cc: jmorris, serge, ebiggers, keyrings, linux-security-module,
linux-kernel, stable, syzkaller-bugs, Mohammed EL Kadiri,
syzbot+f55b043dacf43776b50c
__key_link_begin() runs with keyring->sem held and calls
assoc_array_insert(), which does GFP_KERNEL allocations. Those
allocations may enter filesystem reclaim, evict an fscrypt-protected
inode, and reach keyring_clear() via fscrypt_put_master_key() --
taking a keyring semaphore of the same lockdep class and closing a
keyring->sem -> fs_reclaim -> keyring->sem cycle reported by syzbot.
Wrap the assoc_array_insert() call with memalloc_nofs_save() /
memalloc_nofs_restore() so reclaim cannot recurse into the keys
subsystem while keyring->sem is held.
Reported-by: syzbot+f55b043dacf43776b50c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c
Fixes: d7e7b9af104c ("fscrypt: stop using keyrings subsystem for fscrypt_master_key")
Cc: stable@vger.kernel.org
Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
---
security/keys/keyring.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/security/keys/keyring.c b/security/keys/keyring.c
index 5a9887d6b7be..21bb2e7e7cca 100644
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -12,6 +12,7 @@
#include <linux/security.h>
#include <linux/seq_file.h>
#include <linux/err.h>
+#include <linux/sched/mm.h>
#include <linux/user_namespace.h>
#include <linux/nsproxy.h>
#include <keys/keyring-type.h>
@@ -1298,6 +1299,7 @@ int __key_link_begin(struct key *keyring,
struct assoc_array_edit **_edit)
{
struct assoc_array_edit *edit;
+ unsigned int nofs_flags;
int ret;
kenter("%d,%s,%s,",
@@ -1315,10 +1317,12 @@ int __key_link_begin(struct key *keyring,
/* Create an edit script that will insert/replace the key in the
* keyring tree.
*/
+ nofs_flags = memalloc_nofs_save();
edit = assoc_array_insert(&keyring->keys,
&keyring_assoc_array_ops,
index_key,
NULL);
+ memalloc_nofs_restore(nofs_flags);
if (IS_ERR(edit)) {
ret = PTR_ERR(edit);
goto error;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] lsm: hold cred_guard_mutex for lsm_set_self_attr()
From: Paul Moore @ 2026-06-14 20:25 UTC (permalink / raw)
To: John Johansen
Cc: Stephen Smalley, selinux, omosnace, casey, serge,
linux-security-module
In-Reply-To: <1c87912e-7d7c-49a9-b964-3568e63e74a0@canonical.com>
On Sat, Jun 13, 2026 at 7:29 PM John Johansen
<john.johansen@canonical.com> wrote:
> On 5/14/26 13:47, Paul Moore wrote:
> > On May 13, 2026 Stephen Smalley <stephen.smalley.work@gmail.com> wrote:
> >>
> >> Just as proc_pid_attr_write() already does before calling the LSM
> >> hook. This only matters for SELinux and AppArmor which check
> >> whether the process is being ptraced and if so, whether to
> >> allow the transition.
> >>
> >> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> >> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
> >> ---
> >> security/lsm_syscalls.c | 9 ++++++++-
> >> 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > Thanks Stephen. I'm going to merge this into lsm/stable-7.1 now, but
> > hold on to it until next week before sending it to Linus. While I
> > can't see why John would have any objections to this, the extra time
> > should give him a chance to respond.
> >
> you would think?
> well finally getting this far back the backlog (sorry)
>
> no objections
A review is almost always better late than never ;) Thanks for taking a look.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 v2] evm: check return values of crypto_shash functions
From: Roberto Sassu @ 2026-06-15 7:25 UTC (permalink / raw)
To: Mimi Zohar, Daniel Hodges
Cc: roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, linux-integrity, linux-security-module, linux-kernel
In-Reply-To: <c1d570271884159e6c14617fa7dcd39bc2103e45.camel@linux.ibm.com>
On 3/9/2026 4:03 PM, Mimi Zohar wrote:
> On Thu, 2026-02-19 at 10:26 +0100, Roberto Sassu wrote:
>> On Thu, 2026-02-05 at 21:42 -0500, Daniel Hodges wrote:
>>> The crypto_shash_update() and crypto_shash_final() functions can fail
>>> and return error codes, but their return values were not being checked
>>> in several places in security/integrity/evm/evm_crypto.c:
>>>
>>> - hmac_add_misc() ignored returns from crypto_shash_update() and
>>> crypto_shash_final()
>>> - evm_calc_hmac_or_hash() ignored returns from crypto_shash_update()
>>> - evm_init_hmac() ignored returns from crypto_shash_update()
>>>
>>> If these hash operations fail silently, the resulting HMAC could be
>>> invalid or incomplete, which could weaken the integrity verification
>>> security that EVM provides.
>>>
>>> This patch converts hmac_add_misc() from void to int return type and
>>> adds proper error checking and propagation for all crypto_shash_*
>>> function calls. All callers are updated to handle the new return values.
>>> Additionally, error messages are logged when cryptographic operations
>>> fail to provide visibility into the failure rather than silently
>>> returning error codes.
>>>
>>> Fixes: 66dbc325afce ("evm: re-release")
>>> Signed-off-by: Daniel Hodges <git@danielhodges.dev>
>>
>> After fixing the minor issue below:
>>
>> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com>
>
> Thanks Daniel, Roberto. Daniel there are a couple of places where the line
> length is greater than 80. To see them, add "--max-line-length=80" to
> scripts/checkpatch.pl. I'd appreciate your fixing them. Otherwise, the patch
> looks good.
Daniel, do you have time to fix the style issues, so that we upstream
your patch?
Thanks
Roberto
^ permalink raw reply
* Re: [PATCH] keys: allow request-key path to be configured via Kconfig
From: Jarkko Sakkinen @ 2026-06-15 11:49 UTC (permalink / raw)
To: Gary Guo
Cc: David Howells, Paul Moore, James Morris, Serge E. Hallyn,
keyrings, linux-security-module, linux-kernel
In-Reply-To: <DJ5ES5DZ15W8.2KLL7VS1JMQOE@garyguo.net>
On Wed, Jun 10, 2026 at 02:37:41PM +0100, Gary Guo wrote:
> On Wed Jun 10, 2026 at 1:57 PM BST, Jarkko Sakkinen wrote:
> > On Mon, Jun 08, 2026 at 11:30:06AM +0100, Gary Guo wrote:
> >>
> >> This is really just for distros to be able to configure where /sbin is located.
> >> Given usr merge and (some distros) bin/sbin merge, the canonical path of
> >> request-key binary is very likely not /sbin/request-key anymore, so it seems to
> >> make sense to me to allow this to be changed rather than always go through
> >> compatibility symlinks.
> >
> > I doubt there's a huge demand other than NixOS. Just basing this on that
> > no other noise have been made so far.
>
> Just to add on this, both Fedora and openSUSE for example changes their
> CONFIG_MODPROBE_PATH to be /usr/sbin/modprobe after /usr merge. They still have
> the /sbin -> /usr/sbin symlink available, so it's not like they cannot work with
> /sbin/request-key, but I would think that if the option is available then they
> might switch to use /usr/sbin/request-key, too.
>
> After all, why would one perform a symlink walk for no reason?
>
> Best,
> Gary
It's not who is right or who is wrong. "The representation
of the argument" is not working here.
Back to the drawing board...
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: Pin request_key_auth payload in instantiate paths
From: Jarkko Sakkinen @ 2026-06-15 11:53 UTC (permalink / raw)
To: eee sss
Cc: keyrings, linux-security-module, linux-kernel, David Howells,
Paul Moore, James Morris, Serge E. Hallyn
In-Reply-To: <CA+TOyfjifw5yiZwUmd3y7t227cTMpXxT_JNe0FSO-NYzhqE75Q@mail.gmail.com>
Awesome, no worries, great to hear, and thank you for responding.
And great collaboration :-)
BR, Jarkko
On Wed, Jun 10, 2026 at 10:21:13AM -0500, eee sss wrote:
> Thanks, Jarkko. Sorry for the delayed response.
>
> I checked the commit in for-next-keys. The updated commit message and the
> cleanup look good to me.
>
> Best,
> Shaomin
>
> On Wed, 10 Jun 2026 13:16:01 +0300, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > On Mon, Jun 08, 2026 at 08:42:21AM +0300, Jarkko Sakkinen wrote:
> > > On Mon, Jun 08, 2026 at 08:29:11AM +0300, Jarkko Sakkinen wrote:
> > > > On Mon, Jun 08, 2026 at 06:10:23AM +0300, Jarkko Sakkinen wrote:
> > > > > On Mon, Jun 08, 2026 at 06:06:21AM +0300, Jarkko Sakkinen wrote:
> > > > > > On Tue, May 26, 2026 at 10:48:38AM +0800, Shaomin Chen wrote:
> > > > > > > keyctl_instantiate_key_common() reads request_key_auth from the assumed
> > > > > > > auth key before copying an instantiation payload from userspace. The copy
> > > > > > > can fault and sleep. If the request completes and revokes the auth key in
> > > > > > > that window, the auth payload can be detached and freed before the
> > > > > > > instantiate path uses it again.
> > > > > > >
> > > > > > > A request-key helper reproducer can trigger this race. One helper child
> > > > > > > blocks in KEYCTL_INSTANTIATE_IOV while the original helper instantiates the
> > > > > > > requested key and returns. KASAN then reports a use-after-free from the
> > > > > > > stale request_key_auth payload in keyctl_instantiate_key_common().
> > > > > > >
> > > > > > > Give request_key_auth payloads a refcount. Take a payload reference while
> > > > > >
> > > > > > Please, name concrete things accurately. I.e. 'usage' in this case. If
> > > > > > you have a name, use it instead of obfuscating generalizations.
> > > > > >
> > > > > > > authkey->sem stabilizes the payload and revocation state. Hold that
> > > > > > > reference across the instantiate and reject paths. Drop the auth key
> > > > > > > owning reference from revoke and destroy.
> > > > > > >
> > > > > > > Reported-by: Shaomin Chen <eeesssooo020@gmail.com>
> > > > > > > Closes: https://lore.kernel.org/r/20260519144403.436694-1-eeesssooo020@gmail.com
> > > > > > > Signed-off-by: Shaomin Chen <eeesssooo020@gmail.com>
> > > > > > > ---
> > > > > > > include/keys/request_key_auth-type.h | 2 ++
> > > > > > > security/keys/internal.h | 2 ++
> > > > > > > security/keys/keyctl.c | 24 +++++++++++++++-----
> > > > > > > security/keys/request_key_auth.c | 33 ++++++++++++++++++++++++++--
> > > > > > > 4 files changed, 53 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > So first, couple of things.
> > > > > >
> > > > > > I'm not going to test not that well documented involving OOT driver.
> > > > >
> > > > > Oops, sorry typo. "not that well documented reproducer" :-)
> > > > >
> > > > > But it is cool we just then need to draw the picture.
> > > >
> > > > I think I got this:
> > > >
> > > > A: request_key() B: KEYCTL_INSTANTIATE_IOV
> > > > ---------------- -------------------------
> > > > create auth key
> > > > store rka in auth key
> > > > wait for helper
> > > > get auth key
> > > > load rka from auth key
> > > > copy user payload
> > > > sleep on #PF
> > > > helper completed
> > > > detach and free rka
> > > > destroy auth key
> > > > wake up
> > > > use rka->target_key
> > > > **USE-AFTER-FREE**
> > > >
> > > > So nothing really complicated here, is there?
> > >
> > > Send v2 with the code changes that I proposed as we want to the change
> > > as ergonomic as possible.
> > >
> > > Use this as the commit message:
> > >
> > > keys: Pin request_key_auth payload in instantiate paths
> > >
> > > A: request_key() B: KEYCTL_INSTANTIATE_IOV
> > > ---------------- -------------------------
> > > create auth key
> > > store rka in auth key
> > > wait for helper
> > > get auth key
> > > load rka from auth key
> > > copy user payload
> > > sleep on #PF
> > >
> > > helper completed
> > > detach and free rka
> > > destroy auth key
> > > wake up
> > > use rka->target_key
> > > **USE-AFTER-FREE**
> > >
> > > Give request_key_auth payloads a refcount. Take a payload reference while
> > > authkey->sem stabilizes the payload and revocation state. Hold that
> > > reference across the instantiate and reject paths. Drop the auth key
> > > owning reference from revoke and destroy.
> > >
> > > [jarkko: Replaced the first two paragraphs of text with a concurrency scenario.]
> > >
> > > And it includes also the remark at the end.
> > >
> > > BR, Jarkko
> >
> > Nothing heard so I pushed:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?h=for-next-keys&id=9feb0bb3468e863b2b82a2eabfaeec4c7c44b90c
> >
> > It has the commit message change.
> >
> > BR, Jarkko
^ permalink raw reply
* Re: [PATCH 1/2] keys: request_key: replace BUG with return -EINVAL
From: Jarkko Sakkinen @ 2026-06-15 12:06 UTC (permalink / raw)
To: Mohammed EL Kadiri
Cc: dhowells, paul, jmorris, serge, kees, keyrings,
linux-security-module, linux-kernel, linux-hardening
In-Reply-To: <20260613130408.13709-2-med08elkadiri@gmail.com>
On Sat, Jun 13, 2026 at 02:04:07PM +0100, Mohammed EL Kadiri wrote:
> Replace BUG() in construct_get_dest_keyring() default case
> with return -EINVAL to handle the unimplemented group keyring
> destination gracefully.
>
> Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
> ---
> security/keys/request_key.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/keys/request_key.c b/security/keys/request_key.c
> index a7673ad86d18..fa2bb9f2f538 100644
> --- a/security/keys/request_key.c
> +++ b/security/keys/request_key.c
> @@ -332,7 +332,7 @@ static int construct_get_dest_keyring(struct key **_dest_keyring)
>
> case KEY_REQKEY_DEFL_GROUP_KEYRING:
> default:
> - BUG();
> + return -EINVAL;
> }
>
> /*
> --
> 2.43.0
>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH 2/2] keys: keyctl_pkey: replace BUG with return -EOPNOTSUPP
From: Jarkko Sakkinen @ 2026-06-15 12:06 UTC (permalink / raw)
To: Mohammed EL Kadiri
Cc: dhowells, paul, jmorris, serge, kees, keyrings,
linux-security-module, linux-kernel, linux-hardening
In-Reply-To: <20260613130408.13709-3-med08elkadiri@gmail.com>
On Sat, Jun 13, 2026 at 02:04:08PM +0100, Mohammed EL Kadiri wrote:
> Replace two BUG() calls in keyctl_pkey_params_get_2() and
> keyctl_pkey_e_d_s() default cases with -EOPNOTSUPP, matching
> the error style already used in these functions.
>
> Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
> ---
> security/keys/keyctl_pkey.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/security/keys/keyctl_pkey.c b/security/keys/keyctl_pkey.c
> index 97bc27bbf079..6b2821ffeb6c 100644
> --- a/security/keys/keyctl_pkey.c
> +++ b/security/keys/keyctl_pkey.c
> @@ -155,7 +155,7 @@ static int keyctl_pkey_params_get_2(const struct keyctl_pkey_params __user *_par
> return -EINVAL;
> break;
> default:
> - BUG();
> + return -EOPNOTSUPP;
> }
>
> params->in_len = uparams.in_len;
> @@ -238,7 +238,8 @@ long keyctl_pkey_e_d_s(int op,
> params.op = kernel_pkey_sign;
> break;
> default:
> - BUG();
> + ret = -EOPNOTSUPP;
> + goto error_params;
> }
>
> in = memdup_user(_in, params.in_len);
> --
> 2.43.0
>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Thank you.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v3] security: Expand task_setscheduler LSM hook to include CPU affinity mask
From: Aaron Tomlin @ 2026-06-15 15:22 UTC (permalink / raw)
To: paul
Cc: tsbogend, paul, jmorris, serge, mingo, juri.lelli,
vincent.guittot, stephen.smalley.work, casey, longman, tj, hannes,
mkoutny, chenridong, dietmar.eggemann, rostedt, bsegall, mgorman,
vschneid, kprateek.nayak, omosnace, kees, neelx, sean, chjohnst,
steve, mproche, nick.lange, cgroups, linux-mips, linux-fsdevel,
linux-security-module, selinux, linux-kernel
In-Reply-To: <6hqq5oxvlcpmjvyns42dy2vtfvvixy7q4xyyjrrn46jrvsx5ar@gkmjsteqlpzd>
On Wed, May 27, 2026 at 09:19:11PM -0400, Aaron Tomlin wrote:
> On Wed, May 27, 2026 at 09:58:58PM +0200, Peter Zijlstra wrote:
> > On Wed, May 27, 2026 at 01:41:52PM -0400, Aaron Tomlin wrote:
> >
> > > > > The actual use case here is multi-tenant workload isolation and visibility.
> > > > > Passing the evaluated cpumask to the BPF LSM allows operators to write a
> > > > > simple eBPF program to detect spatial boundary overlaps (e.g., logging an
> > > > > event if a requested mask intersects with platform-reserved cores).
> >
> > Why isn't cgroups good enough to enforce this? If you create a cgroup
> > hierarchy per tenant, and constrain them using the cpuset controller,
> > they should not be able to escape, rendering this event impossible.
>
> Hi Peter,
>
> You raise a very fair point. The cpuset cgroup controller is indeed the
> kernel's primary vehicle for spatial enforcement, and under normal
> circumstances, it successfully prevents a tenant from escaping their
> designated cores.
>
> The cpuset controller does govern resource limits, but does not audit
> intent. When __sched_setaffinity() is invoked, the kernel compares the
> requested in_mask against the task's allowed cpuset. If there is only a
> partial intersection, the kernel silently truncates the requested mask to
> fit the cpuset, without raising any alarm.
>
> The BPF LSM hook, conversely, receives the raw, untruncated in_mask,
> affording operators the visibility to detect, audit, and even reject these
> violations of intent before the kernel silently sanitises the input.
>
> This patch does not seek to replace the cpuset controller, but rather to
> complement it by providing auditing capabilities.
>
> > > We are not creating a bespoke BPF hook here; rather, we are rectifying a
> > > historical blind spot within the API. The existing LSM hook is invoked
> > > during sched_setaffinity(), yet it presently receives only the task_struct
> > > pointer. Consequently, the security module is essentially asked, "Should
> > > Process A be permitted to alter Process B's affinity?" without being
> > > informed of the proposed affinity itself. Providing in_mask simply
> > > furnishes the existing hook with the requisite payload to make an informed
> > > decision.
> >
> > It occurs to me that this same argument would require to also pass in
> > the new sched_attr, no? That way the LSM can inspect the new policy
> > before it becomes effective.
>
> I agree, the underlying logic does indeed extend perfectly to sched_attr.
>
> Presently, the LSM is equally oblivious as to whether a process is
> requesting a benign transition to SCHED_BATCH, or attempting to escalate
> its privileges by requesting a real-time policy such as SCHED_FIFO with
> maximum priority. Just as with the CPU mask, providing the sched_attr
> payload would rectify this parallel blind spot, allowing BPF policies to
> inspect and mediate scheduling attributes before they become effective.
>
> If you are amenable, I should be more than happy to expand the scope of the
> forthcoming patch to include this. Alternatively, we could address the
> sched_attr expansion in a separate, subsequent patch. Personally, I would
> favour the latter approach, but please do let me know your preference.
>
> I very much look forward to hearing Paul's thoughts on whether this aligns
> with the broader LSM vision.
Hi Paul,
I am writing to politely follow up on the discussion above regarding the
proposed enhancement to the sched_setaffinity LSM hook.
As you will see from the thread, Peter Zijlstra and I have discussed the
architectural justification for this change. While the cpuset cgroup
controller effectively handles spatial enforcement, it silently truncates
requested affinity masks. Passing the raw in_mask to the LSM hook enables
security modules (such as the BPF LSM) to audit and mediate the actual
intent of the request before the kernel sanitises the input, a capability
that cgroups inherently lack.
Furthermore, Peter rightly observed that this reasoning extends naturally
to sched_attr. Presently, the LSM cannot inspect whether a process is
requesting a benign scheduling policy or attempting to escalate to a
real-time priority. I am entirely amenable to addressing this parallel
blind spot, preferably in a subsequent patch.
Before I proceed any further, I would be most grateful for your perspective
as the Security sub-system maintainer. Do you feel this expansion is
acceptable?
As a brief administrative aside, please note that Thomas Bogendoerfer has
already queued the MIPS-specific changes related to this work into the
mips-next tree [1][2].
I look forward to hearing your thoughts.
[1]: https://lore.kernel.org/lkml/psb6pxogv2dlknps4p3sh6rt2h7xuuxkoif6ock5vxfz2jimec@txa6iy65crtb/
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=98e37db4a34d3af3fb2f4648295c25b5e40b20e3
Kind regards,
--
Aaron Tomlin
^ permalink raw reply
* Sashiko reviews for the LSM mailing list
From: Mickaël Salaün @ 2026-06-15 15:37 UTC (permalink / raw)
To: linux-security-module; +Cc: sashiko, Roman Gushchin, Günther Noack
Hi,
I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
most of them were valuable. It found issues (security or not), but it
requires to go to https://sashiko.dev to find them, which is too easy to
forget, and requires additional work from maintainers to copy or point
to these reviews. I sent a PR (currently in draft) to enable email
replies from Sashiko to the Linux Security Module mailing list (most
patches are already reviewed anyway):
https://github.com/sashiko-dev/sashiko/pull/278
Making such reviews broadly available can improve the quality of patches
we receive without much noise, helping for all LSM-related code. We can
fine tune some email-related settings if needed.
If there are any concern or question, this is the right time to start a
discussion.
Regards,
Mickaël
^ permalink raw reply
* [PATCH] security: clarify task_prctl hook documentation
From: Bill Roberts @ 2026-06-15 20:03 UTC (permalink / raw)
To: Paul Moore, James Morris, Serge E. Hallyn
Cc: casey, Bill Roberts, linux-security-module, linux-kernel
The task_prctl hook comment incorrectly described the hook as checking
whether a prctl operation is allowed. In reality, the hook exists for
LSMs to handle LSM-specific prctl operations.
Update the function description and kernel-doc comment to reflect the
actual behavior. The old wording appears to have been copied from other
permission-check hooks despite differing semantics.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
---
security/security.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/security/security.c b/security/security.c
index 4e999f023651..96e6ef088801 100644
--- a/security/security.c
+++ b/security/security.c
@@ -3301,15 +3301,14 @@ int security_task_kill(struct task_struct *p, struct kernel_siginfo *info,
}
/**
- * security_task_prctl() - Check if a prctl op is allowed
+ * security_task_prctl() - Handle an LSM specific prctl call
* @option: operation
* @arg2: argument
* @arg3: argument
* @arg4: argument
* @arg5: argument
*
- * Check permission before performing a process control operation on the
- * current process.
+ * Handle lsm specific prctl operations.
*
* Return: Return -ENOSYS if no-one wanted to handle this op, any other value
* to cause prctl() to return immediately with that value.
--
2.54.0
^ permalink raw reply related
* Re: Sashiko reviews for the LSM mailing list
From: Paul Moore @ 2026-06-15 20:13 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <20260615.zeinurej8oZ9@digikod.net>
On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
>
> Hi,
>
> I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
> most of them were valuable. It found issues (security or not), but it
> requires to go to https://sashiko.dev to find them, which is too easy to
> forget, and requires additional work from maintainers to copy or point
> to these reviews. I sent a PR (currently in draft) to enable email
> replies from Sashiko to the Linux Security Module mailing list (most
> patches are already reviewed anyway):
> https://github.com/sashiko-dev/sashiko/pull/278
>
> Making such reviews broadly available can improve the quality of patches
> we receive without much noise, helping for all LSM-related code. We can
> fine tune some email-related settings if needed.
>
> If there are any concern or question, this is the right time to start a
> discussion.
I recently enabled Sashiko for the SELinux list to trial it there
first, with the goal of eventually bringing this topic up for the rest
of the LSM folks on the LSM list.
While I think Sashiko's review comments are generally okay, you should
have contacted the LSM mailing list folks *before* submitting a PR
that would cause an automated bot to send email to the LSM list (this
applies to all automated emails, not just LLM reviews). Please hold
the PR until you have given people a chance to comment on the issue.
Personally, I'm okay with it.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v3] security: Expand task_setscheduler LSM hook to include CPU affinity mask
From: Paul Moore @ 2026-06-15 22:03 UTC (permalink / raw)
To: Aaron Tomlin
Cc: tsbogend, jmorris, serge, mingo, juri.lelli, vincent.guittot,
stephen.smalley.work, casey, longman, tj, hannes, mkoutny,
chenridong, dietmar.eggemann, rostedt, bsegall, mgorman, vschneid,
kprateek.nayak, omosnace, kees, neelx, sean, chjohnst, steve,
mproche, nick.lange, cgroups, linux-mips, linux-fsdevel,
linux-security-module, selinux, linux-kernel
In-Reply-To: <exlgb3dg2kwxgna6gx2qixexvwjjul7z2ya7npal2gz4jjtr7m@h4oxgd74gsbp>
On Mon, Jun 15, 2026 at 11:22 AM Aaron Tomlin <atomlin@atomlin.com> wrote:
> On Wed, May 27, 2026 at 09:19:11PM -0400, Aaron Tomlin wrote:
> > On Wed, May 27, 2026 at 09:58:58PM +0200, Peter Zijlstra wrote:
> > > On Wed, May 27, 2026 at 01:41:52PM -0400, Aaron Tomlin wrote:
> > >
> > > > > > The actual use case here is multi-tenant workload isolation and visibility.
> > > > > > Passing the evaluated cpumask to the BPF LSM allows operators to write a
> > > > > > simple eBPF program to detect spatial boundary overlaps (e.g., logging an
> > > > > > event if a requested mask intersects with platform-reserved cores).
> > >
> > > Why isn't cgroups good enough to enforce this? If you create a cgroup
> > > hierarchy per tenant, and constrain them using the cpuset controller,
> > > they should not be able to escape, rendering this event impossible.
> >
> > Hi Peter,
> >
> > You raise a very fair point. The cpuset cgroup controller is indeed the
> > kernel's primary vehicle for spatial enforcement, and under normal
> > circumstances, it successfully prevents a tenant from escaping their
> > designated cores.
> >
> > The cpuset controller does govern resource limits, but does not audit
> > intent. When __sched_setaffinity() is invoked, the kernel compares the
> > requested in_mask against the task's allowed cpuset. If there is only a
> > partial intersection, the kernel silently truncates the requested mask to
> > fit the cpuset, without raising any alarm.
> >
> > The BPF LSM hook, conversely, receives the raw, untruncated in_mask,
> > affording operators the visibility to detect, audit, and even reject these
> > violations of intent before the kernel silently sanitises the input.
> >
> > This patch does not seek to replace the cpuset controller, but rather to
> > complement it by providing auditing capabilities.
> >
> > > > We are not creating a bespoke BPF hook here; rather, we are rectifying a
> > > > historical blind spot within the API. The existing LSM hook is invoked
> > > > during sched_setaffinity(), yet it presently receives only the task_struct
> > > > pointer. Consequently, the security module is essentially asked, "Should
> > > > Process A be permitted to alter Process B's affinity?" without being
> > > > informed of the proposed affinity itself. Providing in_mask simply
> > > > furnishes the existing hook with the requisite payload to make an informed
> > > > decision.
> > >
> > > It occurs to me that this same argument would require to also pass in
> > > the new sched_attr, no? That way the LSM can inspect the new policy
> > > before it becomes effective.
> >
> > I agree, the underlying logic does indeed extend perfectly to sched_attr.
> >
> > Presently, the LSM is equally oblivious as to whether a process is
> > requesting a benign transition to SCHED_BATCH, or attempting to escalate
> > its privileges by requesting a real-time policy such as SCHED_FIFO with
> > maximum priority. Just as with the CPU mask, providing the sched_attr
> > payload would rectify this parallel blind spot, allowing BPF policies to
> > inspect and mediate scheduling attributes before they become effective.
> >
> > If you are amenable, I should be more than happy to expand the scope of the
> > forthcoming patch to include this. Alternatively, we could address the
> > sched_attr expansion in a separate, subsequent patch. Personally, I would
> > favour the latter approach, but please do let me know your preference.
> >
> > I very much look forward to hearing Paul's thoughts on whether this aligns
> > with the broader LSM vision.
>
> Hi Paul,
>
> I am writing to politely follow up on the discussion above regarding the
> proposed enhancement to the sched_setaffinity LSM hook.
Generally speaking I wait until all dependencies land in Linus' tree.
I've lost a lot of time in the past sorting out issues only to have
one of the dependencies rejected.
> As you will see from the thread, Peter Zijlstra and I have discussed the
> architectural justification for this change. While the cpuset cgroup
> controller effectively handles spatial enforcement, it silently truncates
> requested affinity masks. Passing the raw in_mask to the LSM hook enables
> security modules (such as the BPF LSM) to audit and mediate the actual
> intent of the request before the kernel sanitises the input, a capability
> that cgroups inherently lack.
The issue of resource control comes up from time to time within the
context of LSMs, and my general comment is that we likely need to see
a more comprehensive approach to what access control on resource
limits would look like from a LSM perspective. We've seen a lot of
quick changes to solve very specific problems, but I have yet to see a
good proposal of what it would look like for a more comprehensive
approach.
There is also another issue to consider: none of the in-tree LSMs
currently use these new parameters, raising questions about their
purpose, maintainability, etc. While this is not necessarily a deal
breaker, it does go along with my comment above about taking a more
holistic view of LSM resource controls.
To summarize, I haven't thought about this too much yet because there
are other fires/patches that don't (currently) have the dependency
issues of this patch. I would also feel a lot better if there was an
in-tree user of this parameter and some discussion of how this might
fit into a more holistic approach to controlling resource limits in
the LSM subsystem.
--
paul-moore.com
^ permalink raw reply
* [GIT PULL] lsm/lsm-pr-20260615
From: Paul Moore @ 2026-06-16 2:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-security-module, linux-kernel
Linus,
A single LSM framework patch to update the security_inode_listsecurity()
hook to be able to leverage the xattr_list_one() helper function. We
wanted to do this for a while, but we needed to fixup the callers in the
NFS code first. With the NFS code changes shipping in Linux v7.0 and
no one complaining, it seemed a good time to complete the shift.
Paul
--
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git
tags/lsm-pr-20260615
for you to fetch changes up to f71ece9712b7712df98871eea9aeb60e49ca5239:
security,fs,nfs,net: update security_inode_listsecurity() interface
(2026-05-01 11:29:33 -0400)
----------------------------------------------------------------
lsm/stable-7.2 PR 20260615
----------------------------------------------------------------
Stephen Smalley (1):
security,fs,nfs,net: update security_inode_listsecurity()
interface
fs/nfs/nfs4proc.c | 7 ++-----
fs/xattr.c | 11 +++++++----
include/linux/lsm_hook_defs.h | 4 ++--
include/linux/security.h | 5 +++--
security/security.c | 16 ++++++++--------
security/selinux/hooks.c | 10 +++-------
security/smack/smack_lsm.c | 13 ++++---------
7 files changed, 29 insertions(+), 37 deletions(-)
--
paul-moore.com
^ permalink raw reply
* [GIT PULL] selinux/selinux-pr-20260615
From: Paul Moore @ 2026-06-16 2:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: selinux, linux-security-module, linux-kernel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]
Linus,
A number of SELinux patches for Linux v7.2, almost all of which are
either minor fixes or hardening patches.
- Additional verifications when loading new SELinux policy
Multiple patches by Christian Göttsche to add additional validations to
the code responsible for loading and parsing SELinux policy as it is
loaded into the kernel.
- Avoid nontransitive comparisons comparisons in our sorting code
Done to prevent unexpected sorting results due to overflow. Qualys
documented a similar issue with glibc:
https://www.qualys.com/2024/01/30/qsort.txt
- Consistently use u16 for SELinux security classes
- Move from page allocations to kmalloc() based allocations
Unfortunately one of these patches had to be reverted, but you should
see a fixed version during the next merge window.
- Move from kmalloc_objs() to kzalloc_objs() in the policy load code
- Reorder sel_kill_sb() slightly to match other pseudo filesystems
- Simplify things with QSTR() instead of QSTR_INIT()
- Minor comment typo fixes
Paul
--
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
tags/selinux-pr-20260615
for you to fetch changes up to 033182baeab63ce96a6eb8aef1a6cd444fcf9519:
selinux: revert use of __getname() in selinux_genfs_get_sid()
(2026-05-29 11:24:37 -0400)
----------------------------------------------------------------
selinux/stable-7.2 PR 20260615
----------------------------------------------------------------
Christian Göttsche (9):
selinux: avoid nontransitive comparison
selinux: use u16 for security classes
selinux: more strict policy parsing
selinux: check length fields in policies
selinux: check type attr map overflows
selinux: reorder policydb_index()
selinux: beef up isvalid checks
selinux: more strict bounds check
selinux: check for simple types
Kalevi Kolttonen (2):
selinux: comment typo fix in selinuxfs.c
selinux: comment spelling fix in ibpkey.c
Mike Rapoport (Microsoft) (2):
selinux: use k[mz]alloc() to allocate temporary buffers
selinux: hooks: use __getname() to allocate path buffer
Paul Moore (1):
selinux: revert use of __getname() in selinux_genfs_get_sid()
Stephen Smalley (2):
selinux: fix sel_kill_sb()
selinux: switch two allocations to use kzalloc_objs()
Thorsten Blum (1):
selinux: use QSTR() instead of QSTR_INIT() in init_sel_fs
security/selinux/ibpkey.c | 2
security/selinux/include/security.h | 1
security/selinux/selinuxfs.c | 27 +-
security/selinux/ss/avtab.c | 49 +++
security/selinux/ss/avtab.h | 13 +
security/selinux/ss/conditional.c | 39 ++-
security/selinux/ss/constraint.h | 1
security/selinux/ss/ebitmap.c | 27 ++
security/selinux/ss/ebitmap.h | 1
security/selinux/ss/hashtab.h | 4
security/selinux/ss/mls.c | 66 +++--
security/selinux/ss/mls.h | 6
security/selinux/ss/policydb.c | 358 ++++++++++++++++++++++------
security/selinux/ss/policydb.h | 56 +++-
security/selinux/ss/services.c | 13 -
security/selinux/ss/symtab.c | 2
security/selinux/ss/symtab.h | 2
17 files changed, 512 insertions(+), 155 deletions(-)
--
paul-moore.com
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Mickaël Salaün @ 2026-06-16 8:49 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <CAHC9VhQxHEuznN-xiMJ-LCsz2z-UB0ri6MeMn+Ajyn1WUTDNDw@mail.gmail.com>
On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
> >
> > Hi,
> >
> > I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
> > most of them were valuable. It found issues (security or not), but it
> > requires to go to https://sashiko.dev to find them, which is too easy to
> > forget, and requires additional work from maintainers to copy or point
> > to these reviews. I sent a PR (currently in draft) to enable email
> > replies from Sashiko to the Linux Security Module mailing list (most
> > patches are already reviewed anyway):
> > https://github.com/sashiko-dev/sashiko/pull/278
> >
> > Making such reviews broadly available can improve the quality of patches
> > we receive without much noise, helping for all LSM-related code. We can
> > fine tune some email-related settings if needed.
> >
> > If there are any concern or question, this is the right time to start a
> > discussion.
>
> I recently enabled Sashiko for the SELinux list to trial it there
> first, with the goal of eventually bringing this topic up for the rest
> of the LSM folks on the LSM list.
>
> While I think Sashiko's review comments are generally okay, you should
> have contacted the LSM mailing list folks *before* submitting a PR
> that would cause an automated bot to send email to the LSM list (this
> applies to all automated emails, not just LLM reviews). Please hold
> the PR until you have given people a chance to comment on the issue.
As I explained just above, the PR is a draft (GitHub specific state for
WIP), so it cannot be merged as-is, but it is useful for reviews and for
LSM folks to get a look if they are interested.
>
> Personally, I'm okay with it.
Looks good. What about waiting a week to get some feedback here and
then ask for a merge of the PR? Anyway, it would not be written in
stone, we can update Sashiko config with new PRs.
>
> --
> paul-moore.com
>
^ permalink raw reply
* Re: [PATCH v17 01/10] rust: alloc: add `KBox::into_non_null`
From: Alice Ryhl @ 2026-06-16 11:50 UTC (permalink / raw)
To: Andreas Hindborg
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Daniel Almeida, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Bjorn Helgaas,
Krzysztof Wilczyński, Boqun Feng, Uladzislau Rezki,
Lorenzo Stoakes, Vlastimil Babka, Liam R. Howlett, Igor Korotin,
Pavel Tikhomirov, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci, driver-core
In-Reply-To: <20260604-unique-ref-v17-1-7b4c3d2930b9@kernel.org>
On Thu, Jun 04, 2026 at 10:11:13PM +0200, Andreas Hindborg wrote:
> Add a method to consume a `Box<T, A>` and return a `NonNull<T>`. This
> is a convenience wrapper around `Self::into_raw` for callers that need
> a `NonNull` pointer rather than a raw pointer.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
^ permalink raw reply
* Re: [PATCH v17 01/10] rust: alloc: add `KBox::into_non_null`
From: Gary Guo @ 2026-06-16 11:52 UTC (permalink / raw)
To: Andreas Hindborg, Miguel Ojeda, Gary Guo, Björn Roy Baron,
Benno Lossin, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Greg Kroah-Hartman, Dave Ertman, Ira Weiny, Leon Romanovsky,
Paul Moore, Serge Hallyn, Rafael J. Wysocki, David Airlie,
Simona Vetter, Alexander Viro, Christian Brauner, Jan Kara,
Daniel Almeida, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Bjorn Helgaas, Krzysztof Wilczyński, Boqun Feng,
Uladzislau Rezki, Lorenzo Stoakes, Vlastimil Babka,
Liam R. Howlett, Igor Korotin, Pavel Tikhomirov
Cc: linux-kernel, rust-for-linux, linux-block, linux-security-module,
dri-devel, linux-fsdevel, linux-mm, linux-pm, linux-pci,
driver-core
In-Reply-To: <20260604-unique-ref-v17-1-7b4c3d2930b9@kernel.org>
On Thu Jun 4, 2026 at 9:11 PM BST, Andreas Hindborg wrote:
> Add a method to consume a `Box<T, A>` and return a `NonNull<T>`. This
> is a convenience wrapper around `Self::into_raw` for callers that need
> a `NonNull` pointer rather than a raw pointer.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> rust/kernel/alloc/kbox.rs | 9 +++++++++
> 1 file changed, 9 insertions(+)
^ permalink raw reply
* Re: [PATCH v17 02/10] rust: types: Add Ownable/Owned types
From: Alice Ryhl @ 2026-06-16 11:54 UTC (permalink / raw)
To: Andreas Hindborg
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Daniel Almeida, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Bjorn Helgaas,
Krzysztof Wilczyński, Boqun Feng, Uladzislau Rezki,
Lorenzo Stoakes, Vlastimil Babka, Liam R. Howlett, Igor Korotin,
Pavel Tikhomirov, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci, driver-core, Asahi Lina, Oliver Mangold
In-Reply-To: <20260604-unique-ref-v17-2-7b4c3d2930b9@kernel.org>
On Thu, Jun 04, 2026 at 10:11:14PM +0200, Andreas Hindborg wrote:
> From: Asahi Lina <lina+kernel@asahilina.net>
>
> By analogy to `AlwaysRefCounted` and `ARef`, an `Ownable` type is a
> (typically C FFI) type that *may* be owned by Rust, but need not be. Unlike
> `AlwaysRefCounted`, this mechanism expects the reference to be unique
> within Rust, and does not allow cloning.
>
> Conceptually, this is similar to a `KBox<T>`, except that it delegates
> resource management to the `T` instead of using a generic allocator.
>
> [ om:
> - Split code into separate file and `pub use` it from types.rs.
> - Make from_raw() and into_raw() public.
> - Remove OwnableMut, and make DerefMut dependent on Unpin instead.
> - Usage example/doctest for Ownable/Owned.
> - Fixes to documentation and commit message.
> ]
>
> Link: https://lore.kernel.org/all/20250202-rust-page-v1-1-e3170d7fe55e@asahilina.net/
> Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
> Co-developed-by: Oliver Mangold <oliver.mangold@pm.me>
> Signed-off-by: Oliver Mangold <oliver.mangold@pm.me>
> Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> [ Andreas: Updated documentation, examples, and formatting. Change safety
> requirements, safety comments. Use a reference for `release`. ]
> Reviewed-by: Gary Guo <gary@garyguo.net>
> Co-developed-by: Andreas Hindborg <a.hindborg@kernel.org>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
Overall looks good to me, but two nits below. With them fixed:
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> +pub trait Ownable {
> + /// Tear down this `Ownable`.
> + ///
> + /// Implementers of `Ownable` can use this function to clean up the use of `Self`. This can
> + /// include freeing the underlying object.
> + ///
> + /// # Safety
> + ///
> + /// Callers must ensure that the caller has exclusive ownership of `T`, and this ownership can
> + /// be transferred to the `release` method.
> + unsafe fn release(&mut self);
I'd make this take a raw pointer because the pointer can be freed during
the execution of release(), which references don't allow.
> diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
> index 4329d3c2c2e5..4aec7b699269 100644
> --- a/rust/kernel/types.rs
> +++ b/rust/kernel/types.rs
> @@ -11,6 +11,17 @@
> };
> use pin_init::{PinInit, Wrapper, Zeroable};
>
> +pub use crate::{
> + owned::{
> + Ownable,
> + Owned, //
> + },
> + sync::aref::{
> + ARef,
> + AlwaysRefCounted, //
> + }, //
> +};
We removed the types::ARef re-export, so you shouldn't add it back.
Alice
^ permalink raw reply
* Re: [PATCH v17 03/10] rust: implement `ForeignOwnable` for `Owned`
From: Gary Guo @ 2026-06-16 11:55 UTC (permalink / raw)
To: Andreas Hindborg, Miguel Ojeda, Gary Guo, Björn Roy Baron,
Benno Lossin, Alice Ryhl, Trevor Gross, Danilo Krummrich,
Greg Kroah-Hartman, Dave Ertman, Ira Weiny, Leon Romanovsky,
Paul Moore, Serge Hallyn, Rafael J. Wysocki, David Airlie,
Simona Vetter, Alexander Viro, Christian Brauner, Jan Kara,
Daniel Almeida, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Bjorn Helgaas, Krzysztof Wilczyński, Boqun Feng,
Uladzislau Rezki, Lorenzo Stoakes, Vlastimil Babka,
Liam R. Howlett, Igor Korotin, Pavel Tikhomirov
Cc: linux-kernel, rust-for-linux, linux-block, linux-security-module,
dri-devel, linux-fsdevel, linux-mm, linux-pm, linux-pci,
driver-core
In-Reply-To: <20260604-unique-ref-v17-3-7b4c3d2930b9@kernel.org>
On Thu Jun 4, 2026 at 9:11 PM BST, Andreas Hindborg wrote:
> Implement `ForeignOwnable` for `Owned<T>`. This allows use of `Owned<T>` in
> places such as the `XArray`.
>
> Note that `T` does not need to implement `ForeignOwnable` for `Owned<T>` to
> implement `ForeignOwnable`.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
> ---
> rust/kernel/owned.rs | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/rust/kernel/owned.rs b/rust/kernel/owned.rs
> index 456e239e906e..5eacdf327d12 100644
> --- a/rust/kernel/owned.rs
> +++ b/rust/kernel/owned.rs
> @@ -15,6 +15,8 @@
> ptr::NonNull, //
> };
>
> +use kernel::types::ForeignOwnable;
> +
> /// Types that specify their own way of performing allocation and destruction. Typically, this trait
> /// is implemented on types from the C side.
> ///
> @@ -108,6 +110,7 @@ pub trait Ownable {
> ///
> /// - Until `T::release` is called, this `Owned<T>` exclusively owns the underlying `T`.
> /// - The `T` value is pinned.
> +#[repr(transparent)]
AFAIT this `#[repr(transparent)]` isn't actually needed.
> pub struct Owned<T: Ownable> {
> ptr: NonNull<T>,
> }
> @@ -185,3 +188,46 @@ fn drop(&mut self) {
> unsafe { T::release(self.ptr.as_mut()) };
> }
> }
> +
> +// SAFETY: We derive the pointer to `T` from a valid `T`, so the returned
> +// pointer satisfy alignment requirements of `T`.
> +unsafe impl<T: Ownable + 'static> ForeignOwnable for Owned<T> {
You should drop the `'static` bound and put where bound on the GAT below
instead. See how `Box` is doing it.
Best,
Gary
> + const FOREIGN_ALIGN: usize = core::mem::align_of::<Owned<T>>();
> +
> + type Borrowed<'a> = &'a T;
> + type BorrowedMut<'a> = Pin<&'a mut T>;
> +
> + #[inline]
> + fn into_foreign(self) -> *mut kernel::ffi::c_void {
> + let ptr = self.ptr.as_ptr().cast();
> + core::mem::forget(self);
> + ptr
> + }
> +
> + #[inline]
> + unsafe fn from_foreign(ptr: *mut kernel::ffi::c_void) -> Self {
> + Self {
> + // SAFETY: By function safety contract, `ptr` came from
> + // `into_foreign` and cannot be null.
> + ptr: unsafe { NonNull::new_unchecked(ptr.cast()) },
> + }
> + }
> +
> + #[inline]
> + unsafe fn borrow<'a>(ptr: *mut kernel::ffi::c_void) -> Self::Borrowed<'a> {
> + // SAFETY: By function safety requirements, `ptr` is valid for use as a
> + // reference for `'a`.
> + unsafe { &*ptr.cast() }
> + }
> +
> + #[inline]
> + unsafe fn borrow_mut<'a>(ptr: *mut kernel::ffi::c_void) -> Self::BorrowedMut<'a> {
> + // SAFETY: By function safety requirements, `ptr` is valid for use as a
> + // unique reference for `'a`.
> + let inner = unsafe { &mut *ptr.cast() };
> +
> + // SAFETY: We never move out of inner, and we do not hand out mutable
> + // references when `T: !Unpin`.
> + unsafe { Pin::new_unchecked(inner) }
> + }
> +}
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Paul Moore @ 2026-06-16 14:11 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <20260616.EPh8ked0niko@digikod.net>
On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
> On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> > On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
> > >
> > > Hi,
> > >
> > > I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
> > > most of them were valuable. It found issues (security or not), but it
> > > requires to go to https://sashiko.dev to find them, which is too easy to
> > > forget, and requires additional work from maintainers to copy or point
> > > to these reviews. I sent a PR (currently in draft) to enable email
> > > replies from Sashiko to the Linux Security Module mailing list (most
> > > patches are already reviewed anyway):
> > > https://github.com/sashiko-dev/sashiko/pull/278
> > >
> > > Making such reviews broadly available can improve the quality of patches
> > > we receive without much noise, helping for all LSM-related code. We can
> > > fine tune some email-related settings if needed.
> > >
> > > If there are any concern or question, this is the right time to start a
> > > discussion.
> >
> > I recently enabled Sashiko for the SELinux list to trial it there
> > first, with the goal of eventually bringing this topic up for the rest
> > of the LSM folks on the LSM list.
> >
> > While I think Sashiko's review comments are generally okay, you should
> > have contacted the LSM mailing list folks *before* submitting a PR
> > that would cause an automated bot to send email to the LSM list (this
> > applies to all automated emails, not just LLM reviews). Please hold
> > the PR until you have given people a chance to comment on the issue.
>
> As I explained just above, the PR is a draft (GitHub specific state for
> WIP), so it cannot be merged as-is, but it is useful for reviews and for
> LSM folks to get a look if they are interested.
>
> > Personally, I'm okay with it.
>
> Looks good. What about waiting a week to get some feedback here and
> then ask for a merge of the PR?
I would suggest enabling Sashiko for the LSM list, but not enabling
the email replies at first. This would allow people to view the
reviews and perhaps make a better informed decision.
> Anyway, it would not be written in
> stone, we can update Sashiko config with new PRs.
It is worth noting that sashiko.dev updates are not immediate, so
there is a delay between a PR being merged and it taking effect.
--
paul-moore.com
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Mickaël Salaün @ 2026-06-16 14:59 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <CAHC9VhRa8DQ-ekrmPQSg2pO9pBFj6GA9DO=x5kguGFTbKKyv7Q@mail.gmail.com>
On Tue, Jun 16, 2026 at 10:11:42AM -0400, Paul Moore wrote:
> On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
> > On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> > > On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
> > > > most of them were valuable. It found issues (security or not), but it
> > > > requires to go to https://sashiko.dev to find them, which is too easy to
> > > > forget, and requires additional work from maintainers to copy or point
> > > > to these reviews. I sent a PR (currently in draft) to enable email
> > > > replies from Sashiko to the Linux Security Module mailing list (most
> > > > patches are already reviewed anyway):
> > > > https://github.com/sashiko-dev/sashiko/pull/278
> > > >
> > > > Making such reviews broadly available can improve the quality of patches
> > > > we receive without much noise, helping for all LSM-related code. We can
> > > > fine tune some email-related settings if needed.
> > > >
> > > > If there are any concern or question, this is the right time to start a
> > > > discussion.
> > >
> > > I recently enabled Sashiko for the SELinux list to trial it there
> > > first, with the goal of eventually bringing this topic up for the rest
> > > of the LSM folks on the LSM list.
> > >
> > > While I think Sashiko's review comments are generally okay, you should
> > > have contacted the LSM mailing list folks *before* submitting a PR
> > > that would cause an automated bot to send email to the LSM list (this
> > > applies to all automated emails, not just LLM reviews). Please hold
> > > the PR until you have given people a chance to comment on the issue.
> >
> > As I explained just above, the PR is a draft (GitHub specific state for
> > WIP), so it cannot be merged as-is, but it is useful for reviews and for
> > LSM folks to get a look if they are interested.
> >
> > > Personally, I'm okay with it.
> >
> > Looks good. What about waiting a week to get some feedback here and
> > then ask for a merge of the PR?
>
> I would suggest enabling Sashiko for the LSM list, but not enabling
> the email replies at first. This would allow people to view the
> reviews and perhaps make a better informed decision.
The point of this PR and the related discussion is to enable email
replies, the reviews are already there. As explained, my motivation for
this change is to get reviews, and without emails I suspect almost nobody
(will) take a look and that would not even be an experiment. I'm saying
that because I forgot several times to take a look and it adds more work
to the review/maintenance.
FWIW, there are currently 41 kernel mailing lists registered:
https://github.com/sashiko-dev/sashiko/blob/main/sashiko.dev/email_policy.toml
>
> > Anyway, it would not be written in
> > stone, we can update Sashiko config with new PRs.
>
> It is worth noting that sashiko.dev updates are not immediate, so
> there is a delay between a PR being merged and it taking effect.
Sure and I don't think it's an issue. It's really easy to filter
emails on any MUA if really needed, and I'm sure the Sashiko maintainers
would be able to fix things quickly if needed.
^ permalink raw reply
* Re: Sashiko reviews for the LSM mailing list
From: Paul Moore @ 2026-06-16 15:23 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-security-module, sashiko, Roman Gushchin,
Günther Noack
In-Reply-To: <20260616.aiGaim8xie8z@digikod.net>
On Tue, Jun 16, 2026 at 10:59 AM Mickaël Salaün <mic@digikod.net> wrote:
> On Tue, Jun 16, 2026 at 10:11:42AM -0400, Paul Moore wrote:
> > On Tue, Jun 16, 2026 at 4:49 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > On Mon, Jun 15, 2026 at 04:13:59PM -0400, Paul Moore wrote:
> > > > On Mon, Jun 15, 2026 at 11:41 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I've been reading Sashiko's (AI bot) reviews wrt Landlock patches, and
> > > > > most of them were valuable. It found issues (security or not), but it
> > > > > requires to go to https://sashiko.dev to find them, which is too easy to
> > > > > forget, and requires additional work from maintainers to copy or point
> > > > > to these reviews. I sent a PR (currently in draft) to enable email
> > > > > replies from Sashiko to the Linux Security Module mailing list (most
> > > > > patches are already reviewed anyway):
> > > > > https://github.com/sashiko-dev/sashiko/pull/278
> > > > >
> > > > > Making such reviews broadly available can improve the quality of patches
> > > > > we receive without much noise, helping for all LSM-related code. We can
> > > > > fine tune some email-related settings if needed.
> > > > >
> > > > > If there are any concern or question, this is the right time to start a
> > > > > discussion.
> > > >
> > > > I recently enabled Sashiko for the SELinux list to trial it there
> > > > first, with the goal of eventually bringing this topic up for the rest
> > > > of the LSM folks on the LSM list.
> > > >
> > > > While I think Sashiko's review comments are generally okay, you should
> > > > have contacted the LSM mailing list folks *before* submitting a PR
> > > > that would cause an automated bot to send email to the LSM list (this
> > > > applies to all automated emails, not just LLM reviews). Please hold
> > > > the PR until you have given people a chance to comment on the issue.
> > >
> > > As I explained just above, the PR is a draft (GitHub specific state for
> > > WIP), so it cannot be merged as-is, but it is useful for reviews and for
> > > LSM folks to get a look if they are interested.
> > >
> > > > Personally, I'm okay with it.
> > >
> > > Looks good. What about waiting a week to get some feedback here and
> > > then ask for a merge of the PR?
> >
> > I would suggest enabling Sashiko for the LSM list, but not enabling
> > the email replies at first. This would allow people to view the
> > reviews and perhaps make a better informed decision.
>
> The point of this PR and the related discussion is to enable email
> replies ...
... and you've heard my opinions on that.
> the reviews are already there.
I don't believe the LSM list is being directly reviewed by sashiko.dev
at the moment (check the lists drop-down in the web UI). Any
LSM-posted patches being reviewed are being reviewed due to a CC to a
sashiko.dev monitored list.
> As explained, my motivation for
> this change is to get reviews, and without emails I suspect almost nobody
> (will) take a look and that would not even be an experiment. I'm saying
> that because I forgot several times to take a look and it adds more work
> to the review/maintenance.
I think it's important to allow people a chance to see what the
reviews are like before you enable an automated bot on the mailing
list. I'm sorry you found it cumbersome to check the web UI, but a
change to what is sent to the mailing list affects more than just you.
Perhaps we do eventually enable sashiko.dev to post to the LSM list,
as I said before I have no problem with that, but I want to give
people a chance to look at the Sashiko reviews first and make a more
informed decision.
> FWIW, there are currently 41 kernel mailing lists registered:
> https://github.com/sashiko-dev/sashiko/blob/main/sashiko.dev/email_policy.toml
Yes, I think we can all read a configuration file.
> > > Anyway, it would not be written in
> > > stone, we can update Sashiko config with new PRs.
> >
> > It is worth noting that sashiko.dev updates are not immediate, so
> > there is a delay between a PR being merged and it taking effect.
>
> Sure and I don't think it's an issue. It's really easy to filter
> emails on any MUA if really needed, and I'm sure the Sashiko maintainers
> would be able to fix things quickly if needed.
I think it's important to understand that not everyone approaches the
email lists the same way, and something that is a non-issue for you
might be a larger issue for someone else.
As a reminder, you are always welcome to create your own list for
Landlock if you find that the LSM list no longer meets your needs.
The only thing I ask is that any patches touching/affecting the LSM
framework are sent to the LSM list and of course any pull requests
sent to Linus should CC the LSM list.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH] security: clarify task_prctl hook documentation
From: Casey Schaufler @ 2026-06-16 16:07 UTC (permalink / raw)
To: Bill Roberts, Paul Moore, James Morris, Serge E. Hallyn
Cc: linux-security-module, linux-kernel, Casey Schaufler
In-Reply-To: <20260615200325.260057-1-bill.roberts@arm.com>
On 6/15/2026 1:03 PM, Bill Roberts wrote:
> The task_prctl hook comment incorrectly described the hook as checking
> whether a prctl operation is allowed. In reality, the hook exists for
> LSMs to handle LSM-specific prctl operations.
>
> Update the function description and kernel-doc comment to reflect the
> actual behavior. The old wording appears to have been copied from other
> permission-check hooks despite differing semantics.
>
> Signed-off-by: Bill Roberts <bill.roberts@arm.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
> security/security.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/security/security.c b/security/security.c
> index 4e999f023651..96e6ef088801 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -3301,15 +3301,14 @@ int security_task_kill(struct task_struct *p, struct kernel_siginfo *info,
> }
>
> /**
> - * security_task_prctl() - Check if a prctl op is allowed
> + * security_task_prctl() - Handle an LSM specific prctl call
> * @option: operation
> * @arg2: argument
> * @arg3: argument
> * @arg4: argument
> * @arg5: argument
> *
> - * Check permission before performing a process control operation on the
> - * current process.
> + * Handle lsm specific prctl operations.
> *
> * Return: Return -ENOSYS if no-one wanted to handle this op, any other value
> * to cause prctl() to return immediately with that value.
^ permalink raw reply
* Re: [PATCH] security: clarify task_prctl hook documentation
From: Serge E. Hallyn @ 2026-06-16 17:14 UTC (permalink / raw)
To: Casey Schaufler
Cc: Bill Roberts, Paul Moore, James Morris, Serge E. Hallyn,
linux-security-module, linux-kernel
In-Reply-To: <bdf7591c-4078-4ee5-9e63-e5dc27602fb6@schaufler-ca.com>
On Tue, Jun 16, 2026 at 09:07:40AM -0700, Casey Schaufler wrote:
> On 6/15/2026 1:03 PM, Bill Roberts wrote:
> > The task_prctl hook comment incorrectly described the hook as checking
> > whether a prctl operation is allowed. In reality, the hook exists for
> > LSMs to handle LSM-specific prctl operations.
> >
> > Update the function description and kernel-doc comment to reflect the
> > actual behavior. The old wording appears to have been copied from other
> > permission-check hooks despite differing semantics.
> >
> > Signed-off-by: Bill Roberts <bill.roberts@arm.com>
>
> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Yeah, this is an important distinction, thanks.
Reviewed-by: Serge Hallyn <serge@hallyn.com>
> > ---
> > security/security.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/security/security.c b/security/security.c
> > index 4e999f023651..96e6ef088801 100644
> > --- a/security/security.c
> > +++ b/security/security.c
> > @@ -3301,15 +3301,14 @@ int security_task_kill(struct task_struct *p, struct kernel_siginfo *info,
> > }
> >
> > /**
> > - * security_task_prctl() - Check if a prctl op is allowed
> > + * security_task_prctl() - Handle an LSM specific prctl call
> > * @option: operation
> > * @arg2: argument
> > * @arg3: argument
> > * @arg4: argument
> > * @arg5: argument
> > *
> > - * Check permission before performing a process control operation on the
> > - * current process.
> > + * Handle lsm specific prctl operations.
> > *
> > * Return: Return -ENOSYS if no-one wanted to handle this op, any other value
> > * to cause prctl() to return immediately with that value.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox