From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86F4BE77197 for ; Tue, 7 Jan 2025 18:03:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 12DF16B0093; Tue, 7 Jan 2025 13:03:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0DD646B0096; Tue, 7 Jan 2025 13:03:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC1936B009E; Tue, 7 Jan 2025 13:03:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id CCC826B0093 for ; Tue, 7 Jan 2025 13:03:54 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4F3061A0BBD for ; Tue, 7 Jan 2025 18:03:54 +0000 (UTC) X-FDA: 82981429188.09.D11BECD Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) by imf25.hostedemail.com (Postfix) with ESMTP id E7A4FA000A for ; Tue, 7 Jan 2025 18:03:51 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=TXF2F0M4; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf25.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.171 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736273032; a=rsa-sha256; cv=none; b=hi4rxRbwMsDgRG1I/d6hhXpzUBrwzIHS0n1wHJMuvTYIuRw1OdZ9ZeWfCt9HSADUJXm28+ CEIsShfWj0uS/6N9MjgH1EQVzKKN9h5kleiSYkxVD8+NXPwiW78L7WZL/+Itj+YVB2fVMl u0xZ+1w+sVmdx1jUz4qjsmCGfRtJkmk= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=TXF2F0M4; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf25.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.171 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736273032; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LrVAuQ1nuUS81n75WNC20SAbQtETSilLabjNMZGXh/0=; b=lE4QuHavKEo2zbxYKv6jUjOlUmepIVPlU2OgmL/cyHMt3pfMJETOrXKeCNjiEaEnhDumDk 7+Ne1kQBStvuJKxMl4b/Ztgy8aKXQkdU6BYKyxtNLRsyZ+34ekIda4iPiwNYgCOTcpUAVd uT7U3pkbkjzoc4LDA6trwVNnKJs3vik= Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-7b9e2c1e3baso987854685a.3 for ; Tue, 07 Jan 2025 10:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1736273031; x=1736877831; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=LrVAuQ1nuUS81n75WNC20SAbQtETSilLabjNMZGXh/0=; b=TXF2F0M4LqUs1ZsOxaJ/hcnnZat4t1mCNiIVsQjKU+j1p4fMkL5H1RSscHA4fYjmP1 pvRr/JGs06Av8D3tCL/6kTrD6jfssnJtVZisf1wPLkdp2tH/rnCr5zPXT/GQL9+HTi5q 27P6vU5iD1vzCkp636PinUw0JiWReRWbYwxp5Eo+1df3n4WzjmhZjguzCctFW26t0jPW 4dsSyqbSshdeWaC6Xw5ak3SSqKeyNIOZEK3SXKWEDS3oXUm0Img3NhhC64oCBsuiFShk 2ZjNxRPFRzUZkEJCbJojSuLYs7cpmQodPyBbMley/BstqakvZ8XMhB4ZkJ7OCqSu8lxS RRhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736273031; x=1736877831; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LrVAuQ1nuUS81n75WNC20SAbQtETSilLabjNMZGXh/0=; b=CDab1YhBalykxynjOAZHCmmRJBnmTNItgfMTm8LKzmUr3fm/xjvaEeaufYyMXY0SaF A0qRZI4iU+jspxHtQELOtuASN10FfXiJ18dtqwrmibt5q1pB9yerGhFf0FzFmvJanxyN bGi1158ZJHZK1xpQdfzgsbws3Y6R2v5uX5xx8cmLWlMeIS8NIkiMbJ8RmmLXfWBsvXKB 5emolK/SK3LKTWgfkqSxIH7fGgggtPdAscTqvwqNZUNzLv2RlnC1A1YTfiBVdcJao9lk neeEwNXA5TU+neTHzCzq0ca+RqfglxynHoyOvoeoJ86wQ9vqIRtQayuigrT1/DT4NuLs yuJA== X-Forwarded-Encrypted: i=1; AJvYcCVvKfBXbkWZSZzYlv/6TWmJAaC1JcsQjwxV4GjphrclJvTHQnnlzK9pFeMb7uMSBzIUb0FJJnTFKA==@kvack.org X-Gm-Message-State: AOJu0Yykfv1zYklW+uOcGAHwPv0zCSXAdBCdGmyzo8wmyyfOM/4s7cpA n1227Q/86Ai5qMj9S+ZSVpST5tsj2ffH9h5+p0g1sCzJIsrk6vYGYcUsZHdIxQw= X-Gm-Gg: ASbGncu7XNp4Wsobqsg/fFQztm/6dX7F+iN0L3gDwRBg/bWsZNVGYQJVTRu90WBfAwa +frFJvMbyVKrVF1GM9L/hXSmiKdneslcXAERB8lSg2q3Y93nSigS9fUbVJy87H+Vnck2nlDn9LS u0ghl4LgUBg1Iujw4+T5lQV0DFSfDBSVJIgliVNAhPJiB4uxsRkOP9AjKQzSlwIFqkm082/6foi 4Vb5wq8ia+dWFTsjSMposZQF8PdTjH0FnBP0avVKnkcAuqF25qbn2o= X-Google-Smtp-Source: AGHT+IFl6p5h/awCPmTzw3RMPwNk4yXHopfv2hrojOPvo9EJXutNSG9yLbx8hfMAHYDNC/0n4jjd6A== X-Received: by 2002:a05:6214:48f:b0:6cb:e648:863e with SMTP id 6a1803df08f44-6dd233a6f14mr1042589666d6.43.1736273030789; Tue, 07 Jan 2025 10:03:50 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dd181d5adbsm182844296d6.115.2025.01.07.10.03.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jan 2025 10:03:49 -0800 (PST) Date: Tue, 7 Jan 2025 13:03:45 -0500 From: Johannes Weiner To: Yosry Ahmed Cc: Andrew Morton , Nhat Pham , Chengming Zhou , Vitaly Wool , Barry Song , Sam Sun , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH RESEND 2/2] mm: zswap: use SRCU to synchronize with CPU hotunplug Message-ID: <20250107180345.GD37530@cmpxchg.org> References: <20250107074724.1756696-1-yosryahmed@google.com> <20250107074724.1756696-2-yosryahmed@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250107074724.1756696-2-yosryahmed@google.com> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E7A4FA000A X-Stat-Signature: pqg31qz7gbazujuspr4p5scmjtp76jbf X-Rspam-User: X-HE-Tag: 1736273031-12758 X-HE-Meta: U2FsdGVkX18jTbi6mJWWmQkKXNuJTx7Q6JPpJB4+48i2R47jojoyHSCtEbp8f0xYPtGwVC1Iabh1z+vE9QLZzuFDLDhwpl5TNFx/OtQ9E6AINrhk+QWxwSgGs0HSPBc8pFmHLbwVpvVhRY/KjfSXA/GRjJesI+vJeu06QfnHzL3sh4EPicz+H+GOd+zcuiZIYkqMJp62V7skJ0y+kH4FnMSXpQn5D5jjlPo5nWKGG6oPYjG1xct44lg6zjjsyvzCddKc3lJllu131McCrNIT3idS6QSyqkqXQ39u/wnx88IbPJdDHWAxKvDyVzlXgIXKlS4FWRVXRXrCMuTVjOYanqNi/LTQLsattH1k7KssmPedJByzhW4Y9b7i4T5CDzytBM9o+daWUuh3Esqgyv66M0wykGfdoRn3UCCVOGg/tty0cRvN1LtX5CHwjixDDchGkiLpmOVBnoTCrsKI4iS6YT08ONuhvUxmdGpy2LJWJehlaAx0jLL6XXd5voMY/KtggbtfTbBcYlqppRimoBm3glvK1vqjazXRLAgWA15djMEswNOruj8KJOMTJnQ0mNMLixmiiRGhJBAtP0Nv4r2Tlg9RFcwI+ZFyFBLNs08p2FRdHJsLLmzbX3oDRcvNTxJoGrIXYjqd2lLlbO8kQOgOqzlvkMXcvMWWJNXXUxwGGAfKagkXaze4b2aqA0KE7Utd4Ma0/QYTEjdTk8BeZO6+v3EvOBSBEUbFPcY83IXJI/zhHV5/UZ/qE9UPtsobOOAUffZcgpA4PzaRRq5IdbOA5gdmJzNED653QJDGCvMKhJ8ZUa12PIGS+Z80BM5J897HjTDUQ+p60IdmgZBiwoxsiGmknd3DcZ+VHT2VjmVaRJ4UaXynj7h+uNhGockHGua9z8t179IEHtG9GYSxwFQuCbhFjKIzonckJTsDVoAH7wtVk6v8MvGCyhPDohsZUeQMBDx8ahGXewszGJCMw51 SQuAMHMp 4kTp2O92HubI8U2rI6P3Ve2OdzKgsiOv4f+I5J/4qHQInYBYSdl5sdRcWMivZu9K1+4KvKZFgzlGf+zv35oxLlIFl3ZoCSiMVO711tDbh7pxO0QI6ax0OLcmFJdHCTku7B37qOpE88w2vbJLkGtEchWcVfMGAys7Sd0okRKxvKBzsviPWvAP47cnDL7LdDLt0gopWnzUK1/Zl3rZn43ysV04KpJy8yIpR6ofiSBknrJNhcihI7rAmTJk+fD5oaMqdOHAb0VLsbDszBZ9/1LNM4NjHBHP2WvJhsEx6MVoot8o6+zmqQyYoq9xoTG3fhejGSfOet1nKj8BDUn0TEp1yLd1l0UjInpCCWrP1ym/TDHdd3r3t32VuN9zijFLFPzPhjx4rIaw4+9fWlv3l2DnCUZIK0ddaUx/DM/Ah/TXRnTo/2BFL8wBqqzwqPk3NjbX8mfQhvf+A+0ouRbHVa8d95YMcdbaY2askcnQbqT0pxoOrW1ByMuGVKCuVRZdHNHvTx6/Swqkd1PKWZR0lw6Alllu8QyhtINwswRH22ezzKyHrUlrkwZToZrq0gWpFP0sK6UAt8O6hlb9laQM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jan 07, 2025 at 07:47:24AM +0000, Yosry Ahmed wrote: > In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the > current CPU at the beginning of the operation is retrieved and used > throughout. However, since neither preemption nor migration are disabled, > it is possible that the operation continues on a different CPU. > > If the original CPU is hotunplugged while the acomp_ctx is still in use, > we run into a UAF bug as the resources attached to the acomp_ctx are freed > during hotunplug in zswap_cpu_comp_dead(). > > The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use > crypto_acomp API for hardware acceleration") when the switch to the > crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was > retrieved using get_cpu_ptr() which disables preemption and makes sure the > CPU cannot go away from under us. Preemption cannot be disabled with the > crypto_acomp API as a sleepable context is needed. > > Commit 8ba2f844f050 ("mm/zswap: change per-cpu mutex and buffer to > per-acomp_ctx") increased the UAF surface area by making the per-CPU > buffers dynamic, adding yet another resource that can be freed from under > zswap compression/decompression by CPU hotunplug. > > There are a few ways to fix this: > (a) Add a refcount for acomp_ctx. > (b) Disable migration while using the per-CPU acomp_ctx. > (c) Use SRCU to wait for other CPUs using the acomp_ctx of the CPU being > hotunplugged. Normal RCU cannot be used as a sleepable context is > required. > > Implement (c) since it's simpler than (a), and (b) involves using > migrate_disable() which is apparently undesired (see huge comment in > include/linux/preempt.h). > > Fixes: 1ec3b5fe6eec ("mm/zswap: move to use crypto_acomp API for hardware acceleration") > Cc: > Signed-off-by: Yosry Ahmed > Reported-by: Johannes Weiner > Closes: https://lore.kernel.org/lkml/20241113213007.GB1564047@cmpxchg.org/ > Reported-by: Sam Sun > Closes: https://lore.kernel.org/lkml/CAEkJfYMtSdM5HceNsXUDf5haghD5+o2e7Qv4OcuruL4tPg6OaQ@mail.gmail.com/ > --- > mm/zswap.c | 31 ++++++++++++++++++++++++++++--- > 1 file changed, 28 insertions(+), 3 deletions(-) > > diff --git a/mm/zswap.c b/mm/zswap.c > index f6316b66fb236..add1406d693b8 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -864,12 +864,22 @@ static int zswap_cpu_comp_prepare(unsigned int cpu, struct hlist_node *node) > return ret; > } > > +DEFINE_STATIC_SRCU(acomp_srcu); > + > static int zswap_cpu_comp_dead(unsigned int cpu, struct hlist_node *node) > { > struct zswap_pool *pool = hlist_entry(node, struct zswap_pool, node); > struct crypto_acomp_ctx *acomp_ctx = per_cpu_ptr(pool->acomp_ctx, cpu); > > if (!IS_ERR_OR_NULL(acomp_ctx)) { > + /* > + * Even though the acomp_ctx should not be currently in use on > + * @cpu, it may still be used by compress/decompress operations > + * that started on @cpu and migrated to a different CPU. Wait > + * for such usages to complete, any news usages would be a bug. > + */ > + synchronize_srcu(&acomp_srcu); The docs suggest you can't solve it like that :( Documentation/RCU/Design/Requirements/Requirements.rst: Also unlike other RCU flavors, synchronize_srcu() may **not** be invoked from CPU-hotplug notifiers, due to the fact that SRCU grace periods make use of timers and the possibility of timers being temporarily “stranded” on the outgoing CPU. This stranding of timers means that timers posted to the outgoing CPU will not fire until late in the CPU-hotplug process. The problem is that if a notifier is waiting on an SRCU grace period, that grace period is waiting on a timer, and that timer is stranded on the outgoing CPU, then the notifier will never be awakened, in other words, deadlock has occurred. This same situation of course also prohibits srcu_barrier() from being invoked from CPU-hotplug notifiers.