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 52AAED64099 for ; Sat, 9 Nov 2024 01:39:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D9236B00B6; Fri, 8 Nov 2024 20:39:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7877E6B00BA; Fri, 8 Nov 2024 20:39:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64F326B00BB; Fri, 8 Nov 2024 20:39:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 473346B00B6 for ; Fri, 8 Nov 2024 20:39:08 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E79E980173 for ; Sat, 9 Nov 2024 01:39:07 +0000 (UTC) X-FDA: 82764847200.26.2D8D259 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) by imf18.hostedemail.com (Postfix) with ESMTP id AFB901C000C for ; Sat, 9 Nov 2024 01:38:46 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf18.hostedemail.com: domain of yukuai1@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=yukuai1@huaweicloud.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731116285; a=rsa-sha256; cv=none; b=EaDcpS7H4/F1g9Hee1KuUQmwoTKbTi/0DXVusxifu94OIz0ivuBpjaAcerF3M+QrD0dvjh 9lOR9eOSh9lmglO3GOZGvLYEDKGWpvPQzuXhYOgLOwrxJ8oIYdC359U76F7Jh6QPV1Iwom P8kF8P9CD+509MgCCuu/++hawdQfqZo= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf18.hostedemail.com: domain of yukuai1@huaweicloud.com designates 45.249.212.56 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=1731116285; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KIcoVgi3xMJfmXGSqIU8cixETlI4Dot6Jcygta0FW1Y=; b=sxyUmrJmB3RDMZ/krb3AxA6aQwX+qluk+MBglNYEJWwpxiIP1aj2twuwgADO3DhqCFB8CL TicL3tSdDOcgvConOOZBlTTHzUI/wHZMANzs/IXc56cbIOH+FiriAOxrDZGrl6b88pYW6B c20N2V6ADYrKqOtCW6bKByvuOAQYw0g= Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4XldkS1kvLz4f3jsL for ; Sat, 9 Nov 2024 09:38:40 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 51A451A018D for ; Sat, 9 Nov 2024 09:38:58 +0800 (CST) Received: from [10.174.176.73] (unknown [10.174.176.73]) by APP4 (Coremail) with SMTP id gCh0CgCHY4cwvS5n0C0FBQ--.61013S3; Sat, 09 Nov 2024 09:38:57 +0800 (CST) Subject: Re: [PATCH 6.6 00/28] fix CVE-2024-46701 To: "Liam R. Howlett" , Chuck Lever III , Yu Kuai , 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 , 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:38:56 +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:gCh0CgCHY4cwvS5n0C0FBQ--.61013S3 X-Coremail-Antispam: 1UD129KBjvJXoWxAw1xCFyfWrW8Kw18Xr4ktFb_yoWrAF48pF W0qa4jkr4DXr17twn2vw1UZFW0y3yfJry5Xrn8Gr17Cr909r1ftF4xGr1YkF9rWws3Cr1j qF4Yqa47XF1UJaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBI14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gc CE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E 2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJV W8JwACjcxG0xvEwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2Y2ka 0xkIwI1lc7I2V7IY0VAS07AlzVAYIcxG8wCY1x0262kKe7AKxVWrXVW3AwCF04k20xvY0x 0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E 7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Wrv_Gr1UMIIYrxkI7VAKI48JMIIF0x vE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26F4j6r4UJwCI42IY 6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aV CY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7sREfHUDUUUUU== X-CM-SenderInfo: 51xn3trlr6x35dzhxuhorxvhhfrp/ X-Rspam-User: X-Rspamd-Queue-Id: AFB901C000C X-Rspamd-Server: rspam01 X-Stat-Signature: 33wpcc3p9sba1ihn4u1usnqicmuzc8dg X-HE-Tag: 1731116326-807803 X-HE-Meta: U2FsdGVkX1+Cqq3voEYCzgmVhBiKQLvuMbLMaUD3v1f6aHz+iA4PJ6GEYzgMv6mdleOsAEtypyo/55C4LIU+iDImeAeZwIvFgkRCNGdJG5aUi2AeWnp8MTaN/eFtf7u0nEnDxDMap9LKX6bflvfyVYeVO4imixMFDetQQQ8+tirKp8UHs7sep8HCHYB7p+fSlXdGjU+kH+nnXy9uZf7shYKxpTAmDVcVDz8tQIAgCd5uXTWgoEKxFYeSX9YOxNRdq9mN2tMKuwTLXauWFi5sWA8VU6BPIEg4i7U+rz+bzlj6X6xzz7Ygx53dp/S9Gsm08z9USfQF3TpKorgmWJWyoFVapxalJHdeDBfso0GjIyzNy1gmlmIizS8zG7xYv+GqPYuKwgPqSpqsOr/Tn+SzwZrRJ+aaUCHEWKOTijEf2VIMAsGeOEHcRX1UwGppdW9MJ0D+JWwgH6TvkjkqymU2/XSaHnZcYRBG+2PEYsTtOaH73CNOnd/nXJNNT9lGeDfOe6xsqfrqSb6XxRJZNihs7cj3N5F94rUu68S7QUb2DLSGiYvjhRsdQ7KYbE/PWENzxdhU1Gl73FQJM33p0mzpWqAmqJwxxY9HSPR8lxrn0r5t2FmYg1AJKyZcM/j0OhFxzA+NFaPSnNbe5Pf9Fh4mZdiUzyP8PG0huOMfFKWK4L6mP13JZXHB7Y2/CqtFshW4oAsdWQr4xG4zsuHi5yFv23+ZxDeBhvOeLqq8sTkpybb90LIf7aveFa6MBF31zEzDZjh46h/tnoAxGWoI+aJ4xVTNj1VK4eHY0D4na6wqBP0wv3VRu7k6u14oUhG/DHQaTxi/K+1BABR1RgZUJyPWBG84dXpm16e4YRqGUPL9PrSuq1MvLxlujGpKoZthvfr73Ax0tZhkH3EGHfzjjAW+k4jjRE2eeT+nRtV8YwjShoq6Ss3UkpRMz0XK7LmQmGRlZ4DplD6VRHefYNxeyWH 5oqso/Vo 2/i0RTtzMGKOUOe+pzI6/Kp4wO7hLi4YFBJzlji6eUYilwfG0XgaGOpT2vZgH9NkI4SQLAsYqxVtmlbHXq3Uw9nXOeSB1eeknzAa46RVxVWWX9ZNFjd7kehzrwXMXFqYP3PIS+1iL+krX/8eaV8fWsjMbGAMKTfr+sLebXaLQgbxUmyugjYNgpTce31Ixt0K+n/h87Bovk+fx1gwsIfJgVLogmzFfsmkyyxk4q8KbrwJZFUF+ylwFxpGJb93ScWTwBr0WCnD2aarGmCUvjz4lPWJX0G7bQ1m9A2n6A5sXF000UYi3Bm46x10B602uBL1VlzhT0UgOV6ISA1O+Fuwxqze5Fg== 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/09 1:03, Liam R. Howlett 写道: > * Chuck Lever III [241108 08:23]: >> >> >>> 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. >>>> - 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. >> >> >>> 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. >> > > The tree itself is in v6.6, but the evolution of the tree to fit the > needs of this and other subsystems isn't something that would be well > tested. This is really backporting features and that's not the point of > stable. Of course. > > I think this is what Lorenzo was saying about changing your approach, we > can't backport 28 patches to fix this when it isn't needed. I don't have other approach now, so I'll not follow on fixing this cve. I'll be great if someone has a beeter apporch. :) Thanks, Kuai > > Thanks, > Liam > > . >