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 D4846D0E6C1 for ; Mon, 21 Oct 2024 07:59:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 586396B007B; Mon, 21 Oct 2024 03:59:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 50E9D6B0082; Mon, 21 Oct 2024 03:59:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3880A6B0083; Mon, 21 Oct 2024 03:59:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 184FB6B007B for ; Mon, 21 Oct 2024 03:59:54 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8AE361616FF for ; Mon, 21 Oct 2024 07:59:36 +0000 (UTC) X-FDA: 82696860372.16.0E66966 Received: from frasgout13.his.huawei.com (frasgout13.his.huawei.com [14.137.139.46]) by imf03.hostedemail.com (Postfix) with ESMTP id 9920C2000C for ; Mon, 21 Oct 2024 07:59:42 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf03.hostedemail.com: domain of roberto.sassu@huaweicloud.com designates 14.137.139.46 as permitted sender) smtp.mailfrom=roberto.sassu@huaweicloud.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729497443; 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; bh=3BYFanm1dMpVWrml+12mScaqx8AUIOzKC+nIqw/7ivo=; b=EdI1VkE4r2Y1F95fYgNUY33qkEu7JH/HI9Jamg3UkoUw5QluHdFnN9sKQfOB6a5NoGpy+F WVSHkm0sE44bOfjV//Xmn95vUs5GM8187UhK7kiXdFR03U+qJQvLkV+Lz8PLzOh5Z+Lw6+ DokDYfbY5bVxS9I/ROFzzIw1yeigmyc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729497443; a=rsa-sha256; cv=none; b=1aE0kSMHSDEyuncmI2X9EVKA1Cvid2BohJ/iBq6koaV7uhRPajDNeKyHx8hgS0ENj+UUni lUdccMl4+BfDefiqWkAxj6TTbSWXoV0h48ATZ4NYicXXdlMq/OEcYHS5g21LNBwq+lkX5H P4IXPnRIC6MvJ5KHnOcjGwgzqB/iZCU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf03.hostedemail.com: domain of roberto.sassu@huaweicloud.com designates 14.137.139.46 as permitted sender) smtp.mailfrom=roberto.sassu@huaweicloud.com Received: from mail.maildlp.com (unknown [172.18.186.51]) by frasgout13.his.huawei.com (SkyGuard) with ESMTP id 4XX6dY2qhgz9v7JC for ; Mon, 21 Oct 2024 15:39:29 +0800 (CST) Received: from mail02.huawei.com (unknown [7.182.16.27]) by mail.maildlp.com (Postfix) with ESMTP id 1C1AF1400D2 for ; Mon, 21 Oct 2024 15:59:40 +0800 (CST) Received: from [127.0.0.1] (unknown [10.204.63.22]) by APP2 (Coremail) with SMTP id GxC2BwCXsYDdCRZnfdwkAA--.41168S2; Mon, 21 Oct 2024 08:59:39 +0100 (CET) Message-ID: Subject: Re: [PATCH v2] mm: Split critical region in remap_file_pages() and invoke LSMs in between From: Roberto Sassu To: Paul Moore , "Kirill A. Shutemov" , akpm@linux-foundation.org Cc: Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, vbabka@suse.cz, jannh@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ebpqwerty472123@gmail.com, zohar@linux.ibm.com, dmitry.kasatkin@gmail.com, eric.snowberg@oracle.com, jmorris@namei.org, serge@hallyn.com, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, bpf@vger.kernel.org, linux-fsdevel@vger.kernel.org, stable@vger.kernel.org, syzbot+1cd571a672400ef3a930@syzkaller.appspotmail.com, Roberto Sassu Date: Mon, 21 Oct 2024 09:59:22 +0200 In-Reply-To: References: <20241018161415.3845146-1-roberto.sassu@huaweicloud.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 X-CM-TRANSID:GxC2BwCXsYDdCRZnfdwkAA--.41168S2 X-Coremail-Antispam: 1UD129KBjvJXoWxAF1rZr18XFyrCw1xCryrXrb_yoW5Cw1DpF ZxK3Z0kr1vqryxur1aqFy7WFWrC3yfGrW7WrZ7Xr1ruasrXF1fKr1fGF45Wa4DWrZ7CFWF vF1jkr93Ka1DArJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWUJVW8JwA2z4x0Y4vEx4A2jsIEc7CjxV AFwI0_Gr0_Gr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40E x7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x 0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkIwI1lc7CjxVAaw2AF wI0_GFv_Wryl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4 xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r4a6rW5 MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I 0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWU JVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUIa 0PDUUUU X-CM-SenderInfo: purev21wro2thvvxqx5xdzvxpfor3voofrz/1tbiAQADBGcVvDAFpgADsY X-Rspamd-Queue-Id: 9920C2000C X-Stat-Signature: hxskchw8ds3uxsfzuuafaghqm3rd55j1 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1729497582-587792 X-HE-Meta: U2FsdGVkX1+pr0d4LPj3gtSfhYy0RIAOIu4LeqVfifIgcgiykrgg35THwSibZPRtsOYD9sXJe4omzr5g6wX3ieKeNmcc7iGckHhVTNK7la24BqNJavxJco6aI4ORGJEfLkccMs0BSFJMFE+a7rYPPd4nVG2AjV2PBpFwcFLNDT+fBjbOEgvBOQDVbkySnDLN7iX2ua6N+4gVcf5//nYRXjI8Vzu4b4oOie9ifQWwVht7eVKROnO4I45+O3JG/UL2SVodqS7tcfAYXRUkfT8CIgUYLM4aYybUPHZ35qtxenbBsjVdgAGBn8QVJg3anNw3Jp9lqLP3nwHqhHFgOh12K9jXP4KyiVBHj0BANMJgcx0S5NoEZGPG7+T9z/7B97cXanx5kkKRL96DcWP9TFhuzcYPfAhQDwJlHUVz/wnnAHtOyeK+ZI4mYZMBR9t8GnHXq1u/rYc0b0o5iTCTppW+He/QFF3XkHpu0Mg6z4/n76x9OPuDsoPXObiFr+NrejJHYP1+753K903OGiXUwWzgj3quRwOK5qcVxCEt/HdrOH5Cf3GAK3MZn3O5tPGrq3EdNEztO119Wbb0hVJrQOIwFQQ+n4Y/iiTfztgB3jgOI/DuCdR6TPVkjeyzASBoH75GTkZ2OlQUSjfqW5n4e80c5aEA7Pi+v0gUoCmiN0Da7tBoVc6Vl5/aLe8JrY0TjP4NjpXpj8cINyaQaLXIxPv2fsMggvcZnDkc8xACA7t9EK9LVWlrFX9brhm05SoFUYPX1AkDVEATK1f5+Ady47HMH9bnRglaWZGGzcwawDrPWrjtSfoMzZiJGXvCMkZeV5RwIbxu1ii246ikkNd1h4/oh174NApEER76boo5ZWpH5JnPKaibo5ejlyUocSIpV3TyWkbB85AUV/AZHKIH33fS8JM7DEs8nzPmse2ihpObAIZVgN4Ym1bppl0pDZLMSGLxZbArp3TLiI3JEGQktHF VNJn1kqK 09but6X55KfOPb+wrtDy5FKh4dcctDf433NYFR7LoezGcFCkBgPuBz3fogblFIDgDGCFAcpEnhHQrwHgmde2G1pHI2LMwxjNdQuJatUMriBWUoZgqfert8/zWPItOCHek1UeSC89s/L1Kbx3l7RuZZFFL7KKCwr/FyKhnHIaR8fSywsA81y4gPjCi7JokaGEPzLW5SiiZLKcruiv40s3wTeeBG/MGMCkyvHgBmO8M7RlFV81TTLkU1bhUPtKiAwnI7Y9wPBzmoZhlRfwr0oTOcnpovKhgfKtb8Jfm4nbDqikWdiEfQFtlG++MTo/5CGQ/s8fwA0GoHlYokoLlD0nApIULNBACp4mKxaRjmBzVPRxy8arLxfHqaVXQqOH951dWipLgzshJ0YtX0bye6QO8lK/K+rvOkZa9FfQ3b/OlfsofTsBuyopxU51gEKHdU59F8QUKrpVKoCi4KmscnjjcsFOUoc/lFauLQ7fm+MOt1CF713pO8R1pOoc/Yqdknw/Dimr4jAoxD5/9wF43g57+CE8taQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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 Sat, 2024-10-19 at 11:34 -0400, Paul Moore wrote: > On Fri, Oct 18, 2024 at 12:15=E2=80=AFPM Roberto Sassu > wrote: > > From: "Kirill A. Shutemov" > >=20 > > Commit ea7e2d5e49c0 ("mm: call the security_mmap_file() LSM hook in > > remap_file_pages()") fixed a security issue, it added an LSM check when > > trying to remap file pages, so that LSMs have the opportunity to evalua= te > > such action like for other memory operations such as mmap() and mprotec= t(). > >=20 > > However, that commit called security_mmap_file() inside the mmap_lock l= ock, > > while the other calls do it before taking the lock, after commit > > 8b3ec6814c83 ("take security_mmap_file() outside of ->mmap_sem"). > >=20 > > This caused lock inversion issue with IMA which was taking the mmap_loc= k > > and i_mutex lock in the opposite way when the remap_file_pages() system > > call was called. > >=20 > > Solve the issue by splitting the critical region in remap_file_pages() = in > > two regions: the first takes a read lock of mmap_lock, retrieves the VM= A > > and the file descriptor associated, and calculates the 'prot' and 'flag= s' > > variables; the second takes a write lock on mmap_lock, checks that the = VMA > > flags and the VMA file descriptor are the same as the ones obtained in = the > > first critical region (otherwise the system call fails), and calls > > do_mmap(). > >=20 > > In between, after releasing the read lock and before taking the write l= ock, > > call security_mmap_file(), and solve the lock inversion issue. > >=20 > > Cc: stable@vger.kernel.org # v6.12-rcx > > Fixes: ea7e2d5e49c0 ("mm: call the security_mmap_file() LSM hook in rem= ap_file_pages()") > > Reported-by: syzbot+1cd571a672400ef3a930@syzkaller.appspotmail.com > > Closes: https://lore.kernel.org/linux-security-module/66f7b10e.050a0220= .46d20.0036.GAE@google.com/ > > Reviewed-by: Roberto Sassu > > Reviewed-by: Jann Horn > > Reviewed-by: Lorenzo Stoakes > > Tested-by: Roberto Sassu > > Tested-by: syzbot+1cd571a672400ef3a930@syzkaller.appspotmail.com > > Signed-off-by: Kirill A. Shutemov > > --- > > mm/mmap.c | 69 +++++++++++++++++++++++++++++++++++++++++-------------- > > 1 file changed, 52 insertions(+), 17 deletions(-) >=20 > Thanks for working on this Roberto, Kirill, and everyone else who had > a hand in reviewing and testing. Welcome! > Reviewed-by: Paul Moore >=20 > Andrew, I see you're pulling this into the MM/hotfixes-unstable > branch, do you also plan to send this up to Linus soon/next-week? If > so, great, if not let me know and I can send it up via the LSM tree. >=20 > We need to get clarity around Roberto's sign-off, but I think that is > more of an administrative mistake rather than an intentional omission > :) Ops, I just thought that I would not need to add it, since I'm not the author of the patch. Please add my: Signed-off-by: Roberto Sassu Roberto