* RE: [PATCH v2] tpm: use a map for tpm2_calc_ordinal_duration()
From: Benoit HOUYERE @ 2026-06-08 14:46 UTC (permalink / raw)
To: Serge E. Hallyn, Jarkko Sakkinen
Cc: 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: <aMzSyCQks3NlMhPI@mail.hallyn.com>
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
-----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
^ permalink raw reply
* Re: [PATCH] keys: allow request-key path to be configured via Kconfig
From: Gary Guo @ 2026-06-08 10:30 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: <aiZMT5UYhVDlLVHq@kernel.org>
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.
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.
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.
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.
Best,
Gary
^ permalink raw reply
* Re: [PATCH] keys: prevent slab cache merging for key_jar
From: Vlastimil Babka (SUSE) @ 2026-06-08 7:20 UTC (permalink / raw)
To: Jarkko Sakkinen, Mohammed EL Kadiri
Cc: David Howells, Paul Moore, James Morris, Serge E . Hallyn,
Kees Cook, Vlastimil Babka, keyrings, linux-security-module,
linux-hardening, linux-kernel
In-Reply-To: <aiZDlSTqaQTcvLBl@kernel.org>
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".
>
> ~/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.
>> 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
>>
>
> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
>
> BR, Jarkko
^ permalink raw reply
* Re: [PATCH v6 4/4] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
From: Yeoreum Yun @ 2026-06-08 7:15 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: linux-security-module, linux-kernel, linux-integrity, paul, zohar,
roberto.sassu, noodles, sudeep.holla, jmorris, serge,
dmitry.kasatkin, eric.snowberg, jgg
In-Reply-To: <aiZJAR3-JACaDcwR@kernel.org>
On Mon, Jun 08, 2026 at 07:45:53AM +0300, Jarkko Sakkinen wrote:
> On Fri, Jun 05, 2026 at 03:43:25PM +0100, Yeoreum Yun wrote:
> > commit 746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in")
> > probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.
> >
> > However, IMA now provides the IMA_INIT_LATE_SYNC build option, which
> > initialises IMA at the late_initcall_sync level, so this change is no
> > longer required.
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > ---
> > drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
> > 1 file changed, 3 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
> > index 99f1c1e5644b..025c4d4b17ca 100644
> > --- a/drivers/char/tpm/tpm_crb_ffa.c
> > +++ b/drivers/char/tpm/tpm_crb_ffa.c
> > @@ -177,23 +177,13 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
> > */
> > int tpm_crb_ffa_init(void)
> > {
> > - int ret = 0;
> > -
> > - if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
> > - ret = ffa_register(&tpm_crb_ffa_driver);
> > - if (ret) {
> > - tpm_crb_ffa = ERR_PTR(-ENODEV);
> > - return ret;
> > - }
> > - }
> > -
> > if (!tpm_crb_ffa)
> > - ret = -ENOENT;
> > + return -ENOENT;
> >
> > if (IS_ERR_VALUE(tpm_crb_ffa))
> > - ret = -ENODEV;
> > + return -ENODEV;
> >
> > - return ret;
> > + return 0;
> > }
> > EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
> >
> > @@ -405,9 +395,7 @@ static struct ffa_driver tpm_crb_ffa_driver = {
> > .id_table = tpm_crb_ffa_device_id,
> > };
> >
> > -#ifdef MODULE
> > module_ffa_driver(tpm_crb_ffa_driver);
> > -#endif
> >
> > MODULE_AUTHOR("Arm");
> > MODULE_DESCRIPTION("TPM CRB FFA driver");
> > --
> > LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
> >
>
> Is this different I applied?
>
> If yes, I'll swap (if mandatory).
No difference. Thanks! ;)
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* [PATCH] apparmor: check label build before no_new_privs test
From: Ruoyu Wang @ 2026-06-08 6:36 UTC (permalink / raw)
To: John Johansen
Cc: Paul Moore, James Morris, Serge E . Hallyn, apparmor,
linux-security-module, linux-kernel, Ruoyu Wang
aa_change_profile() builds a replacement label with
fn_label_build_in_scope() before the no_new_privs subset check. The build
helper can fail and return NULL or an ERR_PTR, but the result was passed
to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL()
check.
Reuse the existing target-label build failure handling immediately after
the build. This preserves the current audit handling while preventing the
subset helper from dereferencing an invalid label.
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
security/apparmor/domain.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/security/apparmor/domain.c b/security/apparmor/domain.c
index f02bf770f6385..6748ac74b060b 100644
--- a/security/apparmor/domain.c
+++ b/security/apparmor/domain.c
@@ -1527,6 +1527,8 @@ int aa_change_profile(const char *fqname, int flags)
new = fn_label_build_in_scope(label, profile, GFP_KERNEL,
aa_get_label(target),
aa_get_label(&profile->label));
+ if (IS_ERR_OR_NULL(new))
+ goto build_fail;
/*
* no new privs prevents domain transitions that would
* reduce restrictions.
@@ -1545,16 +1547,8 @@ int aa_change_profile(const char *fqname, int flags)
/* only transition profiles in the current ns */
if (stack)
new = aa_label_merge(label, target, GFP_KERNEL);
- if (IS_ERR_OR_NULL(new)) {
- info = "failed to build target label";
- if (!new)
- error = -ENOMEM;
- else
- error = PTR_ERR(new);
- new = NULL;
- perms.allow = 0;
- goto audit;
- }
+ if (IS_ERR_OR_NULL(new))
+ goto build_fail;
error = aa_replace_current_label(new);
} else {
if (new) {
@@ -1566,6 +1560,17 @@ int aa_change_profile(const char *fqname, int flags)
aa_set_current_onexec(target, stack);
}
+ goto audit;
+
+build_fail:
+ info = "failed to build target label";
+ if (!new)
+ error = -ENOMEM;
+ else
+ error = PTR_ERR(new);
+ new = NULL;
+ perms.allow = 0;
+
audit:
error = fn_for_each_in_scope(label, profile,
aa_audit_file(subj_cred,
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] keys: Pin request_key_auth payload in instantiate paths
From: Jarkko Sakkinen @ 2026-06-08 5:42 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: <aiZTIzGg_peDVo1M@kernel.org>
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
^ permalink raw reply
* security_inode_follow_link: KASAN UAF localization report
From: David Maximiliano Hermitte @ 2026-06-08 5:31 UTC (permalink / raw)
To: paul
Cc: jmorris, serge, viro, brauner, jack, linux-security-module,
linux-fsdevel, linux-kernel, David Maximiliano Hermitte
Hello,
I reproduced this issue locally in a QEMU/TCG VM and I can confirm a valid BEFORE signal.
Summary of the local evidence:
- Reproducer started: yes
- KASAN seen: yes
- use-after-free seen: yes
- target function seen: security_inode_follow_link
- target file seen: security/security.c
- Call Trace seen: yes
- RIP seen: yes
- BEFORE validation: true
At this point I am treating this as a localization report, not as a final patch submission.
The trace points to the security_inode_follow_link / link-follow path. I would prefer not to guess the final fix, since I do not yet have a validated AFTER patch for this issue.
I can provide the reproducer evidence and retest any proposed patch if helpful.
Thanks,
David
^ permalink raw reply
* Re: [PATCH] keys: Pin request_key_auth payload in instantiate paths
From: Jarkko Sakkinen @ 2026-06-08 5:29 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: <aiYynOxFk3LuK4LA@kernel.org>
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?
`
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: allow request-key path to be configured via Kconfig
From: Jarkko Sakkinen @ 2026-06-08 4:59 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: <aiZJ94eugtNHcILD@kernel.org>
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.
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.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: allow request-key path to be configured via Kconfig
From: Jarkko Sakkinen @ 2026-06-08 4: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: <20260607134928.2832202-1-gary@kernel.org>
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.
>
> Follow the way modprobe handles this by making this a Kconfig option which
> defaults to the current /sbin/request-key.
>
> Also changed "char const" to "const char" as checkpatch complains
> otherwise.
>
> Link: https://github.com/NixOS/nixpkgs/blob/6b316287bae2ee04c9b93c8c858d930fd07d7338/pkgs/os-specific/linux/kernel/request-key-helper.patch
> Signed-off-by: Gary Guo <gary@garyguo.net>
> ---
> I did not update mentions of /sbin/request-key in documentation and
> elsewhere, as "/sbin/request-key" is concise while "request-key UMH" is
> more mouthful and less clear.
>
> Number of distros that doesn't have /sbin is limited so I think it wouldn't
> create much confusion. Similarly, there are a lot of places where
> /sbin/modprobe is mentioned despite it is technically configurable.
> ---
> security/keys/Kconfig | 9 +++++++++
> security/keys/request_key.c | 2 +-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/security/keys/Kconfig b/security/keys/Kconfig
> index f4510d8cb485..ee3c3d85fc03 100644
> --- a/security/keys/Kconfig
> +++ b/security/keys/Kconfig
> @@ -40,6 +40,15 @@ config KEYS_REQUEST_CACHE
> key. Pathwalk will call multiple methods for each dentry traversed
> (permission, d_revalidate, lookup, getxattr, getacl, ...).
>
> +config REQUEST_KEY_PATH
> + string "Path to the request-key binary"
> + default "/sbin/request-key"
> + help
> + Path of the request-key usermode helper binary.
> +
> + This program is invoked by the kernel when the kernel is asked for
> + a key that it doesn't have immediately available.
> +
> config PERSISTENT_KEYRINGS
> bool "Enable register of persistent per-UID keyrings"
> help
> diff --git a/security/keys/request_key.c b/security/keys/request_key.c
> index a7673ad86d18..ac8f9d1a87ad 100644
> --- a/security/keys/request_key.c
> +++ b/security/keys/request_key.c
> @@ -117,7 +117,7 @@ static int call_usermodehelper_keys(const char *path, char **argv, char **envp,
> */
> static int call_sbin_request_key(struct key *authkey, void *aux)
> {
> - static char const request_key[] = "/sbin/request-key";
> + static const char request_key[] = CONFIG_REQUEST_KEY_PATH;
> struct request_key_auth *rka = get_request_key_auth(authkey);
> const struct cred *cred = current_cred();
> key_serial_t prkey, sskey;
>
> base-commit: 6e845bcb78c95af935094040bd4edc3c2b6dd784
> --
> 2.54.0
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH next] keys: Replace strcpy(derived_buf, "AUTH_KEY") with strscpy(..., HASH_SIZE)
From: Jarkko Sakkinen @ 2026-06-08 4:46 UTC (permalink / raw)
To: david.laight.linux
Cc: Kees Cook, linux-hardening, Arnd Bergmann, keyrings,
linux-integrity, linux-kernel, linux-security-module,
David Howells, James Morris, Mimi Zohar, Paul Moore,
Serge E. Hallyn
In-Reply-To: <20260606202633.5018-9-david.laight.linux@gmail.com>
On Sat, Jun 06, 2026 at 09:26:03PM +0100, david.laight.linux@gmail.com wrote:
> From: David Laight <david.laight.linux@gmail.com>
>
> derived_buf is guaranteed to be HASH_SIZE - and it is more than enough.
> The strscpy() degenerates into an memcpy() (as did the strcpy()).
> Do the same for the associated "ENC_KEY" copy.
>
> Removes a possibly unbounded strcpy().
>
> Signed-off-by: David Laight <david.laight.linux@gmail.com>
> ---
> This is one of a group of patches that remove potentially unbounded
> strcpy() calls.
>
> They are mostly replaced by strscpy() or, when strlen() has just been
> called, with memcpy() (usually including the '\0').
>
> Calls with copy string literals into arrays are left unchanged.
> They are safe and easily detected as such.
>
> The changes were made by getting the compiler to detect the calls and
> then fixing the code by hand.
>
> Note that all the changes are only compile tested.
>
> Some Makefiles were changed to allow files to contain strcpy().
> As well as 'difficult to fix' files, this included 'show' functions
> as they really need to use sysfs_emit() or seq_printf().
>
> All the patches are being sent individually to avoid very long cc lists.
> Apologies for the terse commit messages and likely unexpected tags.
> (There are about 100 patches in total.)
>
> security/keys/encrypted-keys/encrypted.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c
> index 56b531587a1e..59cb77b237b3 100644
> --- a/security/keys/encrypted-keys/encrypted.c
> +++ b/security/keys/encrypted-keys/encrypted.c
> @@ -343,9 +343,9 @@ static int get_derived_key(u8 *derived_key, enum derived_key_type key_type,
> return -ENOMEM;
>
> if (key_type)
> - strcpy(derived_buf, "AUTH_KEY");
> + strscpy(derived_buf, "AUTH_KEY", HASH_SIZE);
> else
> - strcpy(derived_buf, "ENC_KEY");
> + strscpy(derived_buf, "ENC_KEY", HASH_SIZE);
>
> memcpy(derived_buf + strlen(derived_buf) + 1, master_key,
> master_keylen);
> --
> 2.39.5
>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v6 4/4] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
From: Jarkko Sakkinen @ 2026-06-08 4:45 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-security-module, linux-kernel, linux-integrity, paul, zohar,
roberto.sassu, noodles, sudeep.holla, jmorris, serge,
dmitry.kasatkin, eric.snowberg, jgg
In-Reply-To: <20260605144325.434436-5-yeoreum.yun@arm.com>
On Fri, Jun 05, 2026 at 03:43:25PM +0100, Yeoreum Yun wrote:
> commit 746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in")
> probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.
>
> However, IMA now provides the IMA_INIT_LATE_SYNC build option, which
> initialises IMA at the late_initcall_sync level, so this change is no
> longer required.
>
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> ---
> drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
> 1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
> index 99f1c1e5644b..025c4d4b17ca 100644
> --- a/drivers/char/tpm/tpm_crb_ffa.c
> +++ b/drivers/char/tpm/tpm_crb_ffa.c
> @@ -177,23 +177,13 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
> */
> int tpm_crb_ffa_init(void)
> {
> - int ret = 0;
> -
> - if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
> - ret = ffa_register(&tpm_crb_ffa_driver);
> - if (ret) {
> - tpm_crb_ffa = ERR_PTR(-ENODEV);
> - return ret;
> - }
> - }
> -
> if (!tpm_crb_ffa)
> - ret = -ENOENT;
> + return -ENOENT;
>
> if (IS_ERR_VALUE(tpm_crb_ffa))
> - ret = -ENODEV;
> + return -ENODEV;
>
> - return ret;
> + return 0;
> }
> EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
>
> @@ -405,9 +395,7 @@ static struct ffa_driver tpm_crb_ffa_driver = {
> .id_table = tpm_crb_ffa_device_id,
> };
>
> -#ifdef MODULE
> module_ffa_driver(tpm_crb_ffa_driver);
> -#endif
>
> MODULE_AUTHOR("Arm");
> MODULE_DESCRIPTION("TPM CRB FFA driver");
> --
> LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
>
Is this different I applied?
If yes, I'll swap (if mandatory).
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: prevent slab cache merging for key_jar
From: Jarkko Sakkinen @ 2026-06-08 4:27 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: <19fb9d38-fe02-4653-bbad-58806e55ca84@kernel.org>
On Fri, Jun 05, 2026 at 02:16:00PM +0200, Vlastimil Babka (SUSE) wrote:
> On 6/4/26 14:50, 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.
> >
> > Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
>
> Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Thank you.
has been applied
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: prevent slab cache merging for key_jar
From: Jarkko Sakkinen @ 2026-06-08 4:22 UTC (permalink / raw)
To: Mohammed EL Kadiri
Cc: David Howells, Paul Moore, James Morris, Serge E . Hallyn,
Kees Cook, Vlastimil Babka, keyrings, linux-security-module,
linux-hardening, linux-kernel
In-Reply-To: <20260604125034.13757-1-med08elkadiri@gmail.com>
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.
>
~/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'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?
> 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
>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v5 4/4] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
From: Jarkko Sakkinen @ 2026-06-08 4:01 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-security-module, linux-kernel, linux-integrity, paul, zohar,
roberto.sassu, noodles, sudeep.holla, jmorris, serge,
dmitry.kasatkin, eric.snowberg, jgg
In-Reply-To: <ah7TAk3iItltddzT@e129823.arm.com>
On Tue, Jun 02, 2026 at 01:56:34PM +0100, Yeoreum Yun wrote:
> > On Mon, Jun 01, 2026 at 03:27:49PM +0100, Yeoreum Yun wrote:
> > > commit 746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's build_in")
> > > probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.
> > >
> > > However, IMA now provides the IMA_INIT_LATE_SYNC build option, which
> > > initialises IMA at the late_initcall_sync level, so this change is no
> > > longer required.
> > >
> > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> >
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
>
> Might be rb tag?. Thanks!
>
> --
> Sincerely,
> Yeoreum Yun
SOB is enough information as it is a small change. I pushed it to
for-next-tpm.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v4 3/3] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
From: Jarkko Sakkinen @ 2026-06-08 3:54 UTC (permalink / raw)
To: Sudeep Holla
Cc: Yeoreum Yun, linux-security-module, linux-kernel, linux-integrity,
paul, zohar, roberto.sassu, noodles, jmorris, serge,
dmitry.kasatkin, eric.snowberg, jgg
In-Reply-To: <20260602-vague-proficient-gibbon-b005c0@sudeepholla>
On Tue, Jun 02, 2026 at 10:57:25AM +0100, Sudeep Holla wrote:
> On Tue, Jun 02, 2026 at 04:50:42AM +0300, Jarkko Sakkinen wrote:
> > On Mon, Jun 01, 2026 at 09:54:08AM +0100, Sudeep Holla wrote:
> > > On Mon, Jun 01, 2026 at 08:17:13AM +0100, Yeoreum Yun wrote:
> > > > Hi Jarkko,
> > > >
> > > > Sorry for late answer.
> > > >
> > > > > On Mon, May 25, 2026 at 08:54:04AM +0100, Yeoreum Yun wrote:
> > > > > > commit 746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's build_in")
> > > > > > probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.
> > > > > >
> > > > > > However, IMA now provides the IMA_INIT_LATE_SYNC build option, which
> > > > > > initialises IMA at the late_initcall_sync level, so this change is no
> > > > > > longer required.
> > > > > >
> > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > > > > > ---
> > > > > > drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
> > > > > > 1 file changed, 3 insertions(+), 15 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
> > > > > > index 99f1c1e5644b..025c4d4b17ca 100644
> > > > > > --- a/drivers/char/tpm/tpm_crb_ffa.c
> > > > > > +++ b/drivers/char/tpm/tpm_crb_ffa.c
> > > > > > @@ -177,23 +177,13 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
> > > > > > */
> > > > > > int tpm_crb_ffa_init(void)
> > > > > > {
> > > > > > - int ret = 0;
> > > > > > -
> > > > > > - if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
> > > > > > - ret = ffa_register(&tpm_crb_ffa_driver);
> > > > > > - if (ret) {
> > > > > > - tpm_crb_ffa = ERR_PTR(-ENODEV);
> > > > > > - return ret;
> > > > > > - }
> > > > > > - }
> > > > > > -
> > > > > > if (!tpm_crb_ffa)
> > > > > > - ret = -ENOENT;
> > > > > > + return -ENOENT;
> > > > > >
> > > > > > if (IS_ERR_VALUE(tpm_crb_ffa))
> > > > > > - ret = -ENODEV;
> > > > > > + return -ENODEV;
> > > > > >
> > > > > > - return ret;
> > > > > > + return 0;
> > > > > > }
> > > > > > EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
> > > > > >
> > > > > > @@ -405,9 +395,7 @@ static struct ffa_driver tpm_crb_ffa_driver = {
> > > > > > .id_table = tpm_crb_ffa_device_id,
> > > > > > };
> > > > > >
> > > > > > -#ifdef MODULE
> > > > > > module_ffa_driver(tpm_crb_ffa_driver);
> > > > > > -#endif
> > > > > >
> > > > > > MODULE_AUTHOR("Arm");
> > > > > > MODULE_DESCRIPTION("TPM CRB FFA driver");
> > > > > > --
> > > > > > LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
> > > > > >
> > > > >
> > > > > How we would sync up this patch? Through which tree etc.
> > > >
> > > > IMHO, the IMA relevant thing would be into IMA tree,
> > > > However I think this patch would be much easier to sync into Sudeep's
> > > > FF-A tree where ff-a initilisation is reverted to device_initcall
> > > > unless you're uncomfortable.
> > > >
> > > > For this, It might be better to split this patch from this series
> > > > since by above and defer probe of ff-a would make a register failure
> > > > of registering tpm_crb_ffa driver which is built-in.
> > > >
> > > > @Sudeep what do you think?
> > > >
> > >
> > > IIRC, there is/was no dependency between these and FF-A patches that are
> > > queued in terms of build. I agree there may be dependency to get all the
> > > functionality but we can resort to linux-next for that. FF-A is not enabled
> > > in the defconfig, so anyone working on FF-A + TPM must enable then and can
> > > rely on -next IMHO.
> > >
> > > That said, I have already sent PR for FF-A to SoC team and it is already
> > > queued for v7.2. I don't have any other plans unless they are fixes.
> >
> > Works for me.
> >
>
> Sorry if I was not clear. I haven't included any TPM patches in this series
> as part of my FF-A pull request queued for v7.2. So I was asking to route this
> via your tree.
It's now in 'for-next-tpm'. Just pushed.
>
> --
> Regards,
> Sudeep
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] KEYS: Use acquire when reading state in keyring search
From: Jarkko Sakkinen @ 2026-06-08 3:48 UTC (permalink / raw)
To: Gui-Dong Han
Cc: dhowells, keyrings, ebiggers, linux-security-module, linux-kernel,
baijiaju1990
In-Reply-To: <CALbr=LYaca4+=hTsZJORQfrtzyUAGo8c+4ZEgkzgkFWQDWNJBA@mail.gmail.com>
On Tue, Jun 02, 2026 at 05:42:26PM +0800, Gui-Dong Han wrote:
> On Sat, May 30, 2026 at 9:02 AM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Fri, May 29, 2026 at 11:34:06AM +0800, Gui-Dong Han wrote:
> > > The negative-key race fix added release/acquire ordering for key use.
> > >
> > > Publish payload before state; read state before payload.
> > >
> > > keyring_search_iterator() still uses READ_ONCE() before match callbacks.
> > > An asymmetric match callback calls asymmetric_key_ids(), which reads
> > > key->payload.data[asym_key_ids].
> > >
> > > Use key_read_state() there to complete that ordering.
> >
> > OK, so... I'm having a bit trouble understanding the exact concurrency
> > scenario you're trying to describe despite I think I get the fix itself
> > i.e. it is not pairing with mark_key_instantiated?
>
> Yes, it is intended to pair with mark_key_instantiated().
OK, right. I'll apply this.
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: Pin request_key_auth payload in instantiate paths
From: Jarkko Sakkinen @ 2026-06-08 3:10 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: <aiYxqTyfHwrDOTCs@kernel.org>
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.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: Pin request_key_auth payload in instantiate paths
From: Jarkko Sakkinen @ 2026-06-08 3:06 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: <20260526024838.3368409-1-eeesssooo020@gmail.com>
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.
That does necessarily mean same as NAK but we need much more clarity
here.
You should start off not mentioning 'reproducer'. If it does not
exist in public, it does not exist. It's not good for anything
here.
Then, put a concurrency scenario with A/B sidecars.
Some comments below.
>
> diff --git a/include/keys/request_key_auth-type.h b/include/keys/request_key_auth-type.h
> index 36b89a933310..01e42ee5f409 100644
> --- a/include/keys/request_key_auth-type.h
> +++ b/include/keys/request_key_auth-type.h
> @@ -9,12 +9,14 @@
> #define _KEYS_REQUEST_KEY_AUTH_TYPE_H
>
> #include <linux/key.h>
> +#include <linux/refcount.h>
BTW, did you test compilation w/o adding this? Just potential
low-hanging fruit diff to remove.
>
> /*
> * Authorisation record for request_key().
> */
> struct request_key_auth {
> struct rcu_head rcu;
> + refcount_t usage;
> struct key *target_key;
> struct key *dest_keyring;
> const struct cred *cred;
> diff --git a/security/keys/internal.h b/security/keys/internal.h
> index 2cffa6dc8255..b7b622bc36a1 100644
> --- a/security/keys/internal.h
> +++ b/security/keys/internal.h
> @@ -208,6 +208,8 @@ extern struct key *request_key_auth_new(struct key *target,
> const void *callout_info,
> size_t callout_len,
> struct key *dest_keyring);
> +struct request_key_auth *request_key_auth_get(struct key *authkey);
> +void request_key_auth_put(struct request_key_auth *rka);
>
> extern struct key *key_get_instantiation_authkey(key_serial_t target_id);
>
> diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
> index ef855d69c97a..d14ace88e529 100644
> --- a/security/keys/keyctl.c
> +++ b/security/keys/keyctl.c
> @@ -1197,9 +1197,13 @@ static long keyctl_instantiate_key_common(key_serial_t id,
> if (!instkey)
> goto error;
>
> - rka = instkey->payload.data[0];
> - if (rka->target_key->serial != id)
> + rka = request_key_auth_get(instkey);
> + if (!rka) {
> + ret = -EKEYREVOKED;
> goto error;
> + }
> + if (rka->target_key->serial != id)
> + goto error_put_rka;
This label should not be introduced and generally please do everything
not add extra fat to diff. This is already fat for a claiming to be
bug fix.
>
> /* pull the payload in if one was supplied */
> payload = NULL;
> @@ -1208,7 +1212,7 @@ static long keyctl_instantiate_key_common(key_serial_t id,
> ret = -ENOMEM;
> payload = kvmalloc(plen, GFP_KERNEL);
> if (!payload)
> - goto error;
> + goto error_put_rka;
>
> ret = -EFAULT;
> if (!copy_from_iter_full(payload, plen, from))
> @@ -1234,6 +1238,8 @@ static long keyctl_instantiate_key_common(key_serial_t id,
>
> error2:
> kvfree_sensitive(payload, plen);
> +error_put_rka:
> + request_key_auth_put(rka);
> error:
> return ret;
> }
> @@ -1358,15 +1364,19 @@ long keyctl_reject_key(key_serial_t id, unsigned timeout, unsigned error,
> if (!instkey)
> goto error;
>
> - rka = instkey->payload.data[0];
> - if (rka->target_key->serial != id)
> + rka = request_key_auth_get(instkey);
> + if (!rka) {
> + ret = -EKEYREVOKED;
> goto error;
> + }
> + if (rka->target_key->serial != id)
> + goto error_put_rka;
>
> /* find the destination keyring if present (which must also be
> * writable) */
> ret = get_instantiation_keyring(ringid, rka, &dest_keyring);
> if (ret < 0)
> - goto error;
> + goto error_put_rka;
>
> /* instantiate the key and link it into a keyring */
> ret = key_reject_and_link(rka->target_key, timeout, error,
> @@ -1379,6 +1389,8 @@ long keyctl_reject_key(key_serial_t id, unsigned timeout, unsigned error,
> if (ret == 0)
> keyctl_change_reqkey_auth(NULL);
>
> +error_put_rka:
> + request_key_auth_put(rka);
> error:
> return ret;
> }
> diff --git a/security/keys/request_key_auth.c b/security/keys/request_key_auth.c
> index a7d7538c1f70..282e09d8fa46 100644
> --- a/security/keys/request_key_auth.c
> +++ b/security/keys/request_key_auth.c
> @@ -23,6 +23,7 @@ static void request_key_auth_describe(const struct key *, struct seq_file *);
> static void request_key_auth_revoke(struct key *);
> static void request_key_auth_destroy(struct key *);
> static long request_key_auth_read(const struct key *, char *, size_t);
> +static void request_key_auth_rcu_disposal(struct rcu_head *);
>
> /*
> * The request-key authorisation key type definition.
> @@ -115,6 +116,31 @@ static void free_request_key_auth(struct request_key_auth *rka)
> kfree(rka);
> }
>
> +/*
> + * Take a reference to the request-key authorisation payload so callers can
> + * drop authkey->sem before doing operations that may sleep.
> + */
> +struct request_key_auth *request_key_auth_get(struct key *authkey)
> +{
> + struct request_key_auth *rka;
> +
> + down_read(&authkey->sem);
> + rka = dereference_key_locked(authkey);
> + if (rka && !test_bit(KEY_FLAG_REVOKED, &authkey->flags))
> + refcount_inc(&rka->usage);
> + else
> + rka = NULL;
> + up_read(&authkey->sem);
> +
> + return rka;
> +}
Instead add fast-path return here. Then request_key_auth can be called
called in keyctl_instantiate_key_common and all that extra cruft in
this patch won't be needed.
> +
> +void request_key_auth_put(struct request_key_auth *rka)
> +{
> + if (rka && refcount_dec_and_test(&rka->usage))
> + call_rcu(&rka->rcu, request_key_auth_rcu_disposal);
> +}
> +
> /*
> * Dispose of the request_key_auth record under RCU conditions
> */
> @@ -136,8 +162,10 @@ static void request_key_auth_revoke(struct key *key)
> struct request_key_auth *rka = dereference_key_locked(key);
>
> kenter("{%d}", key->serial);
> + if (!rka)
> + return;
> rcu_assign_keypointer(key, NULL);
> - call_rcu(&rka->rcu, request_key_auth_rcu_disposal);
> + request_key_auth_put(rka);
> }
>
> /*
> @@ -150,7 +178,7 @@ static void request_key_auth_destroy(struct key *key)
> kenter("{%d}", key->serial);
> if (rka) {
> rcu_assign_keypointer(key, NULL);
> - call_rcu(&rka->rcu, request_key_auth_rcu_disposal);
> + request_key_auth_put(rka);
> }
> }
>
> @@ -174,6 +202,7 @@ struct key *request_key_auth_new(struct key *target, const char *op,
> rka = kzalloc_obj(*rka);
> if (!rka)
> goto error;
> + refcount_set(&rka->usage, 1);
> rka->callout_info = kmemdup(callout_info, callout_len, GFP_KERNEL);
> if (!rka->callout_info)
> goto error_free_rka;
> --
> 2.47.3
Looking forward for v2. These requests are for being able to make
reasonable review for the actual logical change. Now there's
that and "decorations".
Thanks!
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v10 6/9] selftests/landlock: add tests for quiet flag with fs rules
From: Tingmao Wang @ 2026-06-08 1:31 UTC (permalink / raw)
To: Justin Suess
Cc: Mickaël Salaün, Günther Noack, Jan Kara,
Abhinav Saxena, linux-security-module
In-Reply-To: <aiMciEe6zVnisbQJ@zenbox>
On 6/5/26 20:04, Justin Suess wrote:
> On Mon, Jun 01, 2026 at 01:00:40AM +0100, Tingmao Wang wrote:
>> [...]
>> + if (target->expect_ioctl_allowed)
>> + ASSERT_NE(EACCES, ret);
>> + else
>> + ASSERT_EQ(EACCES, ret);
> This doesn't compile.
>
> make: Entering directory '/home/justin/Code/linux-next/tools/testing/selftests'
> CC fs_test
> fs_test.c: In function ‘audit_quiet_layout1_test_body’:
> fs_test.c:8456:33: error: expected ‘}’ before ‘else’
> 8456 | else
> | ^~~~
> fs_test.c: At top level:
> fs_test.c:8474:1: error: expected identifier or ‘(’ before ‘}’ token
> 8474 | }
> | ^
> make[1]: *** [../lib.mk:225: /home/justin/Code/linux-next/.out-landlock_archlinux-base-devel/kselftest/landlock/fs_test] Error 1
>
> The ASSERT_* macros doen't properly handle braceless if statements...
>
> (easy to miss if you forget to recompile after clang format and/or
> checkpatch --fix...)
>
> Adding braces to this as with previous versions of this series should
> fix it.
>
> Justin
Thanks for spotting! I forgot and was wondering why I didn't fix this
checkpatch lint earlier, turns out there is a reason why :)
Will fix in next version, after Mickaël's review.
^ permalink raw reply
* Re: [PATCH] keys: allow request-key path to be configured via Kconfig
From: Serge E. Hallyn @ 2026-06-07 19:55 UTC (permalink / raw)
To: Gary Guo
Cc: David Howells, Jarkko Sakkinen, Paul Moore, James Morris,
Serge E. Hallyn, keyrings, linux-security-module, linux-kernel
In-Reply-To: <20260607134928.2832202-1-gary@kernel.org>
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.
>
> Follow the way modprobe handles this by making this a Kconfig option which
> defaults to the current /sbin/request-key.
>
> Also changed "char const" to "const char" as checkpatch complains
> otherwise.
>
> Link: https://github.com/NixOS/nixpkgs/blob/6b316287bae2ee04c9b93c8c858d930fd07d7338/pkgs/os-specific/linux/kernel/request-key-helper.patch
> Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Serge Hallyn <serge@hallyn.com>
> ---
> I did not update mentions of /sbin/request-key in documentation and
> elsewhere, as "/sbin/request-key" is concise while "request-key UMH" is
> more mouthful and less clear.
>
> Number of distros that doesn't have /sbin is limited so I think it wouldn't
> create much confusion. Similarly, there are a lot of places where
> /sbin/modprobe is mentioned despite it is technically configurable.
> ---
> security/keys/Kconfig | 9 +++++++++
> security/keys/request_key.c | 2 +-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/security/keys/Kconfig b/security/keys/Kconfig
> index f4510d8cb485..ee3c3d85fc03 100644
> --- a/security/keys/Kconfig
> +++ b/security/keys/Kconfig
> @@ -40,6 +40,15 @@ config KEYS_REQUEST_CACHE
> key. Pathwalk will call multiple methods for each dentry traversed
> (permission, d_revalidate, lookup, getxattr, getacl, ...).
>
> +config REQUEST_KEY_PATH
> + string "Path to the request-key binary"
> + default "/sbin/request-key"
> + help
> + Path of the request-key usermode helper binary.
> +
> + This program is invoked by the kernel when the kernel is asked for
> + a key that it doesn't have immediately available.
> +
> config PERSISTENT_KEYRINGS
> bool "Enable register of persistent per-UID keyrings"
> help
> diff --git a/security/keys/request_key.c b/security/keys/request_key.c
> index a7673ad86d18..ac8f9d1a87ad 100644
> --- a/security/keys/request_key.c
> +++ b/security/keys/request_key.c
> @@ -117,7 +117,7 @@ static int call_usermodehelper_keys(const char *path, char **argv, char **envp,
> */
> static int call_sbin_request_key(struct key *authkey, void *aux)
> {
> - static char const request_key[] = "/sbin/request-key";
> + static const char request_key[] = CONFIG_REQUEST_KEY_PATH;
> struct request_key_auth *rka = get_request_key_auth(authkey);
> const struct cred *cred = current_cred();
> key_serial_t prkey, sskey;
>
> base-commit: 6e845bcb78c95af935094040bd4edc3c2b6dd784
> --
> 2.54.0
^ permalink raw reply
* [PATCH] keys: allow request-key path to be configured via Kconfig
From: Gary Guo @ 2026-06-07 13:49 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, Paul Moore, James Morris,
Serge E. Hallyn
Cc: Gary Guo, keyrings, linux-security-module, linux-kernel
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.
Follow the way modprobe handles this by making this a Kconfig option which
defaults to the current /sbin/request-key.
Also changed "char const" to "const char" as checkpatch complains
otherwise.
Link: https://github.com/NixOS/nixpkgs/blob/6b316287bae2ee04c9b93c8c858d930fd07d7338/pkgs/os-specific/linux/kernel/request-key-helper.patch
Signed-off-by: Gary Guo <gary@garyguo.net>
---
I did not update mentions of /sbin/request-key in documentation and
elsewhere, as "/sbin/request-key" is concise while "request-key UMH" is
more mouthful and less clear.
Number of distros that doesn't have /sbin is limited so I think it wouldn't
create much confusion. Similarly, there are a lot of places where
/sbin/modprobe is mentioned despite it is technically configurable.
---
security/keys/Kconfig | 9 +++++++++
security/keys/request_key.c | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index f4510d8cb485..ee3c3d85fc03 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -40,6 +40,15 @@ config KEYS_REQUEST_CACHE
key. Pathwalk will call multiple methods for each dentry traversed
(permission, d_revalidate, lookup, getxattr, getacl, ...).
+config REQUEST_KEY_PATH
+ string "Path to the request-key binary"
+ default "/sbin/request-key"
+ help
+ Path of the request-key usermode helper binary.
+
+ This program is invoked by the kernel when the kernel is asked for
+ a key that it doesn't have immediately available.
+
config PERSISTENT_KEYRINGS
bool "Enable register of persistent per-UID keyrings"
help
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index a7673ad86d18..ac8f9d1a87ad 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -117,7 +117,7 @@ static int call_usermodehelper_keys(const char *path, char **argv, char **envp,
*/
static int call_sbin_request_key(struct key *authkey, void *aux)
{
- static char const request_key[] = "/sbin/request-key";
+ static const char request_key[] = CONFIG_REQUEST_KEY_PATH;
struct request_key_auth *rka = get_request_key_auth(authkey);
const struct cred *cred = current_cred();
key_serial_t prkey, sskey;
base-commit: 6e845bcb78c95af935094040bd4edc3c2b6dd784
--
2.54.0
^ permalink raw reply related
* [PATCH next] keys: Replace strcpy(derived_buf, "AUTH_KEY") with strscpy(..., HASH_SIZE)
From: david.laight.linux @ 2026-06-06 20:26 UTC (permalink / raw)
To: Kees Cook, linux-hardening, Arnd Bergmann, keyrings,
linux-integrity, linux-kernel, linux-security-module
Cc: David Howells, James Morris, Jarkko Sakkinen, Mimi Zohar,
Paul Moore, Serge E. Hallyn, David Laight
From: David Laight <david.laight.linux@gmail.com>
derived_buf is guaranteed to be HASH_SIZE - and it is more than enough.
The strscpy() degenerates into an memcpy() (as did the strcpy()).
Do the same for the associated "ENC_KEY" copy.
Removes a possibly unbounded strcpy().
Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.
They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').
Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.
The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.
Note that all the changes are only compile tested.
Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().
All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)
security/keys/encrypted-keys/encrypted.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c
index 56b531587a1e..59cb77b237b3 100644
--- a/security/keys/encrypted-keys/encrypted.c
+++ b/security/keys/encrypted-keys/encrypted.c
@@ -343,9 +343,9 @@ static int get_derived_key(u8 *derived_key, enum derived_key_type key_type,
return -ENOMEM;
if (key_type)
- strcpy(derived_buf, "AUTH_KEY");
+ strscpy(derived_buf, "AUTH_KEY", HASH_SIZE);
else
- strcpy(derived_buf, "ENC_KEY");
+ strscpy(derived_buf, "ENC_KEY", HASH_SIZE);
memcpy(derived_buf + strlen(derived_buf) + 1, master_key,
master_keylen);
--
2.39.5
^ permalink raw reply related
* Re: [PATCH] apparmor: Constify 'nulldfa_src' and 'stacksplitdfa_src' arrays
From: Len Bao @ 2026-06-06 17:18 UTC (permalink / raw)
To: John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Kees Cook
Cc: Len Bao, apparmor, linux-security-module, linux-hardening,
linux-kernel
In-Reply-To: <20260524113412.48050-1-len.bao@gmx.us>
Hi,
On Sun, May 24, 2026 at 11:34:11AM +0000, Len Bao wrote:
> The 'nulldfa_src' and 'stacksplitdfa_src' arrays are initialized in
> their declarations and never changed. So, constify them to reduce the
> attack surface.
>
> To make this possible, it is also necessary to change the 'unpack_table'
> and 'aa_dfa_unpack' function prototypes to pass, as a first argument, a
> pointer to a 'const' blob. At the same type, define the blob exact
> pointer type (pointer to const char) since all the calls to the
> mentioned functions use this same type.
>
> Before the patch (size lsm.o):
>
> text data bss dec hex
> 128768 28028 704 157500 2673c
>
> After the patch (size lsm.o):
>
> text data bss dec hex
> 131264 25532 704 157500 2673c
>
> Signed-off-by: Len Bao <len.bao@gmx.us>
> ---
Friendly ping.
Any comments are welcome.
Regards,
Len
> security/apparmor/include/match.h | 2 +-
> security/apparmor/lsm.c | 4 ++--
> security/apparmor/match.c | 6 +++---
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/security/apparmor/include/match.h b/security/apparmor/include/match.h
> index 7accb1c39..4a92cd044 100644
> --- a/security/apparmor/include/match.h
> +++ b/security/apparmor/include/match.h
> @@ -125,7 +125,7 @@ static inline size_t table_size(size_t len, size_t el_size)
>
> #define aa_state_t unsigned int
>
> -struct aa_dfa *aa_dfa_unpack(void *blob, size_t size, int flags);
> +struct aa_dfa *aa_dfa_unpack(const char *blob, size_t size, int flags);
> aa_state_t aa_dfa_match_len(struct aa_dfa *dfa, aa_state_t start,
> const char *str, int len);
> aa_state_t aa_dfa_match(struct aa_dfa *dfa, aa_state_t start,
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 3491e9f60..3f995b6a7 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -2432,12 +2432,12 @@ static int __init apparmor_nf_ip_init(void)
> }
> #endif
>
> -static char nulldfa_src[] __aligned(8) = {
> +static const char nulldfa_src[] __aligned(8) = {
> #include "nulldfa.in"
> };
> static struct aa_dfa *nulldfa;
>
> -static char stacksplitdfa_src[] __aligned(8) = {
> +static const char stacksplitdfa_src[] __aligned(8) = {
> #include "stacksplitdfa.in"
> };
> struct aa_dfa *stacksplitdfa;
> diff --git a/security/apparmor/match.c b/security/apparmor/match.c
> index 3a2c6cf02..c6f7bea1e 100644
> --- a/security/apparmor/match.c
> +++ b/security/apparmor/match.c
> @@ -31,7 +31,7 @@
> *
> * NOTE: must be freed by kvfree (not kfree)
> */
> -static struct table_header *unpack_table(char *blob, size_t bsize)
> +static struct table_header *unpack_table(const char *blob, size_t bsize)
> {
> struct table_header *table = NULL;
> struct table_header th;
> @@ -311,11 +311,11 @@ static struct table_header *remap_data16_to_data32(struct table_header *old)
> *
> * Returns: an unpacked dfa ready for matching or ERR_PTR on failure
> */
> -struct aa_dfa *aa_dfa_unpack(void *blob, size_t size, int flags)
> +struct aa_dfa *aa_dfa_unpack(const char *blob, size_t size, int flags)
> {
> int hsize;
> int error = -ENOMEM;
> - char *data = blob;
> + const char *data = blob;
> struct table_header *table = NULL;
> struct aa_dfa *dfa = kzalloc_obj(struct aa_dfa);
> if (!dfa)
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v4 2/7] landlock: Add UDP connect() access control
From: Matthieu Buffet @ 2026-06-06 17:11 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Günther Noack, linux-security-module, Mikhail Ivanov,
konstantin.meskhidze, Tingmao Wang
In-Reply-To: <20260522.reif5feiX0Ce@digikod.net>
On 5/22/2026 11:10 PM, Mickaël Salaün wrote:
>> + * Note: socket is not locked, so another thread could do an
>> + * explicit bind(!=0) on this socket, changing inet_num to non-zero
>> + * after we read it, but this would only have us enforce an
>> + * additional bind(0) access check and would not bypass policy.
>> + */
>> + if (inet_sk(sock->sk)->inet_num != 0)
>
> There is still a race condition, this should fix it:
>
> *
> * Hold the socket lock around the inet_num read to exclude
> * udp_lib_get_port()'s transient inet_num = snum write that is reverted
> * to 0 on a failing reuseport bind.
> */
> if (inet_sk(sock->sk)->inet_num != 0)
> slow = lock_sock_fast(sock->sk);
> num = inet_sk(sock->sk)->inet_num;
> unlock_sock_fast(sock->sk, slow);
> if (num != 0)
> return 0;
Oh wow, nice catch. The transient write in udp_lib_get_port() indeed
requires locking, a READ_ONCE would not even be enough.
>> + port0.ss_family = sock->sk->__sk_common.skc_family;
>
> Looking at net/, __sk_common.skc_family (and other __sk_common.* fields)
> should be replaced by sk_family (see #define in include/net/sock.h).
> Same for all other __sk_common.
>
> In fact, it should be READ_ONCE(sock->sk->sk_family) for consistency
> with the net/ code and because the socket are not locked when the LSM
> hooks are called. I realized that the existing Landlock code have the
> same issue... Could you please add a new patch (to be backported) to
> always use this pattern?
Indeed, setsockopt(IPV6_ADDRFORM) could mess with these too, I can send
a separate fix patch for that.
Thanks!
--
Matthieu
^ 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