From patchwork Thu Mar 30 18:27:10 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tim Gardner X-Patchwork-Id: 1763397 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=p8a/BgQj; dkim-atps=neutral Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4PnX2l17Pjz1yZ1 for ; Fri, 31 Mar 2023 05:27:26 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1phwzY-0003Lq-SG; Thu, 30 Mar 2023 18:27:20 +0000 Received: from smtp-relay-internal-0.internal ([10.131.114.225] helo=smtp-relay-internal-0.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1phwzW-0003Ku-KR for kernel-team@lists.ubuntu.com; Thu, 30 Mar 2023 18:27:18 +0000 Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 4F91F3F236 for ; Thu, 30 Mar 2023 18:27:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1680200838; bh=CJ1PElOlMt7y7unR3oO2rWOLaMVgGC83lO7Imr8nUVA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=p8a/BgQjSQk7deBRewHpAx0RSWKhBnPOcuD/ltGRCDd8qHw6QHF2RS8DvRILGQ2fi uY8WJ6BnaGV46+FQE80oAFShxhSFfh+0+aEOlwrDx1UON4F9BHx+uXEA4nXVekeEJ6 Sj2ntUqG5Sn2tt/qLSM0npHTwOwZiANS5ZhRXw+x6dyyiDpULXNTJvtp8PdciI7AKI f5dXrDLKPfCVVU9sAzp3C/ieJc8uHOHyJr2Qjgc5SzjjhpBAVd6rQa/RcVWCNR61Cy IaQOtN/Qnvrjyq9SIYx/x1B/yRPtEw6C5d792x+Q5dFBhbLGnzBGkQmGa2BssyssK2 7tX/KjNl8qQLQ== Received: by mail-pf1-f199.google.com with SMTP id t67-20020a628146000000b0062d6d838243so6851189pfd.21 for ; Thu, 30 Mar 2023 11:27:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680200836; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CJ1PElOlMt7y7unR3oO2rWOLaMVgGC83lO7Imr8nUVA=; b=J5pnfQ4CQFc28oKrl4PX/m3usd6nyZSSBH5cdsHIx8hb77X8TyYeuHj9u2CyHMnLrB hPwOsuV/L9H1jCxwXoJsqpYh4UQasWVmxKfQuXDIyI3RI4gkOIbHRR4W+2TrdlonmwiB jC40hwR8Uid0MYlYxpkx6fiokLTl4668YyDUM9Z6Aw2G0IKkfe78u0lZ+BauTbmR/0UC XVg8UEZYoqdVaI5m8edgSegohddqCQK42h0gHmGVlqrO2RcAg21ySzvS/In9ME9Czw7P WGLKHJ1cf3CtLwSJ/jpVf+Q9x8i/yiElMriJ9IZX2niaoGmJmhTHTqNgycosQEKTdn29 21uw== X-Gm-Message-State: AAQBX9etp+Osp8U2NRj2NBg2Plk841BumKYxjoZrt5vQnG8/JOeV65Oe id0bmkyEzgK535+jbgs2cAt3jG2/IQgN91Y7zciPSaDnsA2suQmPOeeuBdV01CSm8vhoU+uy6bJ mPPW8pbpzv47xiPN/xU7o5Hq5DiBn2Ypk9wQaUuspmzYWfU2Snw== X-Received: by 2002:a62:7b10:0:b0:625:c048:2f81 with SMTP id w16-20020a627b10000000b00625c0482f81mr23063552pfc.32.1680200836402; Thu, 30 Mar 2023 11:27:16 -0700 (PDT) X-Google-Smtp-Source: AKy350YocU1uawVlZiF8iSci2aDWh5D+2jZ/+hg1ZKdbu7FGQ2KXlW3xSPSrrX9kqK2gzSm0TUlgdA== X-Received: by 2002:a62:7b10:0:b0:625:c048:2f81 with SMTP id w16-20020a627b10000000b00625c0482f81mr23063539pfc.32.1680200836133; Thu, 30 Mar 2023 11:27:16 -0700 (PDT) Received: from smtp.gmail.com ([69.163.84.166]) by smtp.gmail.com with ESMTPSA id d19-20020aa78e53000000b005d61829db4fsm179375pfr.168.2023.03.30.11.27.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Mar 2023 11:27:15 -0700 (PDT) From: Tim Gardner To: kernel-team@lists.ubuntu.com Subject: [PATCH 3/3] keys: Do not cache key in task struct if key is requested from kernel thread Date: Thu, 30 Mar 2023 12:27:10 -0600 Message-Id: <20230330182710.1141816-4-tim.gardner@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230330182710.1141816-1-tim.gardner@canonical.com> References: <20230330182710.1141816-1-tim.gardner@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: David Howells BugLink: https://bugs.launchpad.net/bugs/2013349 The key which gets cached in task structure from a kernel thread does not get invalidated even after expiry. Due to which, a new key request from kernel thread will be served with the cached key if it's present in task struct irrespective of the key validity. The change is to not cache key in task_struct when key requested from kernel thread so that kernel thread gets a valid key on every key request. The problem has been seen with the cifs module doing DNS lookups from a kernel thread and the results getting pinned by being attached to that kernel thread's cache - and thus not something that can be easily got rid of. The cache would ordinarily be cleared by notify-resume, but kernel threads don't do that. This isn't seen with AFS because AFS is doing request_key() within the kernel half of a user thread - which will do notify-resume. Fixes: 7743c48e54ee ("keys: Cache result of request_key*() temporarily in task_struct") Signed-off-by: Bharath SM Signed-off-by: David Howells Reviewed-by: Jarkko Sakkinen cc: Shyam Prasad N cc: Steve French cc: keyrings@vger.kernel.org cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/CAGypqWw951d=zYRbdgNR4snUDvJhWL=q3=WOyh7HhSJupjz2vA@mail.gmail.com/ (cherry picked from commit 47f9e4c924025c5be87959d3335e66fcbb7f6b5c) Signed-off-by: Tim Gardner --- security/keys/request_key.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/security/keys/request_key.c b/security/keys/request_key.c index 2da4404276f0..07a0ef2baacd 100644 --- a/security/keys/request_key.c +++ b/security/keys/request_key.c @@ -38,9 +38,12 @@ static void cache_requested_key(struct key *key) #ifdef CONFIG_KEYS_REQUEST_CACHE struct task_struct *t = current; - key_put(t->cached_requested_key); - t->cached_requested_key = key_get(key); - set_tsk_thread_flag(t, TIF_NOTIFY_RESUME); + /* Do not cache key if it is a kernel thread */ + if (!(t->flags & PF_KTHREAD)) { + key_put(t->cached_requested_key); + t->cached_requested_key = key_get(key); + set_tsk_thread_flag(t, TIF_NOTIFY_RESUME); + } #endif }