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 8788DD6409C for ; Sat, 9 Nov 2024 01:31:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B57F6B00A5; Fri, 8 Nov 2024 20:31:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 13F156B00A8; Fri, 8 Nov 2024 20:31:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED3766B00A9; Fri, 8 Nov 2024 20:31:06 -0500 (EST) 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 CCCBB6B00A5 for ; Fri, 8 Nov 2024 20:31:06 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id F3A81A1050 for ; Sat, 9 Nov 2024 01:31:05 +0000 (UTC) X-FDA: 82764826410.08.8FB8A6C Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) by imf11.hostedemail.com (Postfix) with ESMTP id E051740012 for ; Sat, 9 Nov 2024 01:30:14 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf11.hostedemail.com: domain of yukuai1@huaweicloud.com designates 45.249.212.51 as permitted sender) smtp.mailfrom=yukuai1@huaweicloud.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731115692; 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=/ytHRlmeJQb934h4z0GWVJG4Ny8EyTaPIHYWhgF5ACw=; b=yf7MlgMYLYx9D59C/3AdaTJVHwmOOOl1z/ihqtZCDr6X7yZ8gB/vhC5tONtmQ5lh0X9CdV IMenedvd3iVFCZbCR+FagD7TSlnnU6/10OhQwAwYBFUHUfJfVgavX72gNqDjYMVGaWu0Iz ysSt9xQYMf6ExzALzHpqLqNi8yWloMw= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf11.hostedemail.com: domain of yukuai1@huaweicloud.com designates 45.249.212.51 as permitted sender) smtp.mailfrom=yukuai1@huaweicloud.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731115692; a=rsa-sha256; cv=none; b=MT6kr+It+p+bceztmhlcUzi4iAg/xmpVJrwf8p3M6eVZS/eg3+UhsD0T9MzekKOycnlqCp 1FfRiIcv4ew5Bld/Pk9mGUMx14biCjEdMAosbAxChIAA6gpmIjU7RuSDDwjhWIRiUsH/fP OgIFrWuN9YCaEssovn83f5e8r+IvWhA= Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4XldY76fl3z4f3lVx for ; Sat, 9 Nov 2024 09:30:35 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id D90F61A018D for ; Sat, 9 Nov 2024 09:30:54 +0800 (CST) Received: from [10.174.176.73] (unknown [10.174.176.73]) by APP4 (Coremail) with SMTP id gCh0CgCnzoJLuy5nMaQEBQ--.46715S3; Sat, 09 Nov 2024 09:30:53 +0800 (CST) Subject: Re: [PATCH 6.6 00/28] fix CVE-2024-46701 To: Chuck Lever III , Yu Kuai Cc: Greg KH , linux-stable , "harry.wentland@amd.com" , "sunpeng.li@amd.com" , "Rodrigo.Siqueira@amd.com" , "alexander.deucher@amd.com" , "christian.koenig@amd.com" , "Xinhui.Pan@amd.com" , "airlied@gmail.com" , Daniel Vetter , Al Viro , Christian Brauner , Liam Howlett , Andrew Morton , Hugh Dickins , "Matthew Wilcox (Oracle)" , Sasha Levin , "srinivasan.shanmugam@amd.com" , "chiahsuan.chung@amd.com" , "mingo@kernel.org" , "mgorman@techsingularity.net" , "chengming.zhou@linux.dev" , "zhangpeng.00@bytedance.com" , "amd-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , Linux Kernel Mailing List , Linux FS Devel , "maple-tree@lists.infradead.org" , linux-mm , "yi.zhang@huawei.com" , yangerkun , "yukuai (C)" References: <20241024132009.2267260-1-yukuai1@huaweicloud.com> <2024110625-earwig-deport-d050@gregkh> <7AB98056-93CC-4DE5-AD42-49BA582D3BEF@oracle.com> <8bdd405e-0086-5441-e185-3641446ba49d@huaweicloud.com> <4db0a28b-8587-e999-b7a1-1d54fac4e19c@huaweicloud.com> From: Yu Kuai Message-ID: Date: Sat, 9 Nov 2024 09:30:50 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:gCh0CgCnzoJLuy5nMaQEBQ--.46715S3 X-Coremail-Antispam: 1UD129KBjvJXoWxXr4rAF4rWr43Ww4rurWxZwb_yoWrCry5pF Z7t3WjkFsrJr17Kwn2vw4j9FW0yw4fGry5XFn8Wry7AF909r1SgF4xGr1YkFyxGws3u3Wj qF4Yva47JF1UJaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUB214x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gc CE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E 2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJV W8JwACjcxG0xvEwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2Y2ka 0xkIwI1lc7I2V7IY0VAS07AlzVAYIcxG8wCY1x0262kKe7AKxVWrXVW3AwCF04k20xvY0x 0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E 7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Wrv_Gr1UMIIYrxkI7VAKI48JMIIF0x vE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE 42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6x kF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjTRJMa0UUUUU X-CM-SenderInfo: 51xn3trlr6x35dzhxuhorxvhhfrp/ X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E051740012 X-Stat-Signature: kc39fw3engzngdf1qbnyt98ghbxko1go X-Rspam-User: X-HE-Tag: 1731115814-187739 X-HE-Meta: U2FsdGVkX189NW/R0KkNC0MQN4Cj2EMdhyWBv84v4bInvyO9uXbtjYc3q9jwybF7oFjsElhDOtdHdqd9kGZZUEQjV0z8rBJ7ccMCJJomH5TFGHVvP1BXpTMrb3KgLfR9UVNdWeGdMHrmMs9RMx4eSv3fR1auhmpTfw7GKFbDIwHnEW41DzpFuGw8BCj+wqPXHbnU6aouz4pFABLgZXdXDSpTtO36OID+ubK1iXP+pGZBg5GyPztmz0OI4yzkG1kwvxOGDnhXivdsmfYEwS1ixYm+11R8AhpLbILVYu3CmPhBwifZ+qOWzDkAtckxaqGQQ7fquAr9jV40PerAGAnH0PGY1aySnAIyYEFyWHVmW6lxTQsfmXDR8c03VPHAX1gwjpYMDnKPdTxbT952fu2ffq/Zo8ZdIZDGZ5HivBoBzaNhsOz80+h1msbWtIt6VXSLIesaj0IcozFoldtHQCSSZp3F8SQ8PlaFdf+GBuyIPbWu4SDF1Jkqn7G0YpnQCbSxdWujlz5sqBnseX0ZT9+yKycPfqN9q5xwTRYM68TRwK6aQKG77LkfdgD+KY47oedePWnJ3lnMGqDK6+z6nlPksF9O+DRDAtYN2jPDaV6tdAyGcdFkLUQShSF+0IrZK5NwpJ36g1YPqyjcOacWRJNTgXFSPWUzQYp8Y4V2lYfK3VWdPAELgZa3AeKS1Qdwjxdzw8W/KbdVO/p3k197Ncvu2NrKisawlD3l7bcvEE35DWne7+efDgkpXc6F7XcEEGL7Yzq+YuwZb8gX4qGTC71pjGkTHYJbUpmakgSOXO0S0pw1+oXrNxXNCmCc5d+6LxsjRyujv5mde31EALOuxn4OfDtjWQwUfwmZTX6d+K+xxB1PsD1opMtc72dsOjiXftNYN1UcrsWtIdkuNMRlTLUnm8pkYPZLqOy55gXQA9/inrTnsYWtZNPqnwyDyA0cyaGYA3ZBKWrsNs+LR8PzjmR SwyBNu1L xxtmSb0S6knEhna5Hn5v6hWGec1b0j681+rhflLf26W26+Jw+ZXG5WtQJJhYk6S8W9ZdjcPvaNc8a05hV0eZK+5EpZ5Lc1DTi9PFno7W/j8f65yLnkxB3d6QqaRN+vtPAo659N2UsvsHuA/wa94YmS3cuwRwZVGYQ7gxclwEqYUXBCrhQO13yHWg7I/Pk+NDF2otJ/SRIbijkAiv41RjsP0w9V0Mak5wehDWnk58LgaBY2xHX3QfwwT1sZguaZig1bVfo4a6F/BlBcatD0d67mXtUT2IQ2gd3Cx2swDK7gOsTvct3FKRPFEAbf+u8TGW/T1xk 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: Hi, 在 2024/11/08 21:23, Chuck Lever III 写道: > > >> On Nov 7, 2024, at 8:19 PM, Yu Kuai wrote: >> >> Hi, >> >> 在 2024/11/07 22:41, Chuck Lever 写道: >>> On Thu, Nov 07, 2024 at 08:57:23AM +0800, Yu Kuai wrote: >>>> Hi, >>>> >>>> 在 2024/11/06 23:19, Chuck Lever III 写道: >>>>> >>>>> >>>>>> On Nov 6, 2024, at 1:16 AM, Greg KH wrote: >>>>>> >>>>>> On Thu, Oct 24, 2024 at 09:19:41PM +0800, Yu Kuai wrote: >>>>>>> From: Yu Kuai >>>>>>> >>>>>>> Fix patch is patch 27, relied patches are from: >>>>> >>>>> I assume patch 27 is: >>>>> >>>>> libfs: fix infinite directory reads for offset dir >>>>> >>>>> https://lore.kernel.org/stable/20241024132225.2271667-12-yukuai1@huaweicloud.com/ >>>>> >>>>> I don't think the Maple tree patches are a hard >>>>> requirement for this fix. And note that libfs did >>>>> not use Maple tree originally because I was told >>>>> at that time that Maple tree was not yet mature. >>>>> >>>>> So, a better approach might be to fit the fix >>>>> onto linux-6.6.y while sticking with xarray. >>>> >>>> The painful part is that using xarray is not acceptable, the offet >>>> is just 32 bit and if it overflows, readdir will read nothing. That's >>>> why maple_tree has to be used. >>> A 32-bit range should be entirely adequate for this usage. >>> - The offset allocator wraps when it reaches the maximum, it >>> doesn't overflow unless there are actually billions of extant >>> entries in the directory, which IMO is not likely. >> >> Yes, it's not likely, but it's possible, and not hard to trigger for >> test. > > I question whether such a test reflects any real-world > workload. > > Besides, there are a number of other limits that will impact > the ability to create that many entries in one directory. > The number of inodes in one tmpfs instance is limited, for > instance. > > >> And please notice that the offset will increase for each new file, >> and file can be removed, while offset stays the same. Did you see the above explanation? files can be removed, you don't have to store that much files to triggger the offset to overflow. >>> - The offset values are dense, so the directory can use all 2- or >>> 4- billion in the 32-bit integer range before wrapping. >> >> A simple math, if user create and remove 1 file in each seconds, it will >> cost about 130 years to overflow. And if user create and remove 1000 >> files in each second, it will cost about 1 month to overflow. > > The question is what happens when there are no more offset > values available. xa_alloc_cyclic should fail, and file > creation is supposed to fail at that point. If it doesn't, > that's a bug that is outside of the use of xarray or Maple. Can you show me the code that xa_alloc_cyclic should fail? At least according to the commets, it will return 1 if the allocation succeeded after wrapping. * Context: Any context. Takes and releases the xa_lock. May sleep if * the @gfp flags permit. * Return: 0 if the allocation succeeded without wrapping. 1 if the * allocation succeeded after wrapping, -ENOMEM if memory could not be * allocated or -EBUSY if there are no free entries in @limit. */ static inline int xa_alloc_cyclic(struct xarray *xa, u32 *id, void *entry, struct xa_limit limit, u32 *next, gfp_t gfp) > > >> maple tree use 64 bit value for the offset, which is impossible to >> overflow for the rest of our lifes. >>> - No-one complained about this limitation when offset_readdir() was >>> first merged. The xarray was replaced for performance reasons, >>> not because of the 32-bit range limit. >>> It is always possible that I have misunderstood your concern! >> >> The problem is that if the next_offset overflows to 0, then after patch >> 27, offset_dir_open() will record the 0, and later offset_readdir will >> return directly, while there can be many files. > > That's a separate bug that has nothing to do with the maximum > number of entries one directory can have. Again, you don't > need Maple tree to address that. > > My understanding from Liam is that backporting Maple into > v6.6 is just not practical to do. We must explore alternate > ways to address these concerns. Like I said, I'll just give up for this cve for v6.6. > > > -- > Chuck Lever > >