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 68224CFB44C for ; Mon, 7 Oct 2024 16:58:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B38E56B008A; Mon, 7 Oct 2024 12:58:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE92A6B008C; Mon, 7 Oct 2024 12:58:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B0236B0092; Mon, 7 Oct 2024 12:58:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7DB7A6B008A for ; Mon, 7 Oct 2024 12:58:14 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id F2A2140131 for ; Mon, 7 Oct 2024 16:58:13 +0000 (UTC) X-FDA: 82647414066.21.24CE12A Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf08.hostedemail.com (Postfix) with ESMTP id 29409160007 for ; Mon, 7 Oct 2024 16:58:11 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=paul-moore.com header.s=google header.b=d2OFTLPd; spf=pass (imf08.hostedemail.com: domain of paul@paul-moore.com designates 209.85.219.177 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=1728320224; 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=8FDLwYr0W0I2TyrqabkmE1dfXEL1zmhPVUq3NdPKOu8=; b=Syx4C2nTqPtYNvICCxf1KhjDs8oHy2sBJzfZkFEr9Ha25NuRTQFnckPYwQsZS1TvtuCH+g WhY0plR67DzA7QfWJ6rhNkdZaHgYrBUSaZiIlTANC4tot8A0wFcKnWCr6Dzg2JhkBcOV6h Vs4GugyUnmPJhGBDejysW2R9DEkKUxk= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=paul-moore.com header.s=google header.b=d2OFTLPd; spf=pass (imf08.hostedemail.com: domain of paul@paul-moore.com designates 209.85.219.177 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=1728320224; a=rsa-sha256; cv=none; b=rQDk5C8/9TMbd6FrKFvuFaRgXiHqxsx6AnM1AuwBTvzIvvrDtpgo2DSgs94bed6cf4wn2B DIncxz5voB8IqOZXrvhzFO1B4R/i64ZKce8AIs0WurYEX0TEcXQPYZcRpii1lkpkNUgvaf tol4xuETQuNb/5hujAuBI+oNMhJtUzA= Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-e25d405f255so4116025276.2 for ; Mon, 07 Oct 2024 09:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; t=1728320291; x=1728925091; 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=8FDLwYr0W0I2TyrqabkmE1dfXEL1zmhPVUq3NdPKOu8=; b=d2OFTLPdj4+OOYzZ4N32jooL3pn8wEVsWhy0L2CKS9Km98Xt4+PL9CeL29DmVEqNih YzmVF2f2I6F8QupmXm3TF1Hre+MHi6EPLiHe2I/Tb6cFduOU7IEJftC6GAIHN4QTjfDO zVoh5tIhpYhAGTzDJsFVkDWKN7xeMKCSd7osVlLOcJHZujnHz55DonXXrqcBwQaIIaq2 N8uOF5qdiPDvRqWjxdKmHTItz+/txqo/ZhpORGd3ev0Hdmj8HMRxYuAf5vhdmrX0wFL5 IwT6b9WKT9sBdc10vtiBAnXHc5z8U5kht1VbtPP9y8UtLZ7m6J0PIjjHd49Q9VOs2/pJ FyuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728320291; x=1728925091; 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=8FDLwYr0W0I2TyrqabkmE1dfXEL1zmhPVUq3NdPKOu8=; b=Qn8tibtydRYnsSL5xQlKv9E4/QuXI+/hSLm70UnGGyFpdDxNj1SB3nSH5iMgFpog41 QQn4CA4Ao1mFb7S8a8hObEDlrnAN70SB3mJ8ABVsEW7xrJlFhMI2hty4yUWt+G2VSdKi 9fCurqG6A2TL0OJmOmX9AiyKo5VYxgp3/0+JGRKu9E6gtpE0ybAmIUqKhYgcU9GIh8Pa Qq+DWTn7ue1+w8SWN/FXf+N8UqzG8Qb7Ds+kfDGOXpAbI5cqkt2shLwEZraRF+MLg3OY QHSxXw9ZAFvinmRzWy7NvY/GHOkyG6WNf7xU+ndsqJ2XqhgXF0qkm+YmBsuDwI3FV3vb qfJg== X-Forwarded-Encrypted: i=1; AJvYcCX4OQd4gBbsyTQhWr0ZqtaXs+zOfvRVCzvE1b7LZyd+5O//zOCxlsBXBvWmHaNcoj6XZsooIUpGKw==@kvack.org X-Gm-Message-State: AOJu0Yz2MC9PWsdckxCEQEV7reufqeMFEle+0VPSWQH38jm339WVZWXW jP6y0F1JFArsr9K/tDtlMEU004kOF/q5bC/8uYu8vacpNzg75u8G8TUzzd4XBtKToBv1JPwIoek duR8cGAnLmy7bRtRqkzcbuw2gcz21SpW+Sd82 X-Google-Smtp-Source: AGHT+IFNRdRw5/QfeWn+YZcg6EYhNUDISm5RwXNFrmhrBCU4JilAZjxQqSfb9m9kQ/pHzm2oJ8T1BPTDLI27V/5AAXQ= X-Received: by 2002:a05:6902:2408:b0:e25:c0b4:f364 with SMTP id 3f1490d57ef6-e28936dc8f5mr7574805276.17.1728320291200; Mon, 07 Oct 2024 09:58:11 -0700 (PDT) MIME-Version: 1.0 References: <66f7b10e.050a0220.46d20.0036.GAE@google.com> <05e893036fa8753e0177db99dd48eb9d2e33476a.camel@huaweicloud.com> <70f55efdba0e682907c895ea8ba537ea435bc3aa.camel@huaweicloud.com> In-Reply-To: <70f55efdba0e682907c895ea8ba537ea435bc3aa.camel@huaweicloud.com> From: Paul Moore Date: Mon, 7 Oct 2024 12:58:05 -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: 29409160007 X-Stat-Signature: os8yi6r8iw6get7uiu6tyk6u1iy49miw X-HE-Tag: 1728320291-666062 X-HE-Meta: U2FsdGVkX18b0xp1L6e44K/ySyUD74BQx3tlLElm1YZ9rbH1vlsXzjMX/3/RT9fnofKCQF2CUM1S9fuW98EFESXLiDouZsMYNuXmG0GMsPv4mnE5uyj2VLUnzjUmThibNMG1G5go+ehwUG4w+AGjWvJMXCGrzkJTZhnE9X47ZkbJbvqluEDfCgCTIEhzS+VrYY24e65a5fUHQ557LpkVQ9rfKhdjs9NJscGk/83RufEosBFnIXNVmzT5Hqo/0LcWno8XjudwKz32CiQif6hSvVz4aEN3szuISBlUaAZpf+Kzoh2hxldqGXZZQ0cwHUUq//y0GBulHFtrVguyCyTVEdugRxWM2kPSRfrxP++Wi/hhWqJTk+bOvw5+/vCLPzhumSkKvrCPMgOGVhQwxsDKaHUguhXuphPgzxyPlOdxoixntgYoavXfvEav4GgaSjR8/fq5UMs71+HJhN+qc4mCF+Bgm/aoxpMNRbP5GqcX4krH0TXedADZfGZC2sUlIMOrhHpzsYPasDg9B4tJuMwx0pbkbieDPKB+C9zk3wNfZ7bZDVq/3NVYFGTaQBFiZ7T9HGElElpcZBUeln1eSBKk8ybitPIq5/eyKwkIkckCA0q9Ez915Vy4Y3j9B3o50NLPGyWYZgkI6FXFkKctLWECtOXlmfFvULR037fKMAdIvIQ2h3sMXfQJLqZhP9826vHcR85p0v/Psb0brk+MxE0IDLRwNIhzzTdXgsMTzGyCbaXv3rDE1tu+Q2fQdHcvYaCRDtUZbWLhYz6o3KnkSvDInsR2pytL6V73Gs6GZBmRJKYExfDSoxgTjmzV/+biYURNwwPPVGF7ftFagV4C3/C+9MCbkVzbowH2SLLrf7T8cUoWrgNwS+wlapuXgDe6VAp/R5sJVXtV79BNCVNx16eRaqg3nwl0d9+WHsFhQwMXDHgwVSZk9cGwg0MpxQC6TIbtYOb56ILFUnnGh+YBcxX QA4/YENX 2ct6At0hsJiruKGMcFE1IL35cYgvwoL0mFIqu8ha2/011NFTPbuPJesDmj0HcsSLYGAz8ioW9CF8J3MzNTsxCcjH73eexX5DgMO6m27NhaVGrr0209N9HmYjlN9jH552Pbgx2r1n6gyEnFhCLPi6CSaJ/3eiDdzyWhwxHUtKv6KF82WL1hLqtvUtV2qB8p2prcPWpZL3ToHhTRuR6tA3slFT/1lBMJdJfiAjGg80luD5m6L0HetA/xI7AeW6Kptv9q8eTHOyfRo0zMRn/8PZlDTT/LIBIegmjvcpM7cjyry5AkXI5EZkB3B3x4UeZzqix/L3CUnhYMKIZ9IlImYhHBCAuT20ooNGA5/CuwW/UsaRiKqXcmtoVMxLpSOhQy+8lggFICFq563/eR0y8hTS1ErvhS/QTYBRui3csFId3AKNo7ievNAr6k/PDnIwZOvD3eBPnqGyxENvJJdVoS1xKOAKRHpElZyilESwuObi2oM8d7jElqn4K7Yq3Mg== 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 Mon, Oct 7, 2024 at 12:49=E2=80=AFPM Roberto Sassu wrote: > On Mon, 2024-10-07 at 12:35 -0400, Paul Moore wrote: > > 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:= inode_lock include/linux/fs.h:815 [inline] > > > > > > ffff888072852370 (&sb->s_type->i_mutex_key#12){+.+.}-{3:3}, at:= process_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_l= ock_killable include/linux/mmap_lock.h:122 [inline] > > > > > > ffff88807ac9a798 (&mm->mmap_lock){++++}-{3:3}, at: __do_sys_rem= ap_file_pages mm/mmap.c:1649 [inline] > > > > > > ffff88807ac9a798 (&mm->mmap_lock){++++}-{3:3}, at: __se_sys_rem= ap_file_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 `pro= t` > > > > > change caused by the processing logic for READ_IMPLIES_EXEC in do= _mmap(), > > > > > so the remap_file_pages() must perform LSM check before calling d= o_mmap(), > > > > > 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 posi= tive. > > > > > > > > > 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= before > > > > > 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 i= t > > > 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. > > Welcome. Probably it can go down only until the kernel where IMA and > EVM are LSMs. Yes, we'll need to look at that once we solve this in Linus' tree. --=20 paul-moore.com