From patchwork Fri May 21 04:54:03 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: NeilBrown X-Patchwork-Id: 12271871 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0EAC0C433ED for ; Fri, 21 May 2021 04:54:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CE2566135B for ; Fri, 21 May 2021 04:54:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232447AbhEUEzb convert rfc822-to-8bit (ORCPT ); Fri, 21 May 2021 00:55:31 -0400 Received: from mx2.suse.de ([195.135.220.15]:55518 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232099AbhEUEzb (ORCPT ); Fri, 21 May 2021 00:55:31 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 185CBAACA; Fri, 21 May 2021 04:54:08 +0000 (UTC) MIME-Version: 1.0 From: "NeilBrown" To: Steve Dickson Subject: [PATCH nfs-utils] gssd: use mutex to protect decrement of refcount Cc: Linux NFS Mailing list Date: Fri, 21 May 2021 14:54:03 +1000 Message-id: <162157284381.19062.14252943620142216829@noble.neil.brown.name> Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org The decrement of the "ple" refcount is not protected so it can race with increments or decrements from other threads. An increment could be lost and then the ple would be freed early, leading to memory corruption. So use the mutex to protect decrements (increments are already protected). As gssd_destroy_krb5_principals() calls release_ple() while holding the mutex, we need a "release_pte_locked()" which doesn't take the mutex. Signed-off-by: NeilBrown --- utils/gssd/krb5_util.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c index 28b60ba307d0..51e0c6a2484b 100644 --- a/utils/gssd/krb5_util.c +++ b/utils/gssd/krb5_util.c @@ -169,18 +169,28 @@ static int gssd_get_single_krb5_cred(krb5_context context, static int query_krb5_ccache(const char* cred_cache, char **ret_princname, char **ret_realm); -static void release_ple(krb5_context context, struct gssd_k5_kt_princ *ple) +static void release_ple_locked(krb5_context context, + struct gssd_k5_kt_princ *ple) { if (--ple->refcount) return; - printerr(3, "freeing cached principal (ccname=%s, realm=%s)\n", ple->ccname, ple->realm); + printerr(3, "freeing cached principal (ccname=%s, realm=%s)\n", + ple->ccname, ple->realm); krb5_free_principal(context, ple->princ); free(ple->ccname); free(ple->realm); free(ple); } +static void release_ple(krb5_context context, struct gssd_k5_kt_princ *ple) +{ + pthread_mutex_lock(&ple_lock); + release_ple_locked(context, ple); + pthread_mutex_unlock(&ple_lock); +} + + /* * Called from the scandir function to weed out potential krb5 * credentials cache files @@ -1420,7 +1430,7 @@ gssd_destroy_krb5_principals(int destroy_machine_creds) } } - release_ple(context, ple); + release_ple_locked(context, ple); } pthread_mutex_unlock(&ple_lock); krb5_free_context(context);