From patchwork Wed Apr 26 17:19:22 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tim Gardner X-Patchwork-Id: 1774192 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=IOe34a/E; 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 4Q65G42t0Sz23vH for ; Thu, 27 Apr 2023 03:19:40 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1prink-0003YD-Rk; Wed, 26 Apr 2023 17:19:32 +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 1prini-0003Xq-SU for kernel-team@lists.ubuntu.com; Wed, 26 Apr 2023 17:19:30 +0000 Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) (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 9D3483F18A for ; Wed, 26 Apr 2023 17:19:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1682529570; bh=KtsIRD4bt1Xy7itF/hZOd74nRR5AVIbZJJOs6jYH1WU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=IOe34a/EyECqd8QjD581K8WHX/thvRXs35p8f8Ut75Wws5McN8Hmf0xioPtqwP9+J blA6j49Zwc/oiz6nM1032PUzaTaEu6ubjODA19Xvect9fJ0WleRLGF+ESwHnOsZ2gt IpmZJfjbCUP5xxrV/ecq9XDqcczyaJNrYGxFrfTgxcq8S0bFWK81QcUlcpXPJxlJ7V H/w56Jv0bN/lXCVeG6N/j++9TlhJEWmBHZiA9wlOfVqDrYRWeWbHKuMFKiDFJJNoCb WdsnZUrSYiluu6vndcRgHyj00BP3lgp8YY2myyWB6K1FajPwe3CMZb3Q44aXSuoto4 A26aWJZBMP58Q== Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-1a81e92ba00so48190115ad.2 for ; Wed, 26 Apr 2023 10:19:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682529568; x=1685121568; 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=KtsIRD4bt1Xy7itF/hZOd74nRR5AVIbZJJOs6jYH1WU=; b=CNoY4R9NWhQGK/4fjgBuSi8PC6PwSW7l7qVkRxTk4jjVUb3FncgoOobJht8HsW6AK+ DL1VFHU43rMz0M07IJFXl2IKspL2X+//aQxAXJ8K6p5f7KchU9WE6Tl+1+vUL4Y11mLG 2uPJnjPvZjMxNbhp+IEbuzSlzqFJNH8eZu5SyXpfso7HLibB0JKzvhEd9njCHzk2h1x7 BcBlOV1WWF2qeFA+tLJIS6fO1XpY+2XqCegZjzd+MSwL0wVb9UgTVZV5y1syBTtavkj2 xD+IrprDfpuDZID49wO+SO7bPDE8O1bYrBq58iilWdgUtJOhaVc6uLoF9fVRBFXkY8Fa 3D5A== X-Gm-Message-State: AAQBX9dCO5WgfdgyKXiA8VOJo2gnJymq/UbByyzdiIzGYTg8wGr9Y8GJ glsmtMugjhxzsgixWsbD3YUa8I2oXVJFhyXA/QvEvlzQaalGouW2qveIXEu405gtH7K7/7IC2OO Ga18Tza+7f9eAe8qwiq0zyTpoz8+2jQJuVeOV7jVbU9S9gr0GHw== X-Received: by 2002:a17:902:e80a:b0:1a6:34ea:6bc6 with SMTP id u10-20020a170902e80a00b001a634ea6bc6mr25249098plg.14.1682529567892; Wed, 26 Apr 2023 10:19:27 -0700 (PDT) X-Google-Smtp-Source: AKy350aCGXAglNQPRRLZthjPEvF/Qo0HvWzw8lsKPbNvVJh3C/Mr2DZuvgXj5bY+sWyCXQPyFsDFlg== X-Received: by 2002:a17:902:e80a:b0:1a6:34ea:6bc6 with SMTP id u10-20020a170902e80a00b001a634ea6bc6mr25249079plg.14.1682529567587; Wed, 26 Apr 2023 10:19:27 -0700 (PDT) Received: from smtp.gmail.com (174-045-099-030.res.spectrum.com. [174.45.99.30]) by smtp.gmail.com with ESMTPSA id l5-20020a17090a598500b00247a2498075sm9780256pji.48.2023.04.26.10.19.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Apr 2023 10:19:27 -0700 (PDT) From: Tim Gardner To: kernel-team@lists.ubuntu.com Subject: [PATCH] keys: Do not cache key in task struct if key is requested from kernel thread Date: Wed, 26 Apr 2023 11:19:22 -0600 Message-Id: <20230426171922.896150-2-tim.gardner@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230426171922.896150-1-tim.gardner@canonical.com> References: <20230426171922.896150-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/2017801 [ Upstream commit 47f9e4c924025c5be87959d3335e66fcbb7f6b5c ] 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/ Signed-off-by: Sasha Levin (cherry picked from commit 97674f4cd05ef35963a5f73ba785582c82801982 linux-5.4.y) 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 957b9e3e1492..17c9c0cfb6f5 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 }