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 AADECD12D5C for ; Mon, 11 Nov 2024 00:57:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F23B6B0099; Sun, 10 Nov 2024 19:57:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 37AFD6B009A; Sun, 10 Nov 2024 19:57:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CE3B6B009B; Sun, 10 Nov 2024 19:57:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id F01F76B0099 for ; Sun, 10 Nov 2024 19:57:07 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 79A1C1A11F9 for ; Mon, 11 Nov 2024 00:57:07 +0000 (UTC) X-FDA: 82771998834.10.FC37877 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) by imf06.hostedemail.com (Postfix) with ESMTP id DF26B180004 for ; Mon, 11 Nov 2024 00:56:32 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf06.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=1731286564; a=rsa-sha256; cv=none; b=Oekt64zQAixkQRV7qevINtOCDV3pah7WH4+fsfuTJP7y8ZGB9D+klT9B+eJMw5UY5c2Avs hSBQS6lMNyL6SUf6z89JFZlgPJt35OuNT6BxDjU0hebwpRk2V8UNpVhSwDFKBeYTNwlYaU ZZmZgyeB6kZSJL3rh3jY7fjOT5hg5uY= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf06.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=1731286564; 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=1JsrDogQ9K56ZWLbpbqL1JM1g6PPoloTo0lqS0F+sOA=; b=HWjkfa/0Z8NG5t+XqriYae6RkSwigTIp1Fn1BibKzFy6LH384kV34nhxEAPECnDDLH50Pc W/frhbBHSM+0hew6BJFOeu435LUQ5g4iGWiaoFLaAvvPxtwHF7qijnOm5hBd+YBuDg0M3h W7OrUocGpeZ8lOgKjn+j4tM1pvj2JnM= Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4Xmrj0755nz4f3jYW for ; Mon, 11 Nov 2024 08:56:36 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 253A41A07B6 for ; Mon, 11 Nov 2024 08:56:55 +0800 (CST) Received: from [10.174.176.73] (unknown [10.174.176.73]) by APP4 (Coremail) with SMTP id gCh0CgBHIoZSVjFnd7PCBQ--.2481S3; Mon, 11 Nov 2024 08:56:52 +0800 (CST) Subject: Re: [PATCH 6.6 00/28] fix CVE-2024-46701 To: Chuck Lever III , Yu Kuai , Al Viro , Christian Brauner 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 , 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> <976C0DD5-4337-4C7D-92C6-A38C2EC335A4@oracle.com> From: Yu Kuai Message-ID: <48bb5f01-b82b-79a7-dbc6-6ec91bcaab67@huaweicloud.com> Date: Mon, 11 Nov 2024 08:56: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: <976C0DD5-4337-4C7D-92C6-A38C2EC335A4@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:gCh0CgBHIoZSVjFnd7PCBQ--.2481S3 X-Coremail-Antispam: 1UD129KBjvJXoW3Ar18GF17ZrWDJF47Xw45Awb_yoW7AF1kpr Z5t3Wjkr4DJr12kwnFvw1jvFyFyw45Gry5Xrn8WryUCas09r1fKF47Gr4Y9a4DGws3Cw1j qr4ava4xZF1UJ3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUB214x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26F1j6w1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gc CE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E 2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJV W8JwACjcxG0xvEwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2Y2ka 0xkIwI1lc7I2V7IY0VAS07AlzVAYIcxG8wCY1x0262kKe7AKxVWrXVW3AwCF04k20xvY0x 0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E 7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Wrv_Gr1UMIIYrxkI7VAKI48JMIIF0x vE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE 42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6x kF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjTRJMa0UUUUU X-CM-SenderInfo: 51xn3trlr6x35dzhxuhorxvhhfrp/ X-Rspam-User: X-Rspamd-Queue-Id: DF26B180004 X-Rspamd-Server: rspam11 X-Stat-Signature: px7n35q9trrd5pgszwtkuedsid5f5or4 X-HE-Tag: 1731286592-370469 X-HE-Meta: U2FsdGVkX19rwLLh8+3nsbcewqj2ps+UJkrtdmRelAdl6uLjop4ltN4pEc397ZhVHYOW3FBpA23gfyWV7GWF0tiayVfawWQXo092aUjEFqJjHBGelceUIw2ZDLJ0ZwtWYTrhKBlM+6wBMGQQZGBuK5ruk1lqV6Wsgui8hcGTGYuVTadgyG60aehpv4/JdyIhcpoGV97nk51EZuUyjALvO3QALL9FHbaIvBJZ4JjyD1sikb9cn/P7KyAdOhxJuavDhA6MfgbSFf+mc/dAoTuQkZBYvdQvEpUGsH2luxu9FsmRHSFXccgnBlk1AWgzko5KGD8pEgxO8s+PqUQ72j4iY7lh3bTqIthMVTeWyPlZqcH4wxJkzfaA/kJYew7ONhAbzVGy6unIkrvZohL4L6Fejugavekiz8OYN73QvNH0LpVQMC1B75mxbkUxUr80Gqep3eyzrXMi0hbWdy89rMyFFQwszyi5t/F9uY6AqqedXi/GvI2/cW4QGW6tX3cTl9By23s8UeZocNDaI6R+l8+PqUYjgVTFErUVUbNBHTmP004488956r3bHJGs8oi8gS9bj//4qt7s5XEFyg4qp09UBTb6Adu4oZdjXfDaiJJ4gj9y91BF0sOZXMDhkAf6cobd/BKYOgD6RetElre9uedqcHBfihY1G7mx0+gPC641mY9bwbkGJCdue5/usJI2BP18quka6/cO7fUsXLxLt7wfke7BB3sH8mUewFYKdqvLTedXqQx4Wf1NoJ4PakpXziOMFfQvrM9bc25Sqce60U6zFAXgSAwlTWgNp3B4JFD//PP+c6PIkezuB/OsNwPSRA32mStPusZn5wDEbZNiyI9bxlKl9IFpWQeyJ7zqTQ8iHostgQu4tTL95c6oqIMZalftPIsBn53LjCXLOzYGsvmV/6YtQr7VXr14x2Si+iN8oZ3LjTbvcoT3hgU0fKz47+5FrRTKZX01FTLByBkdqHq XTmBjYYB VY0gXWEkacB7cGa/+B5Hqt8ppwwKov8eyKHGtv1beQG+Q4o+yCUSZwP1yprsesw8tdjN3+Mi/FpGBRuMEfI6UszSkjhrYIrkIZj/KVSIp5rJO43EYZnqS69g6PIkWLNQ+2XO8eyNR3EMD4ACQCNvLJCLKCcu1I9jFaxL7mw10VIhc0/oluMDrerueYfPH8DHMniAiqSzlYQQ7lpsgOuYF+GDbrRGBSD0y3KvHoPDjTKEEM4i4r15sh5FbHdh+9uaD9mOmmfGNcDPFaQFH+CazkukBPGpO3UVDNTLZtQP7Caot3Y9JPJsWCj9JdjihRLIvXybP 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/10 0:58, Chuck Lever III 写道: > > >> On Nov 8, 2024, at 8:30 PM, Yu Kuai wrote: >> >> 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 trigger 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 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. > > > Let me revisit this for a moment. The xa_alloc_cyclic() call > in simple_offset_add() has a range limit argument of 2 - U32_MAX. > > So I'm not clear how an overflow (or, more precisely, the > reuse of an offset value) would result in a "0" offset being > recorded. The range limit prevents the use of 0 and 1. > > A "0" offset value would be a bug, I agree, but I don't see > how that can happen. > > >>> 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) > > I recall (dimly) that directory entry offset value re-use > is acceptable and preferred, so I think ignoring a "1" > return value from xa_alloc_cyclic() is OK. If there are > no unused offset values available, it will return -EBUSY, > and file creation will fail. > > Perhaps Christian or Al can chime in here on whether > directory entry offset value re-use is indeed expected > to be acceptable. This can't be acceptable in this case, the reason is straightforward, it will mess readdir, and this is mucth more serious than the cve itself. Thanks, Kuai > > Further, my understanding is that: > > https://lore.kernel.org/stable/20241024132225.2271667-12-yukuai1@huaweicloud.com/ > > fixes a rename issue that results in an infinite loop, > and that's the (only) issue that underlies CVE-2024-46701. > > You are suggesting that there are other overflow problems > with the xarray-based simple_offset implementation. If I > can confirm them, then I can get these fixed in v6.6. But > so far, I'm not sure I completely understand these other > failure modes. > > Are you suggesting that the above fix /introduces/ the > 0 offset problem? > > -- > Chuck Lever > >