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 2F792C27C4F for ; Sat, 15 Jun 2024 23:52:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 16C126B00FF; Sat, 15 Jun 2024 19:52:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 11B9D6B0101; Sat, 15 Jun 2024 19:52:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F255C6B0102; Sat, 15 Jun 2024 19:52:56 -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 D5CB66B00FF for ; Sat, 15 Jun 2024 19:52:56 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 417B580E17 for ; Sat, 15 Jun 2024 23:52:56 +0000 (UTC) X-FDA: 82234775952.15.B57F607 Received: from mail78-58.sinamail.sina.com.cn (mail78-58.sinamail.sina.com.cn [219.142.78.58]) by imf15.hostedemail.com (Postfix) with ESMTP id C1125A0003 for ; Sat, 15 Jun 2024 23:52:52 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of hdanton@sina.com designates 219.142.78.58 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718495572; 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; bh=wtcDP1g0hn4XWYmCxPNJoB/X3GDgjVYHKpSgx5BGqrs=; b=S47S/emgcBUJGwQQSylYGtwkq7aKMLbQQkOU1sx4pxvC6Gkl11EHBqGeDYa9D3loW8DSQH 9d77XcG2kgaGuWrIySXzwOfGek+zOFIwGN0QZsH8nvxlnVkm5d0nc8ndCs88jL0TTA7lM0 uY3CUcvF27UJ61aMVTH+bEkTHO4RuAk= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of hdanton@sina.com designates 219.142.78.58 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718495572; a=rsa-sha256; cv=none; b=8hghN7DuykKyVJ+Z557P7JegkBccOmlbAzztOjaXQsmvn0V1o7iS3LC9UQ6anbEq2jpvtf 3yigecO53wN3QBZY3lGuym/Ig8DYGNihh0MSIYracgeMSq3KxUybF9fX9nU+LsLQYYCuRw aDLGfA90HcTk7r2xN3OGdGF6gczwwoQ= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([116.24.9.2]) by sina.com (172.16.235.25) with ESMTP id 666E294D00005E62; Sat, 16 Jun 2024 07:52:47 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 89047434210117 X-SMAIL-UIID: B5F68BFFE1BC4398B8FF78159B84E9A2-20240616-075247-1 From: Hillf Danton To: Matthew Wilcox Cc: linux-mm@kvack.org, Jan Kara , linux-kernel@vger.kernel.org, syzbot+d79afb004be235636ee8@syzkaller.appspotmail.com, linux-fsdevel@vger.kernel.org, linux-nilfs@vger.kernel.org, Ryusuke Konishi Subject: Re: [RFC PATCH] mm: truncate: flush lru cache for evicted inode Date: Sun, 16 Jun 2024 07:52:38 +0800 Message-Id: <20240615235238.1079-1-hdanton@sina.com> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: C1125A0003 X-Stat-Signature: muy769zxn99ex1ha6zawbhetwuinw5jh X-HE-Tag: 1718495572-930048 X-HE-Meta: U2FsdGVkX1/RTZpN2yu5vhlgJ/lz3V9H4wPN/CQ/V+odCsHpomxUuiDDNifVdq6BGeYbS+ysClG9XckLAKn22AebFreNf7x4swboumTXrQA1HtgQ21wFmk6pfRlhZTUU6//ah64MOdY/wlUz+tUAifb8tyMX0e4YFgUSQd+BDIAaAEPTZUdJX0U1ZtbJ3rzXErUymkRfPlEus/h+kAdFY3Hj97DPhdAIwkHSkianGBoSPUzVfUY6O2iMsraJtO6RV0d6RC7DjUJSR87BYovNmK4S+WDA9gaVK9uSZ/bYSeepGKYEJEmXno1LsIttp+vNZIQbAB4jK3OZ77OeI/cqGcpyPMgt12XxFDXERXTFAeJs1pxaZHmGAIFPpGo9it5VcTVBgL56PjP93cWdKK13oYr3R0HjpJWMLf4hC42/W1ecqSZDvXrmerUgvFXyAaZhnczSud3jCyF1AblyiizODTRRLjqykrkwFSz4dqqEjL6ITjLh5/yiFC9mdc+YWvRm7E076/cOso8wOm/SmDjk3vtp15GjOlaS1ALBcmwKOo5S34FQ6K7ZZpFxs46UwVqX4nV4JqNYh6fRJrIpY5GhbPTcotD7AvBKKDWL2Q1PuclTKsYBmR2RAyCiXl6HvmjtQsorhK6Wjg3bKI5fEOnjP2UwRZxsPgk8GNo7vmxezSC/nRqo8HiFInK9ImWGOONvwnim3XdahV1B3bvT9V16XoLnzBKJqH+fmbVbYTr50jh1sRK6LOOJzs3Fg3XOD62c4IsQ3TqYEGfRng7QrzGuRXkKea9sO84ykrgVCnPndwU0COAEcm1lD3Gr7Lx1n7u7IuYUGpU1VJWm2aGWrdQhhunAjECdc9dYP+Hwo0OwzTnqtcqPcyJTbAvfxwzGSYF88aEnx3i3RbDCc1AlabURfj4/a6lt8ZP6NLx0EF2IpgHqglp3FPT6GHpgVbU0flHuGlyuZP4J7c6Xsa3qQrO nvFFQFb6 1igEF3MSGUDp1CKzKiMtiu191OK6+7qtLNrRpQkmzciEbdYdoJTtJXW4MbDEBKJSPJWiZR00zW1xIXnFa62TX9Kr6HmDlo6hP6sB+PeMJmYrPbMcGtxovZloMkYO/IrdgcpEOpTR6doD44Pwx9kaf9Mr3f19sag3EbchXII/Evpr+DfYPgBAqPMaWOfAbTE6Vs3a2Pi8Ts4a4bcZCBFuDke0voUWiWAjkxWxc99Drki8bXFIlFp3bz8ZOFDe02J3PAY7VyjTKklwAWE7GfF6Q1sFBEKeakPKDth6sFVzDG6SUB1c= 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 Sat, 15 Jun 2024 21:44:54 +0100 Matthew Wilcox wrote: > On Sat, Jun 15, 2024 at 07:59:53AM +0800, Hillf Danton wrote: > > On Fri, 14 Jun 2024 14:42:20 +0100 Matthew Wilcox wrote: > > > On Fri, Jun 14, 2024 at 09:18:56PM +0800, Hillf Danton wrote: > > > > Flush lru cache to avoid folio->mapping uaf in case of inode teardown. > > > > > > What? inodes are supposed to have all their folios removed before > > > being freed. Part of removing a folio sets the folio->mapping to NULL. > > > Where is the report? > > > > > Subject: Re: [syzbot] [nilfs?] [mm?] KASAN: slab-use-after-free Read in lru_add_fn > > https://lore.kernel.org/lkml/000000000000cae276061aa12d5e@google.com/ > > Thanks. This fix is wrong. Of course syzbot says it fixes the problem, > but you're just avoiding putting the folios into the situation where we > have debug that would detect the problem. > > I suspect this would trigger: > Happy to test your idea. > +++ b/fs/inode.c > @@ -282,6 +282,7 @@ static struct inode *alloc_inode(struct super_block *sb) > void __destroy_inode(struct inode *inode) > { > BUG_ON(inode_has_buffers(inode)); > + BUG_ON(inode->i_data.nrpages); > inode_detach_wb(inode); > security_inode_free(inode); > fsnotify_inode_delete(inode); > > and what a real fix would look like would be calling clear_inode() > before calling iput() in nilfs_put_root(). But I'm not an expert Hm...given I_FREEING checked in clear_inode(), fix like this one could be tried in midle 2026. > in this layer of the VFS, so I might well be wrong. #syz test https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 83a7eefedc9b --- x/mm/truncate.c +++ y/mm/truncate.c @@ -419,6 +419,9 @@ void truncate_inode_pages_range(struct a truncate_folio_batch_exceptionals(mapping, &fbatch, indices); folio_batch_release(&fbatch); } + + if (mapping_exiting(mapping)) + lru_add_drain_all(); } EXPORT_SYMBOL(truncate_inode_pages_range); --- x/fs/inode.c +++ y/fs/inode.c @@ -282,6 +282,7 @@ static struct inode *alloc_inode(struct void __destroy_inode(struct inode *inode) { BUG_ON(inode_has_buffers(inode)); + BUG_ON(inode->i_data.nrpages); inode_detach_wb(inode); security_inode_free(inode); fsnotify_inode_delete(inode); --