From: joeyli <jlee@suse.com>
To: Shaomin Chen <eeesssooo020@gmail.com>
Cc: keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
jlee@suse.com
Subject: Re: [PATCH] keys: Pin request_key_auth payload in instantiate paths
Date: Sat, 29 Aug 2026 00:23:16 +0800 [thread overview]
Message-ID: <20260828162316.GO6169@linux-l9pv.suse> (raw)
In-Reply-To: <20260526024838.3368409-1-eeesssooo020@gmail.com>
Hi Shaomin,
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
> 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(-)
>
> 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>
>
> /*
> * 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;
[...snip]
> 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 *);
[...snip]
> +
> +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);
> +}
> +
[...snip]
>
> /*
> @@ -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;I have a question when looking at the request_key_auth_new() in v7.2 kernel.
I have a question when looking at the error handling path in the
request_key_auth_new() code in v7.2 kernel:
struct key *request_key_auth_new(struct key *target, const char *op,
const void *callout_info, size_t callout_len,
struct key *dest_keyring)
{
struct request_key_auth *rka, *irka;
[...snip]
refcount_set(&rka->usage, 1); // here set refcount to 1
[...snip]
/* construct the auth key */
ret = key_instantiate_and_link(authkey, rka, 0, NULL, NULL);
if (ret < 0)
goto error_put_authkey;
kleave(" = {%d,%d}", authkey->serial, refcount_read(&authkey->usage));
return authkey;
error_put_authkey:
key_put(authkey); // here the key_gc_work will call request_key_auth_destroy()
error_free_rka:
free_request_key_auth(rka); // Why is not `request_key_auth_put()` being used here?
error:
kleave("= %d", ret);
return ERR_PTR(ret);
}
The request_key_auth_destroy() also calls free_request_key_auth() finally:
request_key_auth_destroy() -> request_key_auth_put() ->
request_key_auth_rcu_disposal() -> free_request_key_auth()
Direct use free_request_key_auth() in the error_free_rka path may cause
double free? Or I missed any information?
Thanks a lot!
Joey Lee
prev parent reply other threads:[~2026-08-28 16:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 2:48 [PATCH] keys: Pin request_key_auth payload in instantiate paths Shaomin Chen
2026-05-29 22:53 ` Jarkko Sakkinen
[not found] ` <CA+TOyfhe=0Ty-FQDZy-9_LWJ6dgakzyjog5rNfQ2NdCc5X+dFQ@mail.gmail.com>
2026-05-30 16:48 ` Jarkko Sakkinen
2026-05-30 16:49 ` Jarkko Sakkinen
2026-06-08 3:06 ` Jarkko Sakkinen
2026-06-08 3:10 ` Jarkko Sakkinen
2026-06-08 5:29 ` Jarkko Sakkinen
2026-06-08 5:42 ` Jarkko Sakkinen
2026-06-10 10:16 ` Jarkko Sakkinen
2026-06-10 15:21 ` eee sss
2026-06-15 11:53 ` Jarkko Sakkinen
2026-08-28 16:23 ` joeyli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260828162316.GO6169@linux-l9pv.suse \
--to=jlee@suse.com \
--cc=dhowells@redhat.com \
--cc=eeesssooo020@gmail.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.