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 3F638D5D69F for ; Fri, 8 Nov 2024 01:20:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D6446B009F; Thu, 7 Nov 2024 20:20:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7851A6B00B1; Thu, 7 Nov 2024 20:20:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5FEB76B00B5; Thu, 7 Nov 2024 20:20:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 40E3B6B009F for ; Thu, 7 Nov 2024 20:20:00 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id AA9B21C50E6 for ; Fri, 8 Nov 2024 01:19:59 +0000 (UTC) X-FDA: 82761169932.06.6FCA9ED Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) by imf07.hostedemail.com (Postfix) with ESMTP id 9654F40017 for ; Fri, 8 Nov 2024 01:19:01 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf07.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=1731028672; a=rsa-sha256; cv=none; b=lpT4NKAR1/hzny1+lrq0rOXKPjVsILNtfpCcGEE1lBUJI8IhLoasPVfvN92cyw8pxiN8hP jEY6QOpx8WF68ucWstbm3D7WIFYb55O5lYeYfLU+RAnYclCh/WTf3hZGYJ4QKN9pc7bcaX /LKI6apdkPv+mZNDJUuE9Lke1szr/8w= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf07.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=1731028672; 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=0sxvxIacGi3xa/alxT5gAFEMAra21rIm3eoAGnYtpiA=; b=Gf481U6+nwaN4Nm+lXFvxM0n4Sz8gNtpZeQn7/tHJiE7shAPmrmat0nUrZGEgpGrFO5lFJ FZNQiHW1h6xOMWKhbg9bwq6D1CPGmPteD/vK1YKwp1gaK/QNk8GDvpuK0mX6l8xCTlta95 Rz75szBxvSD1zd6zIcfbfBHKPXwbfA8= Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4Xl1Ls6RLdz4f3jv6 for ; Fri, 8 Nov 2024 09:19:33 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id D04461A018D for ; Fri, 8 Nov 2024 09:19:46 +0800 (CST) Received: from [10.174.176.73] (unknown [10.174.176.73]) by APP4 (Coremail) with SMTP id gCh0CgDHo4ctZy1n00WkBA--.29471S3; Fri, 08 Nov 2024 09:19:44 +0800 (CST) Subject: Re: [PATCH 6.6 00/28] fix CVE-2024-46701 To: Chuck Lever , 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> From: Yu Kuai Message-ID: <4db0a28b-8587-e999-b7a1-1d54fac4e19c@huaweicloud.com> Date: Fri, 8 Nov 2024 09:19:41 +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:gCh0CgDHo4ctZy1n00WkBA--.29471S3 X-Coremail-Antispam: 1UD129KBjvJXoW7ArW7CF45Jw13Cw4DtFWDurg_yoW8Kw48pF ZFqas8KwsrJw17KrnFyw1jqFWFyws8Jr15Xrs8Wr1UAF90kr1SgFWxGr1Ykas7Wrs3uw4U KF4ava4xJF1UGaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBF14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4U JVW0owA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcVAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628vn2kI c2xKxwCYjI0SjxkI62AI1cAE67vIY487MxkF7I0En4kS14v26rWY6Fy7MxAIw28IcxkI7V AKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCj r7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWrXVW8Jr1lIxkGc2Ij64vIr41lIxAIcV C0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF 04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7 CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x0pR1lkxUUUUU= X-CM-SenderInfo: 51xn3trlr6x35dzhxuhorxvhhfrp/ X-Rspamd-Queue-Id: 9654F40017 X-Stat-Signature: 3qganrsswgtwmypi5fqo16khn8z5ap84 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1731028741-395144 X-HE-Meta: U2FsdGVkX1/vbVZbLlwfDpZSs4UxDjHm8svWNvA21pvAT2X/NCAY8eLkDFj4qxPYkeaNpAzJCDN6K1RJVimbFU09E8DEHnaVkYZBqMZ+QdRQyYGPIYw6jSBv4jbfe4WnXwn5O7K+nTn3V/wjd+1LtZhLcRKIO16VknOi2Oalc2lU5zKx6Wvvrjv4vK/Sb9Ooz2a4TgBW+2QjcfFW2HA8+rj92HLi9Qw3k2qaMdsJAE8PjGFfUnKR2xH6CO81B3o3DVxz42QyF4qVpzVQ3KdF+Yob9U2R5vZQ970g1m+ISesLOOUu8JBdhoUrpxNdPpFkNdxkn1NIqTO/X8TPP3dYT0FPD0LTNy8U2iH7qqA9EzCtNj0V04Byn21QUY8lcdKN58JjIeydXyWaeRz8UAjU5wn4bHOuXHAbd8/gLKtQf7BCFXMfTqPvQ7W+WKG4azum7K4fD+UkfpmGIwhy/PD0YksuhadWE/RcslhyuWCEYgr3Oirf7WXu7QgzywPDawD1q8bWjbtrWbj/xl9k874fBpvZzWxawMWrLWKHJRJGuJ8gnvc5igGazISTjfLILTRvnX9/ZgVbyW8CZWLuSMX5An5rE3KDmC2LPgGlXhn9OesOMbcgVPvs/gBLBY7WjMujJEVq/5MGF0v9hFmyjLvtZBfxlNiTJLzfjvtfB5WyxkI4BvExQhfQbjDnayAvq8gs4vMg8JshxdAIXua+BH3FGwslEOJqtbFadAWdTpfjKTq5HNFZKkoUTVAuxG7mx2Vlu8JROknkCZ91y76As7tCtXvI58gTYE93EcaUBHRvX/FxMTeh+9nqKshkWF2gRz0pwfos9CnRfsJi0oXTU8GtUZzYxQoMzLFbdNoeq8ebXYi80J1K9+6eksY48d4q2kECeQ2H+h2PV2JJtn1/gxlYM4yT3fdekxhsH7Ju4IgNIHpX+8jFhPVAXOxv1vS6qLRhukor2R4a/fqvLcdsht8 Pi/vewq5 J/Y5nbCv7YDs1VjnOZgkMna+IITlNisl3PLapV747/T4IJ37cnRKfwPpSHSKiwdK6TAtrXFxvpOi5Ekbh0+DugU9rKI4/UTn4TP8N9EsA6+zlBYqmRQA7ZpGa+T0UdEpXd+DcYydGHe7fe4jsvDS8gmVXz30vSTbhBFco0jTyK7SF64Gc84Ygvz0SnsglzPvRtilya7owOF59NzgXxuj0j5XdyxgZke0ipdkhDm46LSuN60aplefIdUSNxqpt8m6FXAUmD/NKsGiJiUqG/KgudOg76HxLzpmpJxBZnLrW7IOW+R5GZv7p/vJoq8iZUQZaVmfG 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/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. 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. 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. Thanks, Kuai