* Re: [PATCH 2/2] landlock: replace __sk_common struct sock field accesses
From: Mickaël Salaün @ 2026-06-10 13:48 UTC (permalink / raw)
To: Matthieu Buffet
Cc: Günther Noack, Mikhail Ivanov, Tingmao Wang,
konstantin.meskhidze, linux-security-module
In-Reply-To: <20260610.rai6icahch2L@digikod.net>
On Wed, Jun 10, 2026 at 03:41:06PM +0200, Mickaël Salaün wrote:
> Thanks for the fixes, but can you please send a full v5 patch series?
Ok, these are not part of the UDP patch series, but this part of the
same thread, my bad... I'll pick them, thanks!
>
> On Tue, Jun 09, 2026 at 11:15:11PM +0200, Matthieu Buffet wrote:
> > Use the proper macro to access __sk_common.skc_family like everywhere
> > else.
> >
> > Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
> > ---
> > security/landlock/net.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/security/landlock/net.c b/security/landlock/net.c
> > index 111e58fd9325..fc2acf8bd898 100644
> > --- a/security/landlock/net.c
> > +++ b/security/landlock/net.c
> > @@ -71,7 +71,7 @@ static int current_check_access_socket(struct socket *const sock,
> > * The socket is not locked, so sk_family can change concurrently
> > * due to e.g. setsockopt(IPV6_ADDRFORM).
> > */
> > - sock_family = READ_ONCE(sock->sk->__sk_common.skc_family);
> > + sock_family = READ_ONCE(sock->sk->sk_family);
> >
> > switch (address->sa_family) {
> > case AF_UNSPEC:
> > --
> > 2.47.3
> >
> >
^ permalink raw reply
* Re: [PATCH v4 0/7] landlock: Add UDP access control support
From: Mickaël Salaün @ 2026-06-10 13:44 UTC (permalink / raw)
To: Matthieu Buffet
Cc: Günther Noack, linux-security-module, Mikhail Ivanov,
konstantin.meskhidze, Tingmao Wang
In-Reply-To: <ed2805ed-72cf-4277-993e-8a0ca73e65ee@buffet.re>
On Sat, Jun 06, 2026 at 07:01:24PM +0200, Matthieu Buffet wrote:
> Hi Mickaël, Günther,
>
> Thank you both for your reviews, I will follow up with these last fixes in a
> v5.
>
> On 5/22/2026 11:08 PM, Mickaël Salaün wrote:
> > > I'm just not super happy about the clarity of logs generated for denied
> > > autobinds ("domain=xxxxxx blockers=net.bind_udp"), due to the fact that
> > > addresses and ports are currently only logged if they are non-0. A later
> > > (coordinated LSM-wide) patch could improve readability by replacing != 0
> > > checks with new booleans in struct lsm_network_audit.
> >
> > Do you plan to send such patch after this series? I guess we could add
> > has_{port,addr} fields to lsm_network_audit and handle AF_UNSPEC too?
>
> I have not come up with anything better than adding boolean fields, so if
> you're in, I will draft a proposition along these lines (and cc: LSM
> subsystem maintainers to synchronize the change across LSMs, I guess)
This sounds good to me.
>
> > > I'm also not
> > > exactly happy with the integration in existing TCP selftests, but
> > > refactoring them has already been discussed earlier.
> >
> > Can you remind us what was your concern and the potential fix?
>
> Regarding TCP selftests, I was referencing that discussion about readability
> (length, and usage of conditionals in what are already test variants) :
> https://lore.kernel.org/linux-security-module/22dcebae-dc5d-0bf1-c686-d2f444558106@huawei-partners.com/
> Nothing blocking, refactoring can be done when things are less busy.
Yes, let's keep that in mind and discuss it once this patch series is
merged.
>
> --
> Matthieu
>
^ permalink raw reply
* Re: [PATCH 2/2] landlock: replace __sk_common struct sock field accesses
From: Mickaël Salaün @ 2026-06-10 13:41 UTC (permalink / raw)
To: Matthieu Buffet
Cc: Günther Noack, Mikhail Ivanov, Tingmao Wang,
konstantin.meskhidze, linux-security-module
In-Reply-To: <20260609211511.85630-2-matthieu@buffet.re>
Thanks for the fixes, but can you please send a full v5 patch series?
On Tue, Jun 09, 2026 at 11:15:11PM +0200, Matthieu Buffet wrote:
> Use the proper macro to access __sk_common.skc_family like everywhere
> else.
>
> Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
> ---
> security/landlock/net.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/landlock/net.c b/security/landlock/net.c
> index 111e58fd9325..fc2acf8bd898 100644
> --- a/security/landlock/net.c
> +++ b/security/landlock/net.c
> @@ -71,7 +71,7 @@ static int current_check_access_socket(struct socket *const sock,
> * The socket is not locked, so sk_family can change concurrently
> * due to e.g. setsockopt(IPV6_ADDRFORM).
> */
> - sock_family = READ_ONCE(sock->sk->__sk_common.skc_family);
> + sock_family = READ_ONCE(sock->sk->sk_family);
>
> switch (address->sa_family) {
> case AF_UNSPEC:
> --
> 2.47.3
>
>
^ permalink raw reply
* Re: [PATCH v3 1/3] landlock: Require LANDLOCK_ACCESS_FS_MAKE_WHITEOUT for RENAME_WHITEOUT
From: Mickaël Salaün @ 2026-06-10 13:38 UTC (permalink / raw)
To: Günther Noack
Cc: Christian Brauner, linux-security-module, Paul Moore,
Amir Goldstein, Miklos Szeredi, Serge Hallyn, Stephen Smalley
In-Reply-To: <20260610092318.3868884-2-gnoack@google.com>
Making MAKE_CHAR not covering MAKE_WHITEOUT is not addressed (see
previous discussion). MAKE_CHAR should not restrict whiteout creation
*if* MAKE_WHITEOUT is handled. Specific tests should check that all
these cases are proprely handled.
There is no documentation update related to the new feature. A note
should also explain what exactly is a whiteout and why it is not
considered a character device (see previous discussions).
The sandboxer is not updated.
There is no audit tests.
On Wed, Jun 10, 2026 at 11:23:16AM +0200, Günther Noack wrote:
> renameat2(2) with the RENAME_WHITEOUT flag places a whiteout character
> device file in the source file location in place of the moved file.
> This creates a directory entry even in cases where all
> LANDLOCK_ACCESS_FS_MAKE_* rights are denied.
>
> Introduce the LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right, which is checked
> for the origin directory if RENAME_WHITEOUT is passed.
>
> This does not affect normal renames within layered OverlayFS mounts:
> When OverlayFS invokes rename with RENAME_WHITEOUT as part of a
> "normal" rename operation, it does so in ovl_rename() using the
> credentials that were set at the time of mounting the OverlayFS.
>
> Bump the Landlock ABI version to 10.
>
> Suggested-by: Christian Brauner <brauner@kernel.org>
> Suggested-by: Mickaël Salaün <mic@digikod.net>
> Signed-off-by: Günther Noack <gnoack@google.com>
> ---
> include/uapi/linux/landlock.h | 3 +++
> security/landlock/audit.c | 1 +
> security/landlock/fs.c | 17 ++++++++++++++---
> security/landlock/limits.h | 2 +-
> security/landlock/syscalls.c | 2 +-
> tools/testing/selftests/landlock/base_test.c | 4 ++--
> tools/testing/selftests/landlock/fs_test.c | 5 +++--
> 7 files changed, 25 insertions(+), 9 deletions(-)
>
> diff --git a/include/uapi/linux/landlock.h b/include/uapi/linux/landlock.h
> index 10a346e55e95..1f8a1d6d25f1 100644
> --- a/include/uapi/linux/landlock.h
> +++ b/include/uapi/linux/landlock.h
> @@ -328,6 +328,8 @@ struct landlock_net_port_attr {
> *
> * If multiple requirements are not met, the ``EACCES`` error code takes
> * precedence over ``EXDEV``.
> + * - %LANDLOCK_ACCESS_FS_MAKE_WHITEOUT: Create a whiteout object through
> + * :manpage:`rename(2)` with ``RENAME_WHITEOUT``.
> *
> * .. warning::
> *
> @@ -356,6 +358,7 @@ struct landlock_net_port_attr {
> #define LANDLOCK_ACCESS_FS_TRUNCATE (1ULL << 14)
> #define LANDLOCK_ACCESS_FS_IOCTL_DEV (1ULL << 15)
> #define LANDLOCK_ACCESS_FS_RESOLVE_UNIX (1ULL << 16)
> +#define LANDLOCK_ACCESS_FS_MAKE_WHITEOUT (1ULL << 17)
> /* clang-format on */
>
> /**
> diff --git a/security/landlock/audit.c b/security/landlock/audit.c
> index 8d0edf94037d..09c97083f599 100644
> --- a/security/landlock/audit.c
> +++ b/security/landlock/audit.c
> @@ -38,6 +38,7 @@ static const char *const fs_access_strings[] = {
> [BIT_INDEX(LANDLOCK_ACCESS_FS_TRUNCATE)] = "fs.truncate",
> [BIT_INDEX(LANDLOCK_ACCESS_FS_IOCTL_DEV)] = "fs.ioctl_dev",
> [BIT_INDEX(LANDLOCK_ACCESS_FS_RESOLVE_UNIX)] = "fs.resolve_unix",
> + [BIT_INDEX(LANDLOCK_ACCESS_FS_MAKE_WHITEOUT)] = "fs.make_whiteout",
> };
>
> static_assert(ARRAY_SIZE(fs_access_strings) == LANDLOCK_NUM_ACCESS_FS);
> diff --git a/security/landlock/fs.c b/security/landlock/fs.c
> index c1ecfe239032..67810d5242b2 100644
> --- a/security/landlock/fs.c
> +++ b/security/landlock/fs.c
> @@ -1080,6 +1080,7 @@ static bool collect_domain_accesses(const struct landlock_ruleset *const domain,
> * @new_dentry: Destination file or directory.
> * @removable: Sets to true if it is a rename operation.
> * @exchange: Sets to true if it is a rename operation with RENAME_EXCHANGE.
> + * @whiteout: Sets to true if it is a rename operation with RENAME_WHITEOUT.
> *
> * Because of its unprivileged constraints, Landlock relies on file hierarchies
> * (and not only inodes) to tie access rights to files. Being able to link or
> @@ -1127,7 +1128,8 @@ static bool collect_domain_accesses(const struct landlock_ruleset *const domain,
> static int current_check_refer_path(struct dentry *const old_dentry,
> const struct path *const new_dir,
> struct dentry *const new_dentry,
> - const bool removable, const bool exchange)
> + const bool removable, const bool exchange,
> + const bool whiteout)
> {
> const struct landlock_cred_security *const subject =
> landlock_get_applicable_subject(current_cred(), any_fs, NULL);
> @@ -1159,6 +1161,14 @@ static int current_check_refer_path(struct dentry *const old_dentry,
> access_request_parent2 |= maybe_remove(new_dentry);
> }
>
> + /*
> + * In case of renameat2(2) with RENAME_WHITEOUT, a whiteout object is
> + * created in the source location, so we require an additional access
> + * right there.
> + */
> + if (whiteout)
> + access_request_parent1 |= LANDLOCK_ACCESS_FS_MAKE_WHITEOUT;
> +
> /* The mount points are the same for old and new paths, cf. EXDEV. */
> if (old_dentry->d_parent == new_dir->dentry) {
> /*
> @@ -1509,7 +1519,7 @@ static int hook_path_link(struct dentry *const old_dentry,
> struct dentry *const new_dentry)
> {
> return current_check_refer_path(old_dentry, new_dir, new_dentry, false,
> - false);
> + false, false);
> }
>
> static int hook_path_rename(const struct path *const old_dir,
> @@ -1520,7 +1530,8 @@ static int hook_path_rename(const struct path *const old_dir,
> {
> /* old_dir refers to old_dentry->d_parent and new_dir->mnt */
> return current_check_refer_path(old_dentry, new_dir, new_dentry, true,
> - !!(flags & RENAME_EXCHANGE));
> + !!(flags & RENAME_EXCHANGE),
> + !!(flags & RENAME_WHITEOUT));
> }
>
> static int hook_path_mkdir(const struct path *const dir,
> diff --git a/security/landlock/limits.h b/security/landlock/limits.h
> index b454ad73b15e..e59378e8e897 100644
> --- a/security/landlock/limits.h
> +++ b/security/landlock/limits.h
> @@ -19,7 +19,7 @@
> #define LANDLOCK_MAX_NUM_LAYERS 16
> #define LANDLOCK_MAX_NUM_RULES U32_MAX
>
> -#define LANDLOCK_LAST_ACCESS_FS LANDLOCK_ACCESS_FS_RESOLVE_UNIX
> +#define LANDLOCK_LAST_ACCESS_FS LANDLOCK_ACCESS_FS_MAKE_WHITEOUT
> #define LANDLOCK_MASK_ACCESS_FS ((LANDLOCK_LAST_ACCESS_FS << 1) - 1)
> #define LANDLOCK_NUM_ACCESS_FS __const_hweight64(LANDLOCK_MASK_ACCESS_FS)
>
> diff --git a/security/landlock/syscalls.c b/security/landlock/syscalls.c
> index accfd2e5a0cd..d45469d5d464 100644
> --- a/security/landlock/syscalls.c
> +++ b/security/landlock/syscalls.c
> @@ -166,7 +166,7 @@ static const struct file_operations ruleset_fops = {
> * If the change involves a fix that requires userspace awareness, also update
> * the errata documentation in Documentation/userspace-api/landlock.rst .
> */
> -const int landlock_abi_version = 9;
> +const int landlock_abi_version = 10;
>
> /**
> * sys_landlock_create_ruleset - Create a new ruleset
> diff --git a/tools/testing/selftests/landlock/base_test.c b/tools/testing/selftests/landlock/base_test.c
> index 30d37234086c..6c8113c2ded1 100644
> --- a/tools/testing/selftests/landlock/base_test.c
> +++ b/tools/testing/selftests/landlock/base_test.c
> @@ -76,8 +76,8 @@ TEST(abi_version)
> const struct landlock_ruleset_attr ruleset_attr = {
> .handled_access_fs = LANDLOCK_ACCESS_FS_READ_FILE,
> };
> - ASSERT_EQ(9, landlock_create_ruleset(NULL, 0,
> - LANDLOCK_CREATE_RULESET_VERSION));
> + ASSERT_EQ(10, landlock_create_ruleset(NULL, 0,
> + LANDLOCK_CREATE_RULESET_VERSION));
>
> ASSERT_EQ(-1, landlock_create_ruleset(&ruleset_attr, 0,
> LANDLOCK_CREATE_RULESET_VERSION));
> diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
> index cdb47fc1fc0a..53d1b659849f 100644
> --- a/tools/testing/selftests/landlock/fs_test.c
> +++ b/tools/testing/selftests/landlock/fs_test.c
> @@ -579,7 +579,7 @@ TEST_F_FORK(layout1, inval)
> LANDLOCK_ACCESS_FS_IOCTL_DEV | \
> LANDLOCK_ACCESS_FS_RESOLVE_UNIX)
>
> -#define ACCESS_LAST LANDLOCK_ACCESS_FS_RESOLVE_UNIX
> +#define ACCESS_LAST LANDLOCK_ACCESS_FS_MAKE_WHITEOUT
>
> #define ACCESS_ALL ( \
> ACCESS_FILE | \
> @@ -593,7 +593,8 @@ TEST_F_FORK(layout1, inval)
> LANDLOCK_ACCESS_FS_MAKE_FIFO | \
> LANDLOCK_ACCESS_FS_MAKE_BLOCK | \
> LANDLOCK_ACCESS_FS_MAKE_SYM | \
> - LANDLOCK_ACCESS_FS_REFER)
> + LANDLOCK_ACCESS_FS_REFER | \
> + LANDLOCK_ACCESS_FS_MAKE_WHITEOUT)
>
> /* clang-format on */
>
> --
> 2.54.0.1099.g489fc7bff1-goog
>
^ permalink raw reply
* Re: [PATCH] keys: allow request-key path to be configured via Kconfig
From: Gary Guo @ 2026-06-10 13:37 UTC (permalink / raw)
To: Jarkko Sakkinen, Gary Guo
Cc: David Howells, Paul Moore, James Morris, Serge E. Hallyn,
keyrings, linux-security-module, linux-kernel
In-Reply-To: <ailfPUbn8gbUqB1D@kernel.org>
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
^ permalink raw reply
* Re: [PATCH] keys: allow request-key path to be configured via Kconfig
From: Gary Guo @ 2026-06-10 13:31 UTC (permalink / raw)
To: Jarkko Sakkinen, Gary Guo
Cc: David Howells, Paul Moore, James Morris, Serge E. Hallyn,
keyrings, linux-security-module, linux-kernel
In-Reply-To: <ailgG5JF6Qu_6v0P@kernel.org>
On Wed Jun 10, 2026 at 2:01 PM BST, Jarkko Sakkinen wrote:
> On Wed, Jun 10, 2026 at 03:57:37PM +0300, Jarkko Sakkinen wrote:
>> On Mon, Jun 08, 2026 at 11:30:06AM +0100, Gary Guo wrote:
>> > On Mon Jun 8, 2026 at 5:59 AM BST, Jarkko Sakkinen wrote:
>> > > On Mon, Jun 08, 2026 at 07:50:03AM +0300, Jarkko Sakkinen wrote:
>> > >> On Sun, Jun 07, 2026 at 02:49:27PM +0100, Gary Guo wrote:
>> > >> > From: Gary Guo <gary@garyguo.net>
>> > >> >
>> > >> > Some Linux distributions (e.g. NixOS) does not have /sbin present, and they
>> > >> > currently carry patches to replace /sbin/request-key to some other path.
>> > >>
>> > >> Sorry but no configuration for introducing API divergence.
>> >
>> > What is the API divergence here? Distros can already patch the kernel or place a
>> > different binary there, so I don't see what's being gained on not allowing to
>> > change this with Kconfig.
>>
>> There's lot of out-of-tree drivers too that distributions. I'm not
>> finding anything usefel in this argument.
Out-of-tree drivers are, well, out of tree. This one requires patching the tree.
Unlike many other distros, so far the only patches needed for NixOS is patching
out /sbin.
>>
>> >
>> > Also to note, the actual binary being called can already be swapped out by
>> > CONFIG_STATIC_USERMODEHELPER_PATH, although for the NixOS this is not the proper
>> > mechanism as it affects coredump too which isn't a fixed path binary in /sbin.
>>
>> I have not seen actual uses of CONFIG_STATIC_USERMODEHELPER_PATH. You
>> could probably use it with busybox?
I think it's used for hardening.
>> >
>> > 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.
>>
>> >
>> > How about a something like CONFIG_DEFAULT_USERMODEHELPER_PATH which defaults to
>> > /sbin, and then request-key uses that concatenated with "/request-key"?
>> >
>> > [snip]
>>
>> I don't frankly care how NixOS works per se in details. Scope this into
>> message to problem that it addresses.
Well, I reckon that's what's going to happen, so in the commit message I just
included "binary is not in /sbin". But the idea is that there's a good reason
that it's not in /sbin.
>
> Not 100% NAK but this does not have "universal logic" embedded into it"
>
> "Distro's use it" is popularity opinion, which has no place over here.
> Mastodon, Threads etc. work for that so much better.
I disagree. Distro is really just a collection of users. I would rather than
phrase this as "user's using it this way". If something needs to be patched to
be used, I think that's rather a good reason to make the change.
I think "user wants to control where UMH lives" is a pretty good motivation, but
it looks like you disagree. Anyhow, if you don't like the idea, I'll just drop
this patch, as I am not the one maintaining these distro patches anyway. I just
think it's the best if Kconfig can meet user demand and more people can run
unpatched kernels.
Best,
Gary
> Perhaps if the motivation-stimuli-solution type of logics gets carved
> crystal clear we can move forward. I.e. you need to work on this. I've
> given my feedback for this version, and it is not good enough, sorry.
>
> BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: allow request-key path to be configured via Kconfig
From: Jarkko Sakkinen @ 2026-06-10 13:01 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: <ailfPUbn8gbUqB1D@kernel.org>
On Wed, Jun 10, 2026 at 03:57:37PM +0300, Jarkko Sakkinen wrote:
> On Mon, Jun 08, 2026 at 11:30:06AM +0100, Gary Guo wrote:
> > On Mon Jun 8, 2026 at 5:59 AM BST, Jarkko Sakkinen wrote:
> > > On Mon, Jun 08, 2026 at 07:50:03AM +0300, Jarkko Sakkinen wrote:
> > >> On Sun, Jun 07, 2026 at 02:49:27PM +0100, Gary Guo wrote:
> > >> > From: Gary Guo <gary@garyguo.net>
> > >> >
> > >> > Some Linux distributions (e.g. NixOS) does not have /sbin present, and they
> > >> > currently carry patches to replace /sbin/request-key to some other path.
> > >>
> > >> Sorry but no configuration for introducing API divergence.
> >
> > What is the API divergence here? Distros can already patch the kernel or place a
> > different binary there, so I don't see what's being gained on not allowing to
> > change this with Kconfig.
>
> There's lot of out-of-tree drivers too that distributions. I'm not
> finding anything usefel in this argument.
>
> >
> > Also to note, the actual binary being called can already be swapped out by
> > CONFIG_STATIC_USERMODEHELPER_PATH, although for the NixOS this is not the proper
> > mechanism as it affects coredump too which isn't a fixed path binary in /sbin.
>
> I have not seen actual uses of CONFIG_STATIC_USERMODEHELPER_PATH. You
> could probably use it with busybox?
>
> >
> > 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.
>
> >
> > How about a something like CONFIG_DEFAULT_USERMODEHELPER_PATH which defaults to
> > /sbin, and then request-key uses that concatenated with "/request-key"?
> >
> > >
> > > Not sure right now but one option might kernel command-line. Then it is
> > > known at run-time, can be signed etc. Compiled value has no identity in
> > > the same way.
> > >
> > > And I don't care if NixOS has such a problem as I've not have any stake
> > > making of those decisions.
> > >
> > > You really should explain why it makes sense to have such feature i.e.,
> > > why is it useful. And if NixOS considered, why is it useful for NixOS.
> > >
> > > This all should be in the commit message.
> >
> > Sure, if you need some more detailed explaination on how NixOS works.
> >
> > NixOS intentionally not use FHS directory paths, so packages refers to their
> > dependencies via cryptographical hashes in rather than fixed paths for build-time
> > known dependencies, and themselves also live in a path with hashes in them (so
> > two different versions of the same package are in different paths). E.g.
> > /nix/store/wjzk0s5dwk0i7swh3rmh1pl10k6v1w6d-keyutils-1.6.3/bin/request-key
> >
> > The full system is also built as a package with all installed binaries in
> > $pkg/sw/bin, configuration in $pkg/etc, etc.. The current system is symlinked to
> > /run/current-system, and when a new system is activated this symlink is swapped
> > out and therefore all paths are updated atomically. For request-key, this is
> > symlinked to
> > /run/current-system/sw/bin/request-key
> >
> > NixOS carries a patch which uses this path instead of /sbin (which does not
> > exist on NixOS at all).
> >
> > The motivation is really "be able to switch /sbin". I feel that all the above are
> > secondary motivations and is too verbose to include in the commit message.
> >
> > I am not a maintainer for NixOS's kernel; I use NixOS and just want to develop
> > kernel and test out kernel on my machines without having to patch them.
>
> I don't frankly care how NixOS works per se in details. Scope this into
> message to problem that it addresses.
Not 100% NAK but this does not have "universal logic" embedded into it"
"Distro's use it" is popularity opinion, which has no place over here.
Mastodon, Threads etc. work for that so much better.
Perhaps if the motivation-stimuli-solution type of logics gets carved
crystal clear we can move forward. I.e. you need to work on this. I've
given my feedback for this version, and it is not good enough, sorry.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: allow request-key path to be configured via Kconfig
From: Jarkko Sakkinen @ 2026-06-10 12:57 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: <DJ3LJFFPMAOW.QA3EZSAB2S5A@garyguo.net>
On Mon, Jun 08, 2026 at 11:30:06AM +0100, Gary Guo wrote:
> On Mon Jun 8, 2026 at 5:59 AM BST, Jarkko Sakkinen wrote:
> > On Mon, Jun 08, 2026 at 07:50:03AM +0300, Jarkko Sakkinen wrote:
> >> On Sun, Jun 07, 2026 at 02:49:27PM +0100, Gary Guo wrote:
> >> > From: Gary Guo <gary@garyguo.net>
> >> >
> >> > Some Linux distributions (e.g. NixOS) does not have /sbin present, and they
> >> > currently carry patches to replace /sbin/request-key to some other path.
> >>
> >> Sorry but no configuration for introducing API divergence.
>
> What is the API divergence here? Distros can already patch the kernel or place a
> different binary there, so I don't see what's being gained on not allowing to
> change this with Kconfig.
There's lot of out-of-tree drivers too that distributions. I'm not
finding anything usefel in this argument.
>
> Also to note, the actual binary being called can already be swapped out by
> CONFIG_STATIC_USERMODEHELPER_PATH, although for the NixOS this is not the proper
> mechanism as it affects coredump too which isn't a fixed path binary in /sbin.
I have not seen actual uses of CONFIG_STATIC_USERMODEHELPER_PATH. You
could probably use it with busybox?
>
> 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.
>
> How about a something like CONFIG_DEFAULT_USERMODEHELPER_PATH which defaults to
> /sbin, and then request-key uses that concatenated with "/request-key"?
>
> >
> > Not sure right now but one option might kernel command-line. Then it is
> > known at run-time, can be signed etc. Compiled value has no identity in
> > the same way.
> >
> > And I don't care if NixOS has such a problem as I've not have any stake
> > making of those decisions.
> >
> > You really should explain why it makes sense to have such feature i.e.,
> > why is it useful. And if NixOS considered, why is it useful for NixOS.
> >
> > This all should be in the commit message.
>
> Sure, if you need some more detailed explaination on how NixOS works.
>
> NixOS intentionally not use FHS directory paths, so packages refers to their
> dependencies via cryptographical hashes in rather than fixed paths for build-time
> known dependencies, and themselves also live in a path with hashes in them (so
> two different versions of the same package are in different paths). E.g.
> /nix/store/wjzk0s5dwk0i7swh3rmh1pl10k6v1w6d-keyutils-1.6.3/bin/request-key
>
> The full system is also built as a package with all installed binaries in
> $pkg/sw/bin, configuration in $pkg/etc, etc.. The current system is symlinked to
> /run/current-system, and when a new system is activated this symlink is swapped
> out and therefore all paths are updated atomically. For request-key, this is
> symlinked to
> /run/current-system/sw/bin/request-key
>
> NixOS carries a patch which uses this path instead of /sbin (which does not
> exist on NixOS at all).
>
> The motivation is really "be able to switch /sbin". I feel that all the above are
> secondary motivations and is too verbose to include in the commit message.
>
> I am not a maintainer for NixOS's kernel; I use NixOS and just want to develop
> kernel and test out kernel on my machines without having to patch them.
I don't frankly care how NixOS works per se in details. Scope this into
message to problem that it addresses.
>
> Best,
> Gary
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: Pin request_key_auth payload in instantiate paths
From: Jarkko Sakkinen @ 2026-06-10 10:16 UTC (permalink / raw)
To: Shaomin Chen
Cc: keyrings, linux-security-module, linux-kernel, David Howells,
Paul Moore, James Morris, Serge E. Hallyn
In-Reply-To: <aiZWPSJZyFq4nmxf@kernel.org>
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 v2] keys: prevent slab cache merging for key_jar
From: Jarkko Sakkinen @ 2026-06-10 9:57 UTC (permalink / raw)
To: Mohammed EL Kadiri
Cc: dhowells, paul, jmorris, serge, kees, vbabka, keyrings,
linux-security-module, linux-hardening, linux-kernel
In-Reply-To: <20260610065052.9120-1-med08elkadiri@gmail.com>
On Wed, Jun 10, 2026 at 07:50:52AM +0100, Mohammed EL Kadiri wrote:
> Add SLAB_NO_MERGE to key_jar to prevent the allocator from merging it
> with other similarly-sized caches. This hardens struct key isolation by
> ensuring dedicated slab pages.
>
> Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
> ---
> security/keys/key.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/keys/key.c b/security/keys/key.c
> index 3bbdde778631..592b65cf8539 100644
> --- a/security/keys/key.c
> +++ b/security/keys/key.c
> @@ -1275,7 +1275,7 @@ void __init key_init(void)
> {
> /* allocate a slab in which we can store keys */
> key_jar = kmem_cache_create("key_jar", sizeof(struct key),
> - 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
> + 0, SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_NO_MERGE, NULL);
>
> /* add the special key types */
> list_add_tail(&key_type_keyring.link, &key_types_list);
> --
> 2.43.0
>
I swapped the commit.
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=for-next-keys
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2 1/3] landlock: Require LANDLOCK_ACCESS_FS_MAKE_WHITEOUT for RENAME_WHITEOUT
From: Günther Noack @ 2026-06-10 9:29 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Christian Brauner, linux-security-module, Paul Moore,
Amir Goldstein, Miklos Szeredi, Serge Hallyn, Stephen Smalley
In-Reply-To: <20260609.pait5oaTheHi@digikod.net>
On Tue, Jun 09, 2026 at 06:09:51PM +0200, Mickaël Salaün wrote:
> On Wed, May 13, 2026 at 06:05:50PM +0200, Günther Noack wrote:
> > diff --git a/security/landlock/fs.c b/security/landlock/fs.c
> > index c1ecfe239032..09de6ba5c3a3 100644
> > --- a/security/landlock/fs.c
> > +++ b/security/landlock/fs.c
> > @@ -1519,6 +1519,21 @@ static int hook_path_rename(const struct path *const old_dir,
> > const unsigned int flags)
> > {
> > /* old_dir refers to old_dentry->d_parent and new_dir->mnt */
> > + if (flags & RENAME_WHITEOUT) {
> > + int err;
> > +
> > + /*
> > + * Rename with RENAME_WHITEOUT creates a whiteout object in the
> > + * old location, so we check the access right for creating that.
> > + *
> > + * See Documentation/filesystems/overlayfs.rst and renameat2(2).
> > + */
> > + err = current_check_access_path(
> > + old_dir, LANDLOCK_ACCESS_FS_MAKE_WHITEOUT);
>
> We should not need a second path walk, even if whiteouts are rare.
> Please propose another way.
I sent a V3 with that implemented differently:
https://lore.kernel.org/all/20260610092318.3868884-1-gnoack@google.com/
The tradeoff is that it complicates the common current_check_refer_path() to
solve this fringe use case. In my understanding, the only software using this
is the FUSE OverlayFS implementation.
See the "tradeoffs" section in the V2 cover letter:
https://lore.kernel.org/all/20260513160552.4022649-1-gnoack@google.com/
I slightly prefer V2, but am OK with either variant if needed. Please pick
the one that makes more sense to you.
—Günther
^ permalink raw reply
* [PATCH v3 3/3] selftests/landlock: Test OverlayFS renames w/o LANDLOCK_ACCESS_FS_MAKE_WHITEOUT
From: Günther Noack @ 2026-06-10 9:23 UTC (permalink / raw)
To: Mickaël Salaün, Christian Brauner
Cc: linux-security-module, Paul Moore, Amir Goldstein, Miklos Szeredi,
Serge Hallyn, Stephen Smalley, Günther Noack
In-Reply-To: <20260610092318.3868884-1-gnoack@google.com>
Even though OverlayFS uses vfs_rename() with RENAME_WHITEOUT, and even
though RENAME_WHITEOUT requires LANDLOCK_ACCESS_FS_MAKE_WHITEOUT, a process
that renames files in an OverlayFS can do so without having the
LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right in that location.
This works, and is supposed to work, because OverlayFS uses the credentials
determined at mount time for the internal vfs_rename() operation. -- The
rename happens with the credentials of the user who mounted the OverlayFS.
Signed-off-by: Günther Noack <gnoack@google.com>
---
tools/testing/selftests/landlock/fs_test.c | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
index bdad92195f62..0c29887278d0 100644
--- a/tools/testing/selftests/landlock/fs_test.c
+++ b/tools/testing/selftests/landlock/fs_test.c
@@ -6963,6 +6963,37 @@ TEST_F_FORK(layout2_overlay, same_content_different_file)
}
}
+TEST_F_FORK(layout2_overlay, rename_in_overlay_without_make_whiteout)
+{
+ struct stat st;
+ const char *merge_fl1_renamed = MERGE_DATA "/fl1_renamed";
+
+ if (self->skip_test)
+ SKIP(return, "overlayfs is not supported (test)");
+
+ enforce_fs(_metadata, LANDLOCK_ACCESS_FS_MAKE_WHITEOUT, NULL);
+
+ /*
+ * Execute a regular file rename within OverlayFS.
+ * merge_fl1 originates from lower layer, so this triggers a copy-up
+ * and creation of a whiteout in the upper layer.
+ */
+ EXPECT_EQ(0, rename(merge_fl1, merge_fl1_renamed));
+
+ /* Check that the rename worked. */
+ EXPECT_EQ(0, stat(merge_fl1_renamed, &st));
+ EXPECT_EQ(-1, stat(merge_fl1, &st));
+ EXPECT_EQ(ENOENT, errno);
+
+ /*
+ * Check that the whiteout object on the underlying "upper" filesystem
+ * exists after the rename. This is OK because it was done with the
+ * credentials of the OverlayFS.
+ */
+ EXPECT_EQ(0, stat(UPPER_DATA "/fl1", &st));
+ EXPECT_TRUE(S_ISCHR(st.st_mode));
+ EXPECT_EQ(0, st.st_rdev);
+}
FIXTURE(layout3_fs)
{
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v3 2/3] selftests/landlock: Add test for RENAME_WHITEOUT denial
From: Günther Noack @ 2026-06-10 9:23 UTC (permalink / raw)
To: Mickaël Salaün, Christian Brauner
Cc: linux-security-module, Paul Moore, Amir Goldstein, Miklos Szeredi,
Serge Hallyn, Stephen Smalley, Günther Noack
In-Reply-To: <20260610092318.3868884-1-gnoack@google.com>
Add a test to check that renames with RENAME_WHITEOUT are guarded by
LANDLOCK_ACCESS_FS_MAKE_WHITEOUT.
Signed-off-by: Günther Noack <gnoack@google.com>
---
tools/testing/selftests/landlock/fs_test.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
index 53d1b659849f..bdad92195f62 100644
--- a/tools/testing/selftests/landlock/fs_test.c
+++ b/tools/testing/selftests/landlock/fs_test.c
@@ -2248,6 +2248,19 @@ TEST_F_FORK(layout1, rename_file)
RENAME_EXCHANGE));
}
+TEST_F_FORK(layout1, rename_whiteout_denied)
+{
+ enforce_fs(_metadata, LANDLOCK_ACCESS_FS_MAKE_WHITEOUT, NULL);
+
+ /*
+ * Try to rename a file with RENAME_WHITEOUT.
+ * file1_s3d3 is in dir_s3d2 (tmpfs), so it supports RENAME_WHITEOUT.
+ */
+ EXPECT_EQ(-1, renameat2(AT_FDCWD, file1_s3d3, AT_FDCWD,
+ TMP_DIR "/s3d1/s3d2/s3d3/f2", RENAME_WHITEOUT));
+ EXPECT_EQ(EACCES, errno);
+}
+
TEST_F_FORK(layout1, rename_dir)
{
const struct rule rules[] = {
@@ -6950,6 +6963,7 @@ TEST_F_FORK(layout2_overlay, same_content_different_file)
}
}
+
FIXTURE(layout3_fs)
{
bool has_created_dir;
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v3 1/3] landlock: Require LANDLOCK_ACCESS_FS_MAKE_WHITEOUT for RENAME_WHITEOUT
From: Günther Noack @ 2026-06-10 9:23 UTC (permalink / raw)
To: Mickaël Salaün, Christian Brauner
Cc: linux-security-module, Paul Moore, Amir Goldstein, Miklos Szeredi,
Serge Hallyn, Stephen Smalley, Günther Noack
In-Reply-To: <20260610092318.3868884-1-gnoack@google.com>
renameat2(2) with the RENAME_WHITEOUT flag places a whiteout character
device file in the source file location in place of the moved file.
This creates a directory entry even in cases where all
LANDLOCK_ACCESS_FS_MAKE_* rights are denied.
Introduce the LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right, which is checked
for the origin directory if RENAME_WHITEOUT is passed.
This does not affect normal renames within layered OverlayFS mounts:
When OverlayFS invokes rename with RENAME_WHITEOUT as part of a
"normal" rename operation, it does so in ovl_rename() using the
credentials that were set at the time of mounting the OverlayFS.
Bump the Landlock ABI version to 10.
Suggested-by: Christian Brauner <brauner@kernel.org>
Suggested-by: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Günther Noack <gnoack@google.com>
---
include/uapi/linux/landlock.h | 3 +++
security/landlock/audit.c | 1 +
security/landlock/fs.c | 17 ++++++++++++++---
security/landlock/limits.h | 2 +-
security/landlock/syscalls.c | 2 +-
tools/testing/selftests/landlock/base_test.c | 4 ++--
tools/testing/selftests/landlock/fs_test.c | 5 +++--
7 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/include/uapi/linux/landlock.h b/include/uapi/linux/landlock.h
index 10a346e55e95..1f8a1d6d25f1 100644
--- a/include/uapi/linux/landlock.h
+++ b/include/uapi/linux/landlock.h
@@ -328,6 +328,8 @@ struct landlock_net_port_attr {
*
* If multiple requirements are not met, the ``EACCES`` error code takes
* precedence over ``EXDEV``.
+ * - %LANDLOCK_ACCESS_FS_MAKE_WHITEOUT: Create a whiteout object through
+ * :manpage:`rename(2)` with ``RENAME_WHITEOUT``.
*
* .. warning::
*
@@ -356,6 +358,7 @@ struct landlock_net_port_attr {
#define LANDLOCK_ACCESS_FS_TRUNCATE (1ULL << 14)
#define LANDLOCK_ACCESS_FS_IOCTL_DEV (1ULL << 15)
#define LANDLOCK_ACCESS_FS_RESOLVE_UNIX (1ULL << 16)
+#define LANDLOCK_ACCESS_FS_MAKE_WHITEOUT (1ULL << 17)
/* clang-format on */
/**
diff --git a/security/landlock/audit.c b/security/landlock/audit.c
index 8d0edf94037d..09c97083f599 100644
--- a/security/landlock/audit.c
+++ b/security/landlock/audit.c
@@ -38,6 +38,7 @@ static const char *const fs_access_strings[] = {
[BIT_INDEX(LANDLOCK_ACCESS_FS_TRUNCATE)] = "fs.truncate",
[BIT_INDEX(LANDLOCK_ACCESS_FS_IOCTL_DEV)] = "fs.ioctl_dev",
[BIT_INDEX(LANDLOCK_ACCESS_FS_RESOLVE_UNIX)] = "fs.resolve_unix",
+ [BIT_INDEX(LANDLOCK_ACCESS_FS_MAKE_WHITEOUT)] = "fs.make_whiteout",
};
static_assert(ARRAY_SIZE(fs_access_strings) == LANDLOCK_NUM_ACCESS_FS);
diff --git a/security/landlock/fs.c b/security/landlock/fs.c
index c1ecfe239032..67810d5242b2 100644
--- a/security/landlock/fs.c
+++ b/security/landlock/fs.c
@@ -1080,6 +1080,7 @@ static bool collect_domain_accesses(const struct landlock_ruleset *const domain,
* @new_dentry: Destination file or directory.
* @removable: Sets to true if it is a rename operation.
* @exchange: Sets to true if it is a rename operation with RENAME_EXCHANGE.
+ * @whiteout: Sets to true if it is a rename operation with RENAME_WHITEOUT.
*
* Because of its unprivileged constraints, Landlock relies on file hierarchies
* (and not only inodes) to tie access rights to files. Being able to link or
@@ -1127,7 +1128,8 @@ static bool collect_domain_accesses(const struct landlock_ruleset *const domain,
static int current_check_refer_path(struct dentry *const old_dentry,
const struct path *const new_dir,
struct dentry *const new_dentry,
- const bool removable, const bool exchange)
+ const bool removable, const bool exchange,
+ const bool whiteout)
{
const struct landlock_cred_security *const subject =
landlock_get_applicable_subject(current_cred(), any_fs, NULL);
@@ -1159,6 +1161,14 @@ static int current_check_refer_path(struct dentry *const old_dentry,
access_request_parent2 |= maybe_remove(new_dentry);
}
+ /*
+ * In case of renameat2(2) with RENAME_WHITEOUT, a whiteout object is
+ * created in the source location, so we require an additional access
+ * right there.
+ */
+ if (whiteout)
+ access_request_parent1 |= LANDLOCK_ACCESS_FS_MAKE_WHITEOUT;
+
/* The mount points are the same for old and new paths, cf. EXDEV. */
if (old_dentry->d_parent == new_dir->dentry) {
/*
@@ -1509,7 +1519,7 @@ static int hook_path_link(struct dentry *const old_dentry,
struct dentry *const new_dentry)
{
return current_check_refer_path(old_dentry, new_dir, new_dentry, false,
- false);
+ false, false);
}
static int hook_path_rename(const struct path *const old_dir,
@@ -1520,7 +1530,8 @@ static int hook_path_rename(const struct path *const old_dir,
{
/* old_dir refers to old_dentry->d_parent and new_dir->mnt */
return current_check_refer_path(old_dentry, new_dir, new_dentry, true,
- !!(flags & RENAME_EXCHANGE));
+ !!(flags & RENAME_EXCHANGE),
+ !!(flags & RENAME_WHITEOUT));
}
static int hook_path_mkdir(const struct path *const dir,
diff --git a/security/landlock/limits.h b/security/landlock/limits.h
index b454ad73b15e..e59378e8e897 100644
--- a/security/landlock/limits.h
+++ b/security/landlock/limits.h
@@ -19,7 +19,7 @@
#define LANDLOCK_MAX_NUM_LAYERS 16
#define LANDLOCK_MAX_NUM_RULES U32_MAX
-#define LANDLOCK_LAST_ACCESS_FS LANDLOCK_ACCESS_FS_RESOLVE_UNIX
+#define LANDLOCK_LAST_ACCESS_FS LANDLOCK_ACCESS_FS_MAKE_WHITEOUT
#define LANDLOCK_MASK_ACCESS_FS ((LANDLOCK_LAST_ACCESS_FS << 1) - 1)
#define LANDLOCK_NUM_ACCESS_FS __const_hweight64(LANDLOCK_MASK_ACCESS_FS)
diff --git a/security/landlock/syscalls.c b/security/landlock/syscalls.c
index accfd2e5a0cd..d45469d5d464 100644
--- a/security/landlock/syscalls.c
+++ b/security/landlock/syscalls.c
@@ -166,7 +166,7 @@ static const struct file_operations ruleset_fops = {
* If the change involves a fix that requires userspace awareness, also update
* the errata documentation in Documentation/userspace-api/landlock.rst .
*/
-const int landlock_abi_version = 9;
+const int landlock_abi_version = 10;
/**
* sys_landlock_create_ruleset - Create a new ruleset
diff --git a/tools/testing/selftests/landlock/base_test.c b/tools/testing/selftests/landlock/base_test.c
index 30d37234086c..6c8113c2ded1 100644
--- a/tools/testing/selftests/landlock/base_test.c
+++ b/tools/testing/selftests/landlock/base_test.c
@@ -76,8 +76,8 @@ TEST(abi_version)
const struct landlock_ruleset_attr ruleset_attr = {
.handled_access_fs = LANDLOCK_ACCESS_FS_READ_FILE,
};
- ASSERT_EQ(9, landlock_create_ruleset(NULL, 0,
- LANDLOCK_CREATE_RULESET_VERSION));
+ ASSERT_EQ(10, landlock_create_ruleset(NULL, 0,
+ LANDLOCK_CREATE_RULESET_VERSION));
ASSERT_EQ(-1, landlock_create_ruleset(&ruleset_attr, 0,
LANDLOCK_CREATE_RULESET_VERSION));
diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
index cdb47fc1fc0a..53d1b659849f 100644
--- a/tools/testing/selftests/landlock/fs_test.c
+++ b/tools/testing/selftests/landlock/fs_test.c
@@ -579,7 +579,7 @@ TEST_F_FORK(layout1, inval)
LANDLOCK_ACCESS_FS_IOCTL_DEV | \
LANDLOCK_ACCESS_FS_RESOLVE_UNIX)
-#define ACCESS_LAST LANDLOCK_ACCESS_FS_RESOLVE_UNIX
+#define ACCESS_LAST LANDLOCK_ACCESS_FS_MAKE_WHITEOUT
#define ACCESS_ALL ( \
ACCESS_FILE | \
@@ -593,7 +593,8 @@ TEST_F_FORK(layout1, inval)
LANDLOCK_ACCESS_FS_MAKE_FIFO | \
LANDLOCK_ACCESS_FS_MAKE_BLOCK | \
LANDLOCK_ACCESS_FS_MAKE_SYM | \
- LANDLOCK_ACCESS_FS_REFER)
+ LANDLOCK_ACCESS_FS_REFER | \
+ LANDLOCK_ACCESS_FS_MAKE_WHITEOUT)
/* clang-format on */
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply related
* [PATCH v3 0/3] landlock: Restrict renameat2 with RENAME_WHITEOUT
From: Günther Noack @ 2026-06-10 9:23 UTC (permalink / raw)
To: Mickaël Salaün, Christian Brauner
Cc: linux-security-module, Paul Moore, Amir Goldstein, Miklos Szeredi,
Serge Hallyn, Stephen Smalley, Günther Noack
Hello!
As discussed in [1], the renameat2() syscall's RENAME_WHITEOUT flag allows
the creation of chardev directory entries with major=minor=0 as "whiteout
objects" in the location of the rename source file [2].
This functionality is available even without having any OverlayFS mounted
and can be invoked with the regular renameat2(2) syscall [3].
In V1 [5], it was discussed that whiteout objects are not the same as
character devices, and should therefore be guarded with a separate access
right. We are therefore guarding the operation with the new access right
LANDLOCK_ACCESS_FS_MAKE_WHITEOUT now.
By introducing a new access right, that change is also exposed by
incrementing the ABI level and does not require a Landlock erratum.
Motivation
==========
The RENAME_WHITEOUT flag side-steps all of the existing Landlock access
rights, which are designed to restrict the creation of directory entries.
It is desirable to restrict that.
This patch set fixes that by adding a check in Landlock's path_rename hook.
[1] https://lore.kernel.org/all/adUBCQXrt7kmgqJT@google.com/
[2] https://docs.kernel.org/filesystems/overlayfs.html#whiteouts-and-opaque-directories
[3] https://man7.org/linux/man-pages/man2/renameat2.2.html#DESCRIPTION
[4] https://codesearch.debian.net/search?q=rename.*RENAME_WHITEOUT&literal=0
[5] https://lore.kernel.org/all/20260411090944.3131168-2-gnoack@google.com/
Changelog
=========
v3:
- Do LANDLOCK_ACCESS_FS_MAKE_WHITEOUT check as part of
current_check_refer_path().
v2:
- Introduce LANDLOCK_ACCESS_FS_MAKE_WHITEOUT access right
and guard it with that.
- Bump ABI version
- https://lore.kernel.org/all/20260513160552.4022649-1-gnoack@google.com/
v1:
- initial version
https://lore.kernel.org/all/20260411090944.3131168-2-gnoack@google.com/
Günther Noack (3):
landlock: Require LANDLOCK_ACCESS_FS_MAKE_WHITEOUT for RENAME_WHITEOUT
selftests/landlock: Add test for RENAME_WHITEOUT denial
selftests/landlock: Test OverlayFS renames w/o
LANDLOCK_ACCESS_FS_MAKE_WHITEOUT
include/uapi/linux/landlock.h | 3 ++
security/landlock/audit.c | 1 +
security/landlock/fs.c | 17 +++++--
security/landlock/limits.h | 2 +-
security/landlock/syscalls.c | 2 +-
tools/testing/selftests/landlock/base_test.c | 4 +-
tools/testing/selftests/landlock/fs_test.c | 50 +++++++++++++++++++-
7 files changed, 70 insertions(+), 9 deletions(-)
Range-diff against v2:
1: 1f2b7f49b927 ! 1: 4a8c3fb9e707 landlock: Require LANDLOCK_ACCESS_FS_MAKE_WHITEOUT for RENAME_WHITEOUT
@@ security/landlock/audit.c: static const char *const fs_access_strings[] = {
static_assert(ARRAY_SIZE(fs_access_strings) == LANDLOCK_NUM_ACCESS_FS);
## security/landlock/fs.c ##
+@@ security/landlock/fs.c: static bool collect_domain_accesses(const struct landlock_ruleset *const domain,
+ * @new_dentry: Destination file or directory.
+ * @removable: Sets to true if it is a rename operation.
+ * @exchange: Sets to true if it is a rename operation with RENAME_EXCHANGE.
++ * @whiteout: Sets to true if it is a rename operation with RENAME_WHITEOUT.
+ *
+ * Because of its unprivileged constraints, Landlock relies on file hierarchies
+ * (and not only inodes) to tie access rights to files. Being able to link or
+@@ security/landlock/fs.c: static bool collect_domain_accesses(const struct landlock_ruleset *const domain,
+ static int current_check_refer_path(struct dentry *const old_dentry,
+ const struct path *const new_dir,
+ struct dentry *const new_dentry,
+- const bool removable, const bool exchange)
++ const bool removable, const bool exchange,
++ const bool whiteout)
+ {
+ const struct landlock_cred_security *const subject =
+ landlock_get_applicable_subject(current_cred(), any_fs, NULL);
+@@ security/landlock/fs.c: static int current_check_refer_path(struct dentry *const old_dentry,
+ access_request_parent2 |= maybe_remove(new_dentry);
+ }
+
++ /*
++ * In case of renameat2(2) with RENAME_WHITEOUT, a whiteout object is
++ * created in the source location, so we require an additional access
++ * right there.
++ */
++ if (whiteout)
++ access_request_parent1 |= LANDLOCK_ACCESS_FS_MAKE_WHITEOUT;
++
+ /* The mount points are the same for old and new paths, cf. EXDEV. */
+ if (old_dentry->d_parent == new_dir->dentry) {
+ /*
+@@ security/landlock/fs.c: static int hook_path_link(struct dentry *const old_dentry,
+ struct dentry *const new_dentry)
+ {
+ return current_check_refer_path(old_dentry, new_dir, new_dentry, false,
+- false);
++ false, false);
+ }
+
+ static int hook_path_rename(const struct path *const old_dir,
@@ security/landlock/fs.c: static int hook_path_rename(const struct path *const old_dir,
- const unsigned int flags)
{
/* old_dir refers to old_dentry->d_parent and new_dir->mnt */
-+ if (flags & RENAME_WHITEOUT) {
-+ int err;
-+
-+ /*
-+ * Rename with RENAME_WHITEOUT creates a whiteout object in the
-+ * old location, so we check the access right for creating that.
-+ *
-+ * See Documentation/filesystems/overlayfs.rst and renameat2(2).
-+ */
-+ err = current_check_access_path(
-+ old_dir, LANDLOCK_ACCESS_FS_MAKE_WHITEOUT);
-+ if (err)
-+ return err;
-+ }
-+
return current_check_refer_path(old_dentry, new_dir, new_dentry, true,
- !!(flags & RENAME_EXCHANGE));
+- !!(flags & RENAME_EXCHANGE));
++ !!(flags & RENAME_EXCHANGE),
++ !!(flags & RENAME_WHITEOUT));
}
+
+ static int hook_path_mkdir(const struct path *const dir,
## security/landlock/limits.h ##
@@
2: aa4e4aeb5884 = 2: 063646822083 selftests/landlock: Add test for RENAME_WHITEOUT denial
3: 6660d70a1eda = 3: 5d4606bc1e84 selftests/landlock: Test OverlayFS renames w/o LANDLOCK_ACCESS_FS_MAKE_WHITEOUT
--
2.54.0.1099.g489fc7bff1-goog
^ permalink raw reply
* [PATCH v2] keys: prevent slab cache merging for key_jar
From: Mohammed EL Kadiri @ 2026-06-10 6:50 UTC (permalink / raw)
To: dhowells, jarkko
Cc: paul, jmorris, serge, kees, vbabka, keyrings,
linux-security-module, linux-hardening, linux-kernel,
Mohammed EL Kadiri
Add SLAB_NO_MERGE to key_jar to prevent the allocator from merging it
with other similarly-sized caches. This hardens struct key isolation by
ensuring dedicated slab pages.
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
---
security/keys/key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/keys/key.c b/security/keys/key.c
index 3bbdde778631..592b65cf8539 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -1275,7 +1275,7 @@ void __init key_init(void)
{
/* allocate a slab in which we can store keys */
key_jar = kmem_cache_create("key_jar", sizeof(struct key),
- 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
+ 0, SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_NO_MERGE, NULL);
/* add the special key types */
list_add_tail(&key_type_keyring.link, &key_types_list);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 00/16] Bump minimum version of LLVM for building the kernel to 17.0.1
From: Nathan Chancellor @ 2026-06-09 23:28 UTC (permalink / raw)
To: Nicolas Schier, Bill Wendling, Justin Stitt, Nick Desaulniers,
Nathan Chancellor
Cc: linux-kernel, llvm, linux-kbuild, Jonathan Corbet, Shuah Khan,
linux-doc, Kees Cook, Gustavo A. R. Silva, linux-hardening,
linux-security-module, Rong Xu, Han Shen, Russell King,
Arnd Bergmann, linux-arm-kernel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, linux-riscv, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Ard Biesheuvel, Peter Zijlstra
In-Reply-To: <20260517-bump-minimum-supported-llvm-version-to-17-v2-0-b3b8cda46bdd@kernel.org>
On Sun, 17 May 2026 13:05:03 -1000, Nathan Chancellor wrote:
> Bump minimum version of LLVM for building the kernel to 17.0.1
>
> The current minimum version of LLVM for building the kernel is 15.0.0.
> However, there are two deficiencies compared to GCC that were fixed in
> LLVM 17 that are starting to become more noticeable.
>
> The first was a bug in LLVM's scope checker [1], where all labels in a
> function were validated as potential targets of an asm goto statement,
> even if they were not listed in the asm goto statement as targets. This
> becomes particularly problematic when the cleanup attribute is used, as
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux.git kbuild-next
Thanks!
[01/16] kbuild: Bump minimum version of LLVM for building the kernel to 17.0.1
https://git.kernel.org/kbuild/c/ce3267a39a92b
[02/16] security/Kconfig.hardening: Remove tautological condition from CC_HAS_ZERO_CALL_USED_REGS
https://git.kernel.org/kbuild/c/813fe686e90b4
[03/16] security/Kconfig.hardening: Remove tautological condition from FORTIFY_SOURCE
https://git.kernel.org/kbuild/c/8ad2017578c99
[04/16] security/Kconfig.hardening: Remove tautological condition from CC_HAS_RANDSTRUCT
https://git.kernel.org/kbuild/c/9331258bc129a
[05/16] arch/Kconfig: Remove tautological conditions from HAS_LTO_CLANG
https://git.kernel.org/kbuild/c/2189cb1a80f06
[06/16] arch/Kconfig: Remove tautological condition from AUTOFDO_CLANG
https://git.kernel.org/kbuild/c/de0bf1e138fcd
[07/16] ARM: Drop tautological ld.lld conditions from ARCH_MULTI_V4{,T}
https://git.kernel.org/kbuild/c/48d229b6a48ae
[08/16] riscv: Remove tautological condition from selection of ARCH_SUPPORTS_CFI
https://git.kernel.org/kbuild/c/62c4af8689511
[09/16] riscv: Drop tautological condition from TOOLCHAIN_NEEDS_OLD_ISA_SPEC
https://git.kernel.org/kbuild/c/7e279976cf2a2
[10/16] scripts/Makefile.warn: Drop -Wformat handling for clang < 16
https://git.kernel.org/kbuild/c/2a35c63c6bc42
[11/16] x86/build: Drop unnecessary '-ffreestanding' addition to KBUILD_CFLAGS
https://git.kernel.org/kbuild/c/7b3281fcb43c5
[12/16] x86/module: Revert "Deal with GOT based stack cookie load on Clang < 17"
https://git.kernel.org/kbuild/c/12b7bf92bddd4
[13/16] x86/entry/vdso32: Remove conditional omission of '.cfi_offset eflags'
https://git.kernel.org/kbuild/c/4e7af20d0d104
[14/16] kbuild: Remove check for broken scoping with clang < 17 in CC_HAS_ASM_GOTO_OUTPUT
https://git.kernel.org/kbuild/c/f3de78cb19d12
[15/16] compiler-clang.h: Remove __cleanup -Wunused-variable workaround
https://git.kernel.org/kbuild/c/c69eaa687667e
[16/16] compiler-clang.h: Drop explicit version number from "all" diagnostic macro
https://git.kernel.org/kbuild/c/c919893eabb43
Please look out for regression or issue reports or other follow up
comments, as they may result in the patch/series getting dropped or
reverted. Patches applied to an "unstable" branch are accepted pending
wider testing in -next and any post-commit review; they will generally
be moved to the main branch in a week if no issues are found.
Best regards,
--
Cheers,
Nathan
^ permalink raw reply
* [PATCH 2/2] landlock: replace __sk_common struct sock field accesses
From: Matthieu Buffet @ 2026-06-09 21:15 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Matthieu Buffet, Günther Noack, Mikhail Ivanov, Tingmao Wang,
konstantin.meskhidze, linux-security-module
In-Reply-To: <20260609211511.85630-1-matthieu@buffet.re>
Use the proper macro to access __sk_common.skc_family like everywhere
else.
Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
---
security/landlock/net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/landlock/net.c b/security/landlock/net.c
index 111e58fd9325..fc2acf8bd898 100644
--- a/security/landlock/net.c
+++ b/security/landlock/net.c
@@ -71,7 +71,7 @@ static int current_check_access_socket(struct socket *const sock,
* The socket is not locked, so sk_family can change concurrently
* due to e.g. setsockopt(IPV6_ADDRFORM).
*/
- sock_family = READ_ONCE(sock->sk->__sk_common.skc_family);
+ sock_family = READ_ONCE(sock->sk->sk_family);
switch (address->sa_family) {
case AF_UNSPEC:
--
2.47.3
^ permalink raw reply related
* [PATCH 1/2] landlock: Fix unmarked concurrent access to socket family
From: Matthieu Buffet @ 2026-06-09 21:15 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Matthieu Buffet, Günther Noack, Mikhail Ivanov, Tingmao Wang,
konstantin.meskhidze, linux-security-module
In-Reply-To: <e561a8c3-de10-45ba-a931-27b9a5751dc9@buffet.re>
Socket family is read (twice) in a context where the socket is not
locked, so another thread can setsockopt(IPV6_ADDRFORM) to write it
concurrently. Add needed READ_ONCE() annotation.
Fixes: fff69fb03dde ("landlock: Support network rules with TCP bind and connect")
Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
---
security/landlock/net.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/security/landlock/net.c b/security/landlock/net.c
index a38bdfcffc22..111e58fd9325 100644
--- a/security/landlock/net.c
+++ b/security/landlock/net.c
@@ -55,6 +55,7 @@ static int current_check_access_socket(struct socket *const sock,
const struct access_masks masks = {
.net = access_request,
};
+ unsigned short sock_family;
const struct landlock_cred_security *const subject =
landlock_get_applicable_subject(current_cred(), masks, NULL);
struct lsm_network_audit audit_net = {};
@@ -66,6 +67,12 @@ static int current_check_access_socket(struct socket *const sock,
if (addrlen < offsetofend(typeof(*address), sa_family))
return -EINVAL;
+ /*
+ * The socket is not locked, so sk_family can change concurrently
+ * due to e.g. setsockopt(IPV6_ADDRFORM).
+ */
+ sock_family = READ_ONCE(sock->sk->__sk_common.skc_family);
+
switch (address->sa_family) {
case AF_UNSPEC:
if (access_request == LANDLOCK_ACCESS_NET_CONNECT_TCP) {
@@ -102,7 +109,7 @@ static int current_check_access_socket(struct socket *const sock,
* these checks, but it is safer to return a proper
* error and test consistency thanks to kselftest.
*/
- if (sock->sk->__sk_common.skc_family == AF_INET) {
+ if (sock_family == AF_INET) {
const struct sockaddr_in *const sockaddr =
(struct sockaddr_in *)address;
@@ -180,7 +187,7 @@ static int current_check_access_socket(struct socket *const sock,
* check, but it is safer to return a proper error and test
* consistency thanks to kselftest.
*/
- if (address->sa_family != sock->sk->__sk_common.skc_family &&
+ if (address->sa_family != sock_family &&
address->sa_family != AF_UNSPEC)
return -EINVAL;
base-commit: 4c403b9ffc86358d5ae50e4121aaf541bdab04d8
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 1/3] landlock: Require LANDLOCK_ACCESS_FS_MAKE_WHITEOUT for RENAME_WHITEOUT
From: Mickaël Salaün @ 2026-06-09 16:09 UTC (permalink / raw)
To: Günther Noack
Cc: Christian Brauner, linux-security-module, Paul Moore,
Amir Goldstein, Miklos Szeredi, Serge Hallyn, Stephen Smalley
In-Reply-To: <20260513160552.4022649-2-gnoack@google.com>
On Wed, May 13, 2026 at 06:05:50PM +0200, Günther Noack wrote:
> renameat2(2) with the RENAME_WHITEOUT flag places a whiteout character
> device file in the source file location in place of the moved file.
> This creates a directory entry even in cases where all
> LANDLOCK_ACCESS_FS_MAKE_* rights are denied.
>
> Introduce the LANDLOCK_ACCESS_FS_MAKE_WHITEOUT right, which is checked
> for the origin directory if RENAME_WHITEOUT is passed.
>
> This does not affect normal renames within layered OverlayFS mounts:
> When OverlayFS invokes rename with RENAME_WHITEOUT as part of a
> "normal" rename operation, it does so in ovl_rename() using the
> credentials that were set at the time of mounting the OverlayFS.
>
> Bump the Landlock ABI version to 10.
>
> Suggested-by: Christian Brauner <brauner@kernel.org>
> Suggested-by: Mickaël Salaün <mic@digikod.net>
> Signed-off-by: Günther Noack <gnoack@google.com>
> ---
> include/uapi/linux/landlock.h | 3 +++
> security/landlock/audit.c | 1 +
> security/landlock/fs.c | 15 +++++++++++++++
> security/landlock/limits.h | 2 +-
> security/landlock/syscalls.c | 2 +-
> tools/testing/selftests/landlock/base_test.c | 4 ++--
> tools/testing/selftests/landlock/fs_test.c | 5 +++--
> 7 files changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/include/uapi/linux/landlock.h b/include/uapi/linux/landlock.h
> index 10a346e55e95..1f8a1d6d25f1 100644
> --- a/include/uapi/linux/landlock.h
> +++ b/include/uapi/linux/landlock.h
> @@ -328,6 +328,8 @@ struct landlock_net_port_attr {
> *
> * If multiple requirements are not met, the ``EACCES`` error code takes
> * precedence over ``EXDEV``.
> + * - %LANDLOCK_ACCESS_FS_MAKE_WHITEOUT: Create a whiteout object through
> + * :manpage:`rename(2)` with ``RENAME_WHITEOUT``.
> *
> * .. warning::
> *
> @@ -356,6 +358,7 @@ struct landlock_net_port_attr {
> #define LANDLOCK_ACCESS_FS_TRUNCATE (1ULL << 14)
> #define LANDLOCK_ACCESS_FS_IOCTL_DEV (1ULL << 15)
> #define LANDLOCK_ACCESS_FS_RESOLVE_UNIX (1ULL << 16)
> +#define LANDLOCK_ACCESS_FS_MAKE_WHITEOUT (1ULL << 17)
> /* clang-format on */
>
> /**
> diff --git a/security/landlock/audit.c b/security/landlock/audit.c
> index 8d0edf94037d..09c97083f599 100644
> --- a/security/landlock/audit.c
> +++ b/security/landlock/audit.c
> @@ -38,6 +38,7 @@ static const char *const fs_access_strings[] = {
> [BIT_INDEX(LANDLOCK_ACCESS_FS_TRUNCATE)] = "fs.truncate",
> [BIT_INDEX(LANDLOCK_ACCESS_FS_IOCTL_DEV)] = "fs.ioctl_dev",
> [BIT_INDEX(LANDLOCK_ACCESS_FS_RESOLVE_UNIX)] = "fs.resolve_unix",
> + [BIT_INDEX(LANDLOCK_ACCESS_FS_MAKE_WHITEOUT)] = "fs.make_whiteout",
> };
>
> static_assert(ARRAY_SIZE(fs_access_strings) == LANDLOCK_NUM_ACCESS_FS);
> diff --git a/security/landlock/fs.c b/security/landlock/fs.c
> index c1ecfe239032..09de6ba5c3a3 100644
> --- a/security/landlock/fs.c
> +++ b/security/landlock/fs.c
> @@ -1519,6 +1519,21 @@ static int hook_path_rename(const struct path *const old_dir,
> const unsigned int flags)
> {
> /* old_dir refers to old_dentry->d_parent and new_dir->mnt */
> + if (flags & RENAME_WHITEOUT) {
> + int err;
> +
> + /*
> + * Rename with RENAME_WHITEOUT creates a whiteout object in the
> + * old location, so we check the access right for creating that.
> + *
> + * See Documentation/filesystems/overlayfs.rst and renameat2(2).
> + */
> + err = current_check_access_path(
> + old_dir, LANDLOCK_ACCESS_FS_MAKE_WHITEOUT);
We should not need a second path walk, even if whiteouts are rare.
Please propose another way.
> + if (err)
> + return err;
> + }
> +
> return current_check_refer_path(old_dentry, new_dir, new_dentry, true,
> !!(flags & RENAME_EXCHANGE));
> }
> diff --git a/security/landlock/limits.h b/security/landlock/limits.h
> index b454ad73b15e..e59378e8e897 100644
> --- a/security/landlock/limits.h
> +++ b/security/landlock/limits.h
> @@ -19,7 +19,7 @@
> #define LANDLOCK_MAX_NUM_LAYERS 16
> #define LANDLOCK_MAX_NUM_RULES U32_MAX
>
> -#define LANDLOCK_LAST_ACCESS_FS LANDLOCK_ACCESS_FS_RESOLVE_UNIX
> +#define LANDLOCK_LAST_ACCESS_FS LANDLOCK_ACCESS_FS_MAKE_WHITEOUT
> #define LANDLOCK_MASK_ACCESS_FS ((LANDLOCK_LAST_ACCESS_FS << 1) - 1)
> #define LANDLOCK_NUM_ACCESS_FS __const_hweight64(LANDLOCK_MASK_ACCESS_FS)
>
> diff --git a/security/landlock/syscalls.c b/security/landlock/syscalls.c
> index accfd2e5a0cd..d45469d5d464 100644
> --- a/security/landlock/syscalls.c
> +++ b/security/landlock/syscalls.c
> @@ -166,7 +166,7 @@ static const struct file_operations ruleset_fops = {
> * If the change involves a fix that requires userspace awareness, also update
> * the errata documentation in Documentation/userspace-api/landlock.rst .
> */
> -const int landlock_abi_version = 9;
> +const int landlock_abi_version = 10;
>
> /**
> * sys_landlock_create_ruleset - Create a new ruleset
> diff --git a/tools/testing/selftests/landlock/base_test.c b/tools/testing/selftests/landlock/base_test.c
> index 30d37234086c..6c8113c2ded1 100644
> --- a/tools/testing/selftests/landlock/base_test.c
> +++ b/tools/testing/selftests/landlock/base_test.c
> @@ -76,8 +76,8 @@ TEST(abi_version)
> const struct landlock_ruleset_attr ruleset_attr = {
> .handled_access_fs = LANDLOCK_ACCESS_FS_READ_FILE,
> };
> - ASSERT_EQ(9, landlock_create_ruleset(NULL, 0,
> - LANDLOCK_CREATE_RULESET_VERSION));
> + ASSERT_EQ(10, landlock_create_ruleset(NULL, 0,
> + LANDLOCK_CREATE_RULESET_VERSION));
>
> ASSERT_EQ(-1, landlock_create_ruleset(&ruleset_attr, 0,
> LANDLOCK_CREATE_RULESET_VERSION));
> diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
> index cdb47fc1fc0a..53d1b659849f 100644
> --- a/tools/testing/selftests/landlock/fs_test.c
> +++ b/tools/testing/selftests/landlock/fs_test.c
> @@ -579,7 +579,7 @@ TEST_F_FORK(layout1, inval)
> LANDLOCK_ACCESS_FS_IOCTL_DEV | \
> LANDLOCK_ACCESS_FS_RESOLVE_UNIX)
>
> -#define ACCESS_LAST LANDLOCK_ACCESS_FS_RESOLVE_UNIX
> +#define ACCESS_LAST LANDLOCK_ACCESS_FS_MAKE_WHITEOUT
>
> #define ACCESS_ALL ( \
> ACCESS_FILE | \
> @@ -593,7 +593,8 @@ TEST_F_FORK(layout1, inval)
> LANDLOCK_ACCESS_FS_MAKE_FIFO | \
> LANDLOCK_ACCESS_FS_MAKE_BLOCK | \
> LANDLOCK_ACCESS_FS_MAKE_SYM | \
> - LANDLOCK_ACCESS_FS_REFER)
> + LANDLOCK_ACCESS_FS_REFER | \
> + LANDLOCK_ACCESS_FS_MAKE_WHITEOUT)
>
> /* clang-format on */
>
> --
> 2.54.0.563.g4f69b47b94-goog
>
>
^ permalink raw reply
* Re: [PATCH v2] tpm: use a map for tpm2_calc_ordinal_duration()
From: Jarkko Sakkinen @ 2026-06-09 15:44 UTC (permalink / raw)
To: Benoit HOUYERE
Cc: Serge E. Hallyn, linux-integrity@vger.kernel.org,
Frédéric Jouen, Peter Huewe, Jason Gunthorpe,
James Bottomley, Mimi Zohar, David Howells, Paul Moore,
James Morris, open list, open list:KEYS-TRUSTED,
open list:SECURITY SUBSYSTEM, Laurent CHARPENTIER
In-Reply-To: <DB5PR10MB766844D5478D63272584A12AFE1C2@DB5PR10MB7668.EURPRD10.PROD.OUTLOOK.COM>
On Mon, Jun 08, 2026 at 02:46:28PM +0000, Benoit HOUYERE wrote:
> Hello Serge and Jarkko,
>
>
> We have detected a regression with this fix. Indeed, it miss one zero on TPM_LONG_LONG. Initial value was 300000 and not 30000.
>
> > + {TPM2_CC_CREATE_PRIMARY, 30000},
> > + {TPM2_CC_CREATE, 30000},
> > + {TPM2_CC_CREATE_LOADED, 30000},
>
> > +enum tpm2_durations {
> > TPM2_DURATION_SHORT = 20,
> > - TPM2_DURATION_MEDIUM = 750,
> > TPM2_DURATION_LONG = 2000,
> > - TPM2_DURATION_LONG_LONG = 300000,
> > TPM2_DURATION_DEFAULT = 120000,
> > };
>
> Best Regards, Cordialement, Cordialmente, Hälsningar, 最好的问候, Mit besten Grüßen, 真心を込めて, 진심으로
>
>
> Benoit HOUYERE | Tel: +33 6 14 22 81 30
> TPM specialist
This has been fixed in 478a3f949a43822dc6ce089345ae80e8dcde3300.
>
> -----Original Message-----
> From: Serge E. Hallyn <serge@hallyn.com>
> Sent: Friday, September 19, 2025 5:49 AM
> To: Jarkko Sakkinen <jarkko@kernel.org>
> Cc: linux-integrity@vger.kernel.org; Frédéric Jouen <fjouen@sealsq.com>; Peter Huewe <peterhuewe@gmx.de>; Jason Gunthorpe <jgg@ziepe.ca>; James Bottomley <James.Bottomley@hansenpartnership.com>; Mimi Zohar <zohar@linux.ibm.com>; David Howells <dhowells@redhat.com>; Paul Moore <paul@paul-moore.com>; James Morris <jmorris@namei.org>; Serge E. Hallyn <serge@hallyn.com>; open list <linux-kernel@vger.kernel.org>; open list:KEYS-TRUSTED <keyrings@vger.kernel.org>; open list:SECURITY SUBSYSTEM <linux-security-module@vger.kernel.org>
> Subject: Re: [PATCH v2] tpm: use a map for tpm2_calc_ordinal_duration()
>
> On Thu, Sep 18, 2025 at 10:30:18PM +0300, Jarkko Sakkinen wrote:
> > The current shenanigans for duration calculation introduce too much
> > complexity for a trivial problem, and further the code is hard to
> > patch and maintain.
> >
> > Address these issues with a flat look-up table, which is easy to
> > understand and patch. If leaf driver specific patching is required in
> > future, it is easy enough to make a copy of this table during driver
> > initialization and add the chip parameter back.
> >
> > 'chip->duration' is retained for TPM 1.x.
> >
> > As the first entry for this new behavior address TCG spec update
> > mentioned in this issue:
> >
> > https://github.com/raspberrypi/linux/issues/7054
> >
> > Therefore, for TPM_SelfTest the duration is set to 3000 ms.
> >
> > This does not categorize a as bug, given that this is introduced to
> > the spec after the feature was originally made.
> >
> > Cc: Frédéric Jouen <fjouen@sealsq.com>
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
>
> fwiw (which shouldn't be much) looks good to me, but two questions, one here and one below.
>
> First, it looks like in the existing code it is possible for a tpm2 chip to set its own timeouts and then set the TPM_CHIP_FLAG_HAVE_TIMEOUTS flag to avoid using the defaults, but I don't see anything using that in-tree. Is it possible that there are out of tree drivers that will be sabotaged here? Or am I misunderstanding that completely?
>
> > ---
> > v2:
> > - Add the missing msec_to_jiffies() calls.
> > - Drop redundant stuff.
> > ---
> > drivers/char/tpm/tpm-interface.c | 2 +-
> > drivers/char/tpm/tpm.h | 2 +-
> > drivers/char/tpm/tpm2-cmd.c | 127 ++++++++-----------------------
> > include/linux/tpm.h | 5 +-
> > 4 files changed, 37 insertions(+), 99 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm-interface.c
> > b/drivers/char/tpm/tpm-interface.c
> > index b71725827743..c9f173001d0e 100644
> > --- a/drivers/char/tpm/tpm-interface.c
> > +++ b/drivers/char/tpm/tpm-interface.c
> > @@ -52,7 +52,7 @@ MODULE_PARM_DESC(suspend_pcr, unsigned long
> > tpm_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal) {
> > if (chip->flags & TPM_CHIP_FLAG_TPM2)
> > - return tpm2_calc_ordinal_duration(chip, ordinal);
> > + return tpm2_calc_ordinal_duration(ordinal);
> > else
> > return tpm1_calc_ordinal_duration(chip, ordinal); } diff --git
> > a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index
> > 7bb87fa5f7a1..2726bd38e5ac 100644
> > --- a/drivers/char/tpm/tpm.h
> > +++ b/drivers/char/tpm/tpm.h
> > @@ -299,7 +299,7 @@ ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32
> > property_id, ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip);
> > int tpm2_auto_startup(struct tpm_chip *chip); void
> > tpm2_shutdown(struct tpm_chip *chip, u16 shutdown_type); -unsigned
> > long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
> > +unsigned long tpm2_calc_ordinal_duration(u32 ordinal);
> > int tpm2_probe(struct tpm_chip *chip); int
> > tpm2_get_cc_attrs_tbl(struct tpm_chip *chip); int tpm2_find_cc(struct
> > tpm_chip *chip, u32 cc); diff --git a/drivers/char/tpm/tpm2-cmd.c
> > b/drivers/char/tpm/tpm2-cmd.c index 524d802ede26..7d77f6fbc152 100644
> > --- a/drivers/char/tpm/tpm2-cmd.c
> > +++ b/drivers/char/tpm/tpm2-cmd.c
> > @@ -28,120 +28,57 @@ static struct tpm2_hash tpm2_hash_map[] = {
> >
> > int tpm2_get_timeouts(struct tpm_chip *chip) {
> > - /* Fixed timeouts for TPM2 */
> > chip->timeout_a = msecs_to_jiffies(TPM2_TIMEOUT_A);
> > chip->timeout_b = msecs_to_jiffies(TPM2_TIMEOUT_B);
> > chip->timeout_c = msecs_to_jiffies(TPM2_TIMEOUT_C);
> > chip->timeout_d = msecs_to_jiffies(TPM2_TIMEOUT_D);
> > -
> > - /* PTP spec timeouts */
> > - chip->duration[TPM_SHORT] = msecs_to_jiffies(TPM2_DURATION_SHORT);
> > - chip->duration[TPM_MEDIUM] = msecs_to_jiffies(TPM2_DURATION_MEDIUM);
> > - chip->duration[TPM_LONG] = msecs_to_jiffies(TPM2_DURATION_LONG);
> > -
> > - /* Key creation commands long timeouts */
> > - chip->duration[TPM_LONG_LONG] =
> > - msecs_to_jiffies(TPM2_DURATION_LONG_LONG);
> > -
> > chip->flags |= TPM_CHIP_FLAG_HAVE_TIMEOUTS;
> > -
> > return 0;
> > }
> >
> > -/**
> > - * tpm2_ordinal_duration_index() - returns an index to the chip
> > duration table
> > - * @ordinal: TPM command ordinal.
> > - *
> > - * The function returns an index to the chip duration table
> > - * (enum tpm_duration), that describes the maximum amount of
> > - * time the chip could take to return the result for a particular ordinal.
> > - *
> > - * The values of the MEDIUM, and LONG durations are taken
> > - * from the PC Client Profile (PTP) specification (750, 2000 msec)
> > - *
> > - * LONG_LONG is for commands that generates keys which empirically
> > takes
> > - * a longer time on some systems.
> > - *
> > - * Return:
> > - * * TPM_MEDIUM
> > - * * TPM_LONG
> > - * * TPM_LONG_LONG
> > - * * TPM_UNDEFINED
> > +/*
> > + * Contains the maximum durations in milliseconds for TPM2 commands.
> > */
> > -static u8 tpm2_ordinal_duration_index(u32 ordinal) -{
> > - switch (ordinal) {
> > - /* Startup */
> > - case TPM2_CC_STARTUP: /* 144 */
> > - return TPM_MEDIUM;
> > -
> > - case TPM2_CC_SELF_TEST: /* 143 */
> > - return TPM_LONG;
> > -
> > - case TPM2_CC_GET_RANDOM: /* 17B */
> > - return TPM_LONG;
> > -
> > - case TPM2_CC_SEQUENCE_UPDATE: /* 15C */
> > - return TPM_MEDIUM;
> > - case TPM2_CC_SEQUENCE_COMPLETE: /* 13E */
> > - return TPM_MEDIUM;
> > - case TPM2_CC_EVENT_SEQUENCE_COMPLETE: /* 185 */
> > - return TPM_MEDIUM;
> > - case TPM2_CC_HASH_SEQUENCE_START: /* 186 */
> > - return TPM_MEDIUM;
> > -
> > - case TPM2_CC_VERIFY_SIGNATURE: /* 177 */
> > - return TPM_LONG_LONG;
> > -
> > - case TPM2_CC_PCR_EXTEND: /* 182 */
> > - return TPM_MEDIUM;
> > -
> > - case TPM2_CC_HIERARCHY_CONTROL: /* 121 */
> > - return TPM_LONG;
> > - case TPM2_CC_HIERARCHY_CHANGE_AUTH: /* 129 */
> > - return TPM_LONG;
> > -
> > - case TPM2_CC_GET_CAPABILITY: /* 17A */
> > - return TPM_MEDIUM;
> > -
> > - case TPM2_CC_NV_READ: /* 14E */
> > - return TPM_LONG;
> > -
> > - case TPM2_CC_CREATE_PRIMARY: /* 131 */
> > - return TPM_LONG_LONG;
> > - case TPM2_CC_CREATE: /* 153 */
> > - return TPM_LONG_LONG;
> > - case TPM2_CC_CREATE_LOADED: /* 191 */
> > - return TPM_LONG_LONG;
> > -
> > - default:
> > - return TPM_UNDEFINED;
> > - }
> > -}
> > +static const struct {
> > + unsigned long ordinal;
> > + unsigned long duration;
> > +} tpm2_ordinal_duration_map[] = {
> > + {TPM2_CC_STARTUP, 750},
> > + {TPM2_CC_SELF_TEST, 3000},
>
> I assume you intended to increase TPM2_CC_SELF_TEST from 2000 to 3000 here? But it's not mentioned in the commit, so making sure...
>
> > + {TPM2_CC_GET_RANDOM, 2000},
> > + {TPM2_CC_SEQUENCE_UPDATE, 750},
> > + {TPM2_CC_SEQUENCE_COMPLETE, 750},
> > + {TPM2_CC_EVENT_SEQUENCE_COMPLETE, 750},
> > + {TPM2_CC_HASH_SEQUENCE_START, 750},
> > + {TPM2_CC_VERIFY_SIGNATURE, 30000},
> > + {TPM2_CC_PCR_EXTEND, 750},
> > + {TPM2_CC_HIERARCHY_CONTROL, 2000},
> > + {TPM2_CC_HIERARCHY_CHANGE_AUTH, 2000},
> > + {TPM2_CC_GET_CAPABILITY, 750},
> > + {TPM2_CC_NV_READ, 2000},
> > + {TPM2_CC_CREATE_PRIMARY, 30000},
> > + {TPM2_CC_CREATE, 30000},
> > + {TPM2_CC_CREATE_LOADED, 30000},
> > +};
> >
> > /**
> > - * tpm2_calc_ordinal_duration() - calculate the maximum command duration
> > - * @chip: TPM chip to use.
> > + * tpm2_calc_ordinal_duration() - Calculate the maximum command
> > + duration
> > * @ordinal: TPM command ordinal.
> > *
> > - * The function returns the maximum amount of time the chip could
> > take
> > - * to return the result for a particular ordinal in jiffies.
> > - *
> > - * Return: A maximal duration time for an ordinal in jiffies.
> > + * Returns the maximum amount of time the chip is expected by kernel
> > + to
> > + * take in jiffies.
> > */
> > -unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32
> > ordinal)
> > +unsigned long tpm2_calc_ordinal_duration(u32 ordinal)
> > {
> > - unsigned int index;
> > + int i;
> >
> > - index = tpm2_ordinal_duration_index(ordinal);
> > + for (i = 0; i < ARRAY_SIZE(tpm2_ordinal_duration_map); i++)
> > + if (ordinal == tpm2_ordinal_duration_map[i].ordinal)
> > + return msecs_to_jiffies(tpm2_ordinal_duration_map[i].duration);
> >
> > - if (index != TPM_UNDEFINED)
> > - return chip->duration[index];
> > - else
> > - return msecs_to_jiffies(TPM2_DURATION_DEFAULT);
> > + return msecs_to_jiffies(TPM2_DURATION_DEFAULT);
> > }
> >
> > -
> > struct tpm2_pcr_read_out {
> > __be32 update_cnt;
> > __be32 pcr_selects_cnt;
> > diff --git a/include/linux/tpm.h b/include/linux/tpm.h index
> > b0e9eb5ef022..dc0338a783f3 100644
> > --- a/include/linux/tpm.h
> > +++ b/include/linux/tpm.h
> > @@ -228,10 +228,11 @@ enum tpm2_timeouts {
> > TPM2_TIMEOUT_B = 4000,
> > TPM2_TIMEOUT_C = 200,
> > TPM2_TIMEOUT_D = 30,
> > +};
> > +
> > +enum tpm2_durations {
> > TPM2_DURATION_SHORT = 20,
> > - TPM2_DURATION_MEDIUM = 750,
> > TPM2_DURATION_LONG = 2000,
> > - TPM2_DURATION_LONG_LONG = 300000,
> > TPM2_DURATION_DEFAULT = 120000,
> > };
> >
> > --
> > 2.39.5
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: prevent slab cache merging for key_jar
From: Jarkko Sakkinen @ 2026-06-09 15:36 UTC (permalink / raw)
To: Mohammed EL Kadiri
Cc: Vlastimil Babka (SUSE), David Howells, Paul Moore, James Morris,
Serge E . Hallyn, Kees Cook, Vlastimil Babka, keyrings,
linux-security-module, linux-hardening, linux-kernel
In-Reply-To: <CAAMeuQTue5bkbhjYLjsRCnB9=KBifsPNQ=ZRVp+wCh2TiXE7Uw@mail.gmail.com>
On Tue, Jun 09, 2026 at 04:15:18PM +0100, Mohammed EL Kadiri wrote:
> Hi Jarkko, Vlastimil,
>
> I will send a v2 this evening with the commit message reworked. I will
> remove CVE references and frame it as hardening rather than an active
> vulnerability. I'll also drop the inaccurate skbuff_head_cache
> comparison that Vlastimil flagged.
>
> No need to strip it yourself, I'll have it out today.
Take your time :-) And thanks Vlastimil for the remark!
If I get the patch within this week, all is fine.
>
> Thanks,
> Mohammed
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: prevent slab cache merging for key_jar
From: Mohammed EL Kadiri @ 2026-06-09 15:15 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Vlastimil Babka (SUSE), David Howells, Paul Moore, James Morris,
Serge E . Hallyn, Kees Cook, Vlastimil Babka, keyrings,
linux-security-module, linux-hardening, linux-kernel
In-Reply-To: <aigoZeoqygyBYCbR@kernel.org>
Hi Jarkko, Vlastimil,
I will send a v2 this evening with the commit message reworked. I will
remove CVE references and frame it as hardening rather than an active
vulnerability. I'll also drop the inaccurate skbuff_head_cache
comparison that Vlastimil flagged.
No need to strip it yourself, I'll have it out today.
Thanks,
Mohammed
^ permalink raw reply
* Re: [PATCH] keys: prevent slab cache merging for key_jar
From: Jarkko Sakkinen @ 2026-06-09 14:52 UTC (permalink / raw)
To: Vlastimil Babka (SUSE)
Cc: Mohammed EL Kadiri, David Howells, Paul Moore, James Morris,
Serge E . Hallyn, Kees Cook, Vlastimil Babka, keyrings,
linux-security-module, linux-hardening, linux-kernel
In-Reply-To: <85a686a6-7fcc-4a1d-8574-0fc7c2f84bc8@kernel.org>
On Mon, Jun 08, 2026 at 09:20:39AM +0200, Vlastimil Babka (SUSE) wrote:
> On 6/8/26 06:22, Jarkko Sakkinen wrote:
> > On Thu, Jun 04, 2026 at 01:50:34PM +0100, Mohammed EL Kadiri wrote:
> >> The key_jar slab cache holds struct key objects containing cryptographic
> >> keys, authentication tokens, and keyring linkage. This cache currently
> >> lacks merge prevention, allowing the SLUB allocator to merge it with
> >> other similarly-sized caches.
> >>
> >> On a default Ubuntu 6.17.0-23-generic system, key_jar has 5 aliases,
> >> meaning 5 unrelated object types share its slab pages. struct key is
> >> 224 bytes, placed in 256-byte slabs alongside biovec-16, maple_node,
> >> ip6_dst_cache, task_delay_info, and kmalloc-256 users.
> >>
> >> Cross-cache heap exploitation is a well-documented attack class
> >> (CVE-2022-29582, CVE-2022-2588, CVE-2021-22555) where slab cache
> >> merging enables type confusion between unrelated kernel objects. A
> >> use-after-free in any subsystem sharing slab pages with key_jar could
> >> allow an attacker to reclaim a freed slot as a struct key, or corrupt
> >> an existing key through a dangling pointer to a different type.
> >>
> >> Add SLAB_NO_MERGE to ensure key_jar receives dedicated slab pages,
> >> eliminating cross-cache attacks targeting struct key. The memory
> >> overhead is minimal: with 32 objects per slab page and typical key
> >> usage bounded by system keyring size, the cost of dedicated pages is
> >> negligible. There is zero performance impact on the allocation hot
> >> path.
> >>
> >> This follows the precedent set by skbuff_head_cache (net/core/skbuff.c)
> >> which uses SLAB_NO_MERGE for similar isolation requirements.
>
> I just realized this part is somewhat misleading, because it's done there
> for performance reasons, so I wouldn't say "similar".
Mohammed, could you at least send v2, which does not emphasize on
CVEs? It's better the use no_merge for sake of hardnening but some
risk is not same as vulnerability.
I'll replace the patch in my tree with updated once I get it.
Or I can strip off the parts myself, whatever goes...
>
> >
> > ~/work/kernel.org/jarkko/linux-tpmdd master*
> > ❯ git log --oneline -1 d0bf7d5759c1d89fb013aa41cca5832e00b9632a
> > d0bf7d5759c1 mm/slab: introduce kmem_cache flag SLAB_NO_MERGE
> >
> > ~/work/kernel.org/jarkko/linux-tpmdd master*
> > ❯ git describe --contains d0bf7d5759c1d89fb013aa41cca5832e00b9632a
> > v6.5-rc1~137^2^3~1
> >
> > So we could probably forward to stable's starting from v6.6+ if that
> > is necessary / makes sense?
>
> It won't hurt, but I doubt it's "necessary" per stable rules. But stable
> maintainers ignore those themselves anyway, so whatever.
>
> > It's not a bug fix but kind of still I think would be a change that
> > stable kernels are better off with it than without it.
> >
> > What do you think?
>
> Won't object.
Yeah, I agree, and yeah I think commit message goes over the top, while
the change is for better.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v17 00/10] rust: add `Ownable` trait and `Owned` type
From: Miguel Ojeda @ 2026-06-09 14:11 UTC (permalink / raw)
To: Andreas Hindborg
Cc: 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, 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,
Viresh Kumar
In-Reply-To: <20260604-unique-ref-v17-0-7b4c3d2930b9@kernel.org>
On Thu, Jun 4, 2026 at 10:13 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
> rust: page: update formatting of `use` statements
> rust: aref: update formatting of use statements
Applied these to `rust-next` to get them out of the way already since
I have another similar one for `str` I am applying too -- thanks!
[ Picked from larger series and reworded. - Miguel ]
Cheers,
Miguel
^ 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