From patchwork Tue Mar 26 14:32:08 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Hildenbrand X-Patchwork-Id: 13604283 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 697CDCD11DD for ; Tue, 26 Mar 2024 14:32:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB42B6B0085; Tue, 26 Mar 2024 10:32:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E6E476B0087; Tue, 26 Mar 2024 10:32:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D06C96B0088; Tue, 26 Mar 2024 10:32:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C07A16B0085 for ; Tue, 26 Mar 2024 10:32:45 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 466DE80BF9 for ; Tue, 26 Mar 2024 14:32:45 +0000 (UTC) X-FDA: 81939431490.21.50C6082 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf30.hostedemail.com (Postfix) with ESMTP id 8934180024 for ; Tue, 26 Mar 2024 14:32:42 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=W+PsGvPt; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf30.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711463562; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jCQ18XUYGXxAblag6bvSJIJrwTPD6Hhm3KxukBaiG2A=; b=763j5Ahcho9npTg02AXV6SZkORijXuQObY93zi2xap1UwzZs9ktirC1KlnoAx6SYzNn8Jt DWnZRRfqmZdtbkpLRxZGQmZnzLGePfR7OQoQJ+3L00MfgFpBBP3M0UqBdcOImLrqJCVL+/ IRTrbbzMdbMt3S1+XhfGMAyBd3rgChE= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=W+PsGvPt; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf30.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711463562; a=rsa-sha256; cv=none; b=Lo4q2wLwuIN2SsL5D2Y8nwlnFOWcetFaxmjUj3qAppLz/J9OBEFEf/kf3Kqc2jJov1aJRk rADwyg752Wz/6ELA1WgxKUZKcWB5Lxf7H6VyHnPARwYuIVTrgMizPqNEayDlGp5bVP8DcR nApPCDo/EQTmjTJSkHap9M7KX1rbSLM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1711463561; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jCQ18XUYGXxAblag6bvSJIJrwTPD6Hhm3KxukBaiG2A=; b=W+PsGvPto/7dV1XNioWFiWvQemJgIGerwYHPPYBPk0Nlukjx7FW34eU5wclCSi7KLJWmP7 yaEhusXhG0Jy5kB1URnwyPGQDbUOwm+8kBGcT6iZRPYw6Bx81T9ds3qAH27PSkWRjWiBZt xbYlTDSkmSygB1prZ7YGKRg/O20g1as= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-130-SUIk7uSiPqOSHPDYataC4g-1; Tue, 26 Mar 2024 10:32:38 -0400 X-MC-Unique: SUIk7uSiPqOSHPDYataC4g-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id 95BD23C0C889; Tue, 26 Mar 2024 14:32:37 +0000 (UTC) Received: from t14s.fritz.box (unknown [10.39.192.164]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6784340C6CBE; Tue, 26 Mar 2024 14:32:34 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, David Hildenbrand , Andrew Morton , Mike Rapoport , Miklos Szeredi , Lorenzo Stoakes , xingwei lee , yue sun , Miklos Szeredi , stable@vger.kernel.org Subject: [PATCH v2 1/3] mm/secretmem: fix GUP-fast succeeding on secretmem folios Date: Tue, 26 Mar 2024 15:32:08 +0100 Message-ID: <20240326143210.291116-2-david@redhat.com> In-Reply-To: <20240326143210.291116-1-david@redhat.com> References: <20240326143210.291116-1-david@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Rspamd-Queue-Id: 8934180024 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: bc88pryzfcgwrp8sqh3r664ccpmsfjk4 X-HE-Tag: 1711463562-191136 X-HE-Meta: U2FsdGVkX1+Uuli2uoCVXntUhIPKddl/ixIUeVJHsw/Ti5I4rhd8ewrPu33GfaoXR7TzoIG5rNAPIA4vWDzFoJEAsz7MkzONn6cFc1VV5uo/1aEMLpVmpIoYBh0XqdSxP5eLeGSf+Kvqu/a8YCnt7Epy9vGMasXJZfGfURq94Le7kB09trDExk69PlX6nOJUxKFqC9/h7eVbBx5W2nq4VjTghmaUBCB3/ZW4j9r8MRr+55ZFtw+ArfWCiVBlh1VFtkaQHvAoZZZkohLvZ5vUnQrVVmGAY471JUsjScyqinyaDUQGW9qjzgRw08VrW7pvIl1B1QFtJnCGl4YGfIHjmMu65AMR6dRlp/xqAJSSFogajWD4s5BzPCcFje/nIfR1ONlsF07QXB0yi8OA6ffmiXJCW27r1plXLvNAzlYX4jOf/DxVqR2pWnrOMmpT6KLJ4DFg1PzRB83LCjyCh6X4nsZ63R/Vju/6USEc/0CrJfilDqldOm18U+qoTZOwZ/82iB84lIJvatT6Dv9ocUxdee0nhksdDXcX+wyIF14LWL1U+qpn/oOnxfZAVccjzR7+N8BXJvhFkTip75rfqj6cgcN+igVgCvfKPzUJBGx/zg4/SBqwXyQ8bFrzS3ZFFpIsGnNBgaWYq4jwey5q5Wr1R8RpCJztHY/TsNZE9lmQZAr4COmOAgfnXAG/LW023rAXUIvOUNP05eYyACLG8xWuKJ0HWT6kLGo6Axshf9+hDRr37X4e87yvAKx9CjG/cV93cQYX13uI7pecXv9bHWPt50cGgZUlNhnVCl7lgGk16EwH+SofViTmoQauXRwFl/tSllPUfIGKGDXStZid74kdbre35acoTTaaJOa6hhbbWpMqS0krnZd6BYCUTSURsZxz8GF62PVa1g5EZ7nyNsUW6zdOMHxbZ/IlT1x9SdWJdd5qDsFQRjEhxL6UsAi1zCQMkYG5nxXtihwfD7nnI+6 dOx2QK4g N7ybjqGMiJMJbnkzgb6cr06mElg6U9es0ABjy+9NP2B4EUUNSf1AuM6nCW1dPdunYGRDnFgE77QVB9jOWnKQgDUIuHzjQVKniE8rjoLfzULT89xnM0sx2xcCS4734zCGKj6uuvvcFPICo/cUWVB5wY27M1SFjF635pB+4Ya6BG0sXhKZ590CN/EkxL/pmBLNCjlheVpFdIkO9YFXe20aRJQqu/2YKkqU3x+eRg+dqOD9rrqoe4h4ZEj9YF6ZgTK7W2AVp 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: folio_is_secretmem() currently relies on secretmem folios being LRU folios, to save some cycles. However, folios might reside in a folio batch without the LRU flag set, or temporarily have their LRU flag cleared. Consequently, the LRU flag is unreliable for this purpose. In particular, this is the case when secretmem_fault() allocates a fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might be added to the per-cpu folio batch and won't get the LRU flag set until the batch was drained using e.g., lru_add_drain(). Consequently, folio_is_secretmem() might not detect secretmem folios and GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel when we would later try reading/writing to the folio, because the folio has been unmapped from the directmap. Fix it by removing that unreliable check. Reported-by: xingwei lee Reported-by: yue sun Closes: https://lore.kernel.org/lkml/CABOYnLyevJeravW=QrH0JUPYEcDN160aZFb7kwndm-J2rmz0HQ@mail.gmail.com/ Debugged-by: Miklos Szeredi Tested-by: Miklos Szeredi Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") Cc: Signed-off-by: David Hildenbrand Reviewed-by: Mike Rapoport (IBM) --- include/linux/secretmem.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h index 35f3a4a8ceb1..acf7e1a3f3de 100644 --- a/include/linux/secretmem.h +++ b/include/linux/secretmem.h @@ -13,10 +13,10 @@ static inline bool folio_is_secretmem(struct folio *folio) /* * Using folio_mapping() is quite slow because of the actual call * instruction. - * We know that secretmem pages are not compound and LRU so we can + * We know that secretmem pages are not compound, so we can * save a couple of cycles here. */ - if (folio_test_large(folio) || !folio_test_lru(folio)) + if (folio_test_large(folio)) return false; mapping = (struct address_space *)