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 EA89DCFB44C for ; Mon, 7 Oct 2024 16:36:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7CB716B008C; Mon, 7 Oct 2024 12:36:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 77B6B6B0092; Mon, 7 Oct 2024 12:36:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 61C1D6B0093; Mon, 7 Oct 2024 12:36:01 -0400 (EDT) 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 409846B008C for ; Mon, 7 Oct 2024 12:36:01 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id EE4B3A0795 for ; Mon, 7 Oct 2024 16:36:00 +0000 (UTC) X-FDA: 82647358080.29.FC253DF Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by imf09.hostedemail.com (Postfix) with ESMTP id 34091140022 for ; Mon, 7 Oct 2024 16:35:58 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=paul-moore.com header.s=google header.b="filXuZ//"; spf=pass (imf09.hostedemail.com: domain of paul@paul-moore.com designates 209.85.219.175 as permitted sender) smtp.mailfrom=paul@paul-moore.com; dmarc=pass (policy=none) header.from=paul-moore.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728318890; 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=FGLVVCKHdNtO/ioaopKZCdho+ecoPCau6mCNU2xBYcs=; b=c/5Ia4lozPNyNaG7sXcGl1QGgbzz4g61oUL5dYPKalUGGTIKKGhyIg1wgkIsePqiH0e1l3 UC0rLdcuhINvPB5cO6qKx/n84QHuFC36JpwOWvQA0+B+pQo2YtpfimVOKv27gmfNxXJ1xU FDx6opHGw7rt7VVjvNiYFFkndQaXpHo= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=paul-moore.com header.s=google header.b="filXuZ//"; spf=pass (imf09.hostedemail.com: domain of paul@paul-moore.com designates 209.85.219.175 as permitted sender) smtp.mailfrom=paul@paul-moore.com; dmarc=pass (policy=none) header.from=paul-moore.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728318890; a=rsa-sha256; cv=none; b=r/kafJffvf0i+PenosEWHHR+8LGsKZ7rtMd03+ABtWvMK0+Ybw2BYbjlrpBqxyHd/ljvXY FvmgxhJV8Ms6mfu0qPNszt4K5lO0eLsXt8DLXI9fNHECkKtVbmwtkwcsYuQzwDQnFfzOHy XVcEapf6Vlazm+KiWhnWJRAGuVS3CSc= Received: by mail-yb1-f175.google.com with SMTP id 3f1490d57ef6-e25c5ed057dso4246583276.3 for ; Mon, 07 Oct 2024 09:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; t=1728318957; x=1728923757; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FGLVVCKHdNtO/ioaopKZCdho+ecoPCau6mCNU2xBYcs=; b=filXuZ//pY55f6XDJHA50PMMTT5A11xvmBfh9RPrPR+Mj24on/4mhJQf3W1HryKbxO rQTAYOS81y/lH/InU7T6Z492L0l58QQsXGVtdWNt2jUtc45+IkR0sB3hLS9y85zi3RN6 W+lY3mtimjRtddlM236k+CmokQty1BUnn0FDhsPfFkVeF2xqJ+bEQLfc7sAAsUyUxJgy l3HcXlkVh+ofi7JrlqQVwu8yQdUoUvlsmh1tf4a4s81SN3x9GuLNXnAWGO4TKbFAuZU/ DzBuziGLkYVbkR1hPgjE4idtwSqD/QDJ4YCnk0F7pAo/rZ6M87NUeStpyIg2vWccC+K3 FFEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728318957; x=1728923757; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FGLVVCKHdNtO/ioaopKZCdho+ecoPCau6mCNU2xBYcs=; b=P702XLlEnb1aqA//B9H6NxuuUPHz2PRR9Qy4KOhlyVbDfYcfNiky/YlkWIJu2b5yQ/ C9TD7H3qjdAiTIvAL6vq0e4j+2tSY7h4jYKOvlfqqRaEAxbDPTy+Kgi7lLNuig2A3Lp+ MYghgpWNoFRKqRdW3BkJroQAOf2RNV/S1uTkP3mwitGsPNl/sK85w6RX3ur2nUub4OZ/ FwO0uXlCxaAbsnoPOM6EWZWLxctkvTVG0QzUj/tALPqQ8u8IlV2PO+UtLkEhwOVChe7k 2BZ0b2dBt9V9RvZ7keyvTvh9HWe6Rsl8zYjxSntbTzzMuVk857sXZ8n+XcDhKl2I/sFe PtNQ== X-Forwarded-Encrypted: i=1; AJvYcCUswp1e84HlUFkWDDqYBaMBsBXKLQQY6IIEBadQtsbLveCC9dEv/I7KE5e23ooi4ofhPaCmykigxw==@kvack.org X-Gm-Message-State: AOJu0YzqynX6aAKz4clhz9gQv3ybML6YqqnrbOuDc/uOcsQ8utKbejKd XvPx+U5IZ0zwx1cY+H9gFHKJTBQrV+3W/eMyHzufmnyYRY3L3zvCf0qYNy/XO81T6GTMCQtEB0c 75sjf/suCQqWda41jUxuAwaJM21FSDgv2q/uS X-Google-Smtp-Source: AGHT+IHMnCKj/L8qumQO35MXRgmOOBpLRXITDLkE2JHuYnlF1uX8MtmRoQF/PE4lBXFoP3VKXpQqHk5de4DKSnvSRQU= X-Received: by 2002:a05:6902:2301:b0:e1a:9379:5aac with SMTP id 3f1490d57ef6-e28937e4569mr9008649276.30.1728318957146; Mon, 07 Oct 2024 09:35:57 -0700 (PDT) MIME-Version: 1.0 References: <66f7b10e.050a0220.46d20.0036.GAE@google.com> <05e893036fa8753e0177db99dd48eb9d2e33476a.camel@huaweicloud.com> In-Reply-To: <05e893036fa8753e0177db99dd48eb9d2e33476a.camel@huaweicloud.com> From: Paul Moore Date: Mon, 7 Oct 2024 12:35:46 -0400 Message-ID: Subject: Re: [syzbot] [integrity?] [lsm?] possible deadlock in process_measurement (4) To: Roberto Sassu Cc: Shu Han , syzbot , akpm@linux-foundation.org, dmitry.kasatkin@gmail.com, eric.snowberg@oracle.com, hughd@google.com, jmorris@namei.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, roberto.sassu@huawei.com, serge@hallyn.com, stephen.smalley.work@gmail.com, syzkaller-bugs@googlegroups.com, zohar@linux.ibm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 34091140022 X-Stat-Signature: oj1trnzkdd6ctfcibxssxehpqgicn5zs X-HE-Tag: 1728318958-313705 X-HE-Meta: U2FsdGVkX19DV/RhF5c2dbRHJr9MOBxXYXDUV7HVpGZM8WBJOA3NzkiQ0PCAQ7x72JmfCxedZCytrMTWcqFMO/gZMypeUZEFQWKMA7G66q/NVcNkMOwvLza3Ln+6CEepMRAKvQaWm3x4YV68edNK4YySI8GllLedaxM/4VLVxZdllncw2awJXMaj3VIoUM3eDtmmk14Tp1gvLXwwYefDk9HSYjDYchHGZjFy8txzP10IbLfWhkmscPoqxytb5s97fi9+e2pyNAJcrFmbfco4EYgjgA28J8GHSGyJIDoPD7SRlA8VchLEUwZo+D3AANdWn8ZYxmA75lYBJgAlvnpxKwpnU+KbUZCkNxMuj/0bOwMqjptDJK5RXsikSkAFYe9G1J+Zc6xevnKra50dF+iueTlIaR/rjy94KG7V5GouD/K8RKQeXH9N17VdJ7Zyauu6g2VNXKukBhdVwfYE2udPKOWfk5JIgd6vldrSYVjTPTCpYUYYpV4mTY77Za6uSIKb/YGbFsnojoSvzDwRHvToVvTcNFhb49GfTkW1VqjqMJWxk/R5N/0ygtS5iWcqtn6FNVzBe8ct71Cq070NOskDPKO+TH39cVrHch/JlpT3K3MgTigpaVCjII69WGT+fplKMcplUuxLxRvxtdCLzI0k7eBG3tGRWjWc23TKwY7el9RPw4Gk6pge0cPXfkSL5MNNli8vt7iajb9/jKsiF0C4nyUgs+dX8AONYI+qKOHFIhC6o/bHe18AfxyK/ynlnrfuX9nxKtM0d9T0TmpRGZ/RTXRjF7XdUVtVnQ1To6CQjYG+X1MAUR3nJ8roeuGeaOXVzdQuuRYVK7sjvOZuyGSEIYx/NT+GE8i9zHWnO4gXo/qpYi/bLVRGSVujocdXacgNW85mruf9xCJCcP8iwj+jTAN+Ehavn+EHVcONAnsyBTUtjQxt/XK+TeTNRs/XYMEAVwLi/UeEXgJ+ACoSqXd V5Fqfqhn VrPlFHPHn2/CV8xSd5glZtQxQzOL9CMtLZUbNrIOESLO++oXA5UHlocEPTp45WMtGWHikl/jv3E0eT56gGDyMoo8SXqvL/12LClzcFg8KGz6lrOGSrbtpO3fjbVPZrXspx+MuIQ7Iz+55T2N39JMDIQrz+IMzyTvVoyhSY0KQ5zt9uxvDjBPM+Robx4gKCCh2zfqDH9fExrYrEBTU37XkD+grewh41X/78592z7UtwuG48eXyeXn8RcHZESHcA27ZuE9CRFGid1y3x0Nitx+0FiiJptH3o8JGCH+uOt8m6xmCHRQ8VfTof7wXj14PmXvgcm3z3C1smMvvbBxsanMo4BoPX3LbcS48kMQ61EnB4hsCivTJekh1QMdZXTBd9QREgBj2ZtYLMqN2cfefyZQyKHi5YaHfKcMZDUZKfcCQvIofDY21LQt4r5hoOdEvb3fJ9vCNAyHEPjAKDw7pm3lDHqFwEEGSlLhO+hS+iDVSSiKHAwGF+c3iry6EIQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.010698, 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 Mon, Oct 7, 2024 at 11:31=E2=80=AFAM Roberto Sassu wrote: > On Wed, 2024-10-02 at 23:09 -0400, Paul Moore wrote: > > On Sat, Sep 28, 2024 at 2:08=E2=80=AFPM Shu Han wrote: > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > WARNING: possible circular locking dependency detected > > > > 6.11.0-syzkaller-10045-g97d8894b6f4c #0 Not tainted > > > > ------------------------------------------------------ > > > > syz-executor369/5231 is trying to acquire lock: > > > > ffff888072852370 (&sb->s_type->i_mutex_key#12){+.+.}-{3:3}, at: ino= de_lock include/linux/fs.h:815 [inline] > > > > ffff888072852370 (&sb->s_type->i_mutex_key#12){+.+.}-{3:3}, at: pro= cess_measurement+0x439/0x1fb0 security/integrity/ima/ima_main.c:250 > > > > > > > > but task is already holding lock: > > > > ffff88807ac9a798 (&mm->mmap_lock){++++}-{3:3}, at: mmap_write_lock_= killable include/linux/mmap_lock.h:122 [inline] > > > > ffff88807ac9a798 (&mm->mmap_lock){++++}-{3:3}, at: __do_sys_remap_f= ile_pages mm/mmap.c:1649 [inline] > > > > ffff88807ac9a798 (&mm->mmap_lock){++++}-{3:3}, at: __se_sys_remap_f= ile_pages+0x22d/0xa50 mm/mmap.c:1624 > > > > > > > > which lock already depends on the new lock. > > > > > > This issue (if not a false positive?) is due to the possible `prot` > > > change caused by the processing logic for READ_IMPLIES_EXEC in do_mma= p(), > > > so the remap_file_pages() must perform LSM check before calling do_mm= ap(), > > > this is what the previous commit want to do. > > > > My apologies for the delay on this, I was traveling for a bit and > > missed this issue while away. > > > > Looking quickly at the report, I don't believe this is a false positive= . > > > > > The LSM check is required to know what the `prot` is, but `prot` must= be > > > obtained after holding the `mmap_write_lock`. > > > > > > If the `mmap_write_lock` is released after getting the `prot` and bef= ore > > > the LSM call in remap_file_pages(), it may cause TOCTOU. > > > > Looking at the IMA code, specifically the process_measurement() > > function which is called from the security_mmap_file() LSM hook, I'm > > not sure why there is the inode_lock() protected region. Mimi? > > Roberto? My best guess is that locking the inode may have been > > necessary before we moved the IMA inode state into the inode's LSM > > security blob, but I'm not certain. > > > > Mimi and Roberto, can we safely remove the inode locking in > > process_measurement()? > > I discussed a bit with Mimi. Her concern was the duplicate iint > structure creation during concurrent file accesses. Now that inode > integrity metadata have been moved to the inode security blob, we can > take the iint->mutex out of the ima_iint_cache structure, and store it > directly in the security blob. In this way, we can remove the inode > lock. > > Will write a patch and see if it passes our tests. That's great, thanks Roberto. Assuming all goes well we'll want to backport this everywhere we merged the remap_file_pages() patch. --=20 paul-moore.com