From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A144437F005 for ; Fri, 28 Aug 2026 16:23:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787934208; cv=none; b=Khx+dhF9HHfcFbbBq0s56hEisrT9hNxoMwf85wZ+LLJZtejNw4h7ro0LTNHNZe2ArBQ/0uLboz0d6CJiAXu3pgI2ml5Ag3jnXSyKwMxpbdWRl8ZpNbhBviD4L7CZIYcLLIhmYOGk5QqmvX2SsfVVUga9iWI+WXWIK3yqXangAwA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787934208; c=relaxed/simple; bh=EXrA4Rz+Z1SUvLdlK6q1IWLQcN1MltuhMgX8g/P/Pek=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NZiRouBZQ5wbhcj/3Vh8qwoe0WPnYVnodbUjYC63L+9tZYXwY3xZHEEXPjf+moprUwVIUncevdaodoRetFp7dncFTJHGskDEiv7TM6y+P7ScbWqpFckOy+/QEy/GdMNQLATj3J0slLRimfGHv7GIpSUaB/2XIOgu4J3FrQVgY5c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=AOTqd3JI; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="AOTqd3JI" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-49b8e527d63so10297425e9.2 for ; Fri, 28 Aug 2026 09:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1787934204; x=1788539004; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to:content-type; bh=tOG+EsEc4JsO7LPts5VvW3Bv9S3ckFQ6qY35PjmYmcM=; b=AOTqd3JI/KyEnUFNpkBIfhzHPcUQS7vXdlHS16jaMf23nl28/q83kR8ueN2FdrgtqE bTUQND9vaXLxJWi/QE8FxNqhK35nf+xUEe9M7b26QNolMosWPYLJznGu+AVD46cJ6LHt Ypp6V7HFniI3FaDjcOhAyP06u3NxQBkaeXAv0TgwLLpziL03nAy1q93LE+NWFjEDbfPZ Q4IoKlz9QIGedqgBUhdErJb3YakO1YOmTxVERFkdWfjyjoajwYnhCK/dEUoiZCmOitfl nBbAcNCyOvEZjzpCePDjSi/NG0v7n3EdXNXRhwL8dcNJMmxCuHWnPqfou6FnXeQuG2WA nMYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787934204; x=1788539004; h=user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=tOG+EsEc4JsO7LPts5VvW3Bv9S3ckFQ6qY35PjmYmcM=; b=WjeNXqAGRuwAkx4vNxnfXzT1m2HrWfwwmweY09QbK2G7DzFfb6nQc+LBly/UXpJREo doEjcbQ7xp9YIpKgqi71bWaUAXk22jt/cz5+gCL+r08lGViya7aab8C+DpNlBWnODikW 2bBTNIwNTo4QDdRwsZ1aLOKy9yh7UFVa9NwozvlFcDSFYB/93XN4n/5WprzW0mHfmQfH ANNUEgBrab802MKhF42as+WKKMt/IHhOymTjc84ChQSUwwkiX7NBmT7iazZNarWOXLw7 Lp9jeNTpl5wx77eQA3Ao1QnPZrTZUQV76GLohEWhYl72ssExfLLvYShu65X2QNqM7+Pf Ynrw== X-Forwarded-Encrypted: i=1; AHgh+RqrDFWQc0N00sFo6GOB+dP5+YiQ7crNKs1+SHOIIZvYVxME/UrMhJ+SnudCtoj+LBKB294tjum4TcspfT0=@vger.kernel.org X-Gm-Message-State: AFuF++l3Sv4L+ri2vGgFE0+8YDH+j1rZBYWZuYu4W1qnyTOmHnRsdbPE CPCrYruBEnU1EL0oNfdsyVIoTM9TjrxIhVw2eUwn7SQl9YJkek51Y5jaKA+sOw/+LHo= X-Gm-Gg: AR+sD13FInsjxYD7yZos29AqHMfRORFeaftgA695lXTMzmexN0iUa0M7FiosIUIoSNv Vpkulb7xefTnn4ue+uN6PBLUSvw3zIybQXZgi/F4hCluxOW7kf4EeqvaSQkU1ba1IIqaq775295 er63I2WvluvRU+tRCecsaliVfimYwI1k2qMRM2W0+z8Hj3dihxePw/TR2inJulZJZAjDmfkcEUo +Pjm8l6LpO3so7RUVYUd7a6JKQ4h23SR2hPFFMzqTNyxv8ms7zL2HsbLV3uM7TvD8TzgAlH43U+ GNnenMJOWPLnvyRY4m9yut/IDmuhWqZhKehbEOF4v4wfQQCWVBnwMzLjnMQ35/u0qx6CTdwUmS+ cedC1xjn8BCDrNtifdfxzzoRQS7qvGCZalGOxnZG1tqm2SjWe1bjuJO4H+Tluui16jbHoNqi4Yx LAp5lP+sG1phCJMuBefsl7VhhMHUmm1GpsYi32pUh/YtJD8hZJDw== X-Received: by 2002:a05:600c:1c0d:b0:499:a5fc:207e with SMTP id 5b1f17b1804b1-49b91c338dcmr144866675e9.8.1787934203825; Fri, 28 Aug 2026 09:23:23 -0700 (PDT) Received: from linux-l9pv.suse ([124.11.22.254]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-142e0d38207sm7074939c88.5.2026.08.28.09.23.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Aug 2026 09:23:22 -0700 (PDT) Date: Sat, 29 Aug 2026 00:23:16 +0800 From: joeyli To: Shaomin Chen Cc: keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Howells , Jarkko Sakkinen , Paul Moore , James Morris , "Serge E. Hallyn" , jlee@suse.com Subject: Re: [PATCH] keys: Pin request_key_auth payload in instantiate paths Message-ID: <20260828162316.GO6169@linux-l9pv.suse> References: <20260526024838.3368409-1-eeesssooo020@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260526024838.3368409-1-eeesssooo020@gmail.com> User-Agent: Mutt/1.11.4 (2019-03-13) 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 > Closes: https://lore.kernel.org/r/20260519144403.436694-1-eeesssooo020@gmail.com > Signed-off-by: Shaomin Chen > --- > 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 > +#include > > /* > * 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