Message-ID: <D2A4C13B-3B50-4BA7-A5CC-C16E98944D55@oracle.com>
Date: Fri, 8 Nov 2024 13:23:23 +0000
From: Chuck Lever III <chuck.lever@...cle.com>
To: Yu Kuai <yukuai1@...weicloud.com>
CC: Greg KH <gregkh@...uxfoundation.org>,
        linux-stable
	<stable@...r.kernel.org>,
        "harry.wentland@....com" <harry.wentland@....com>,
        "sunpeng.li@....com" <sunpeng.li@....com>,
        "Rodrigo.Siqueira@....com"
	<Rodrigo.Siqueira@....com>,
        "alexander.deucher@....com"
	<alexander.deucher@....com>,
        "christian.koenig@....com"
	<christian.koenig@....com>,
        "Xinhui.Pan@....com" <Xinhui.Pan@....com>,
        "airlied@...il.com" <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>, Al
 Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        Liam
 Howlett <liam.howlett@...cle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Hugh Dickins <hughd@...gle.com>,
        "Matthew Wilcox (Oracle)"
	<willy@...radead.org>,
        Sasha Levin <sashal@...nel.org>,
        "srinivasan.shanmugam@....com" <srinivasan.shanmugam@....com>,
        "chiahsuan.chung@....com" <chiahsuan.chung@....com>,
        "mingo@...nel.org"
	<mingo@...nel.org>,
        "mgorman@...hsingularity.net"
	<mgorman@...hsingularity.net>,
        "chengming.zhou@...ux.dev"
	<chengming.zhou@...ux.dev>,
        "zhangpeng.00@...edance.com"
	<zhangpeng.00@...edance.com>,
        "amd-gfx@...ts.freedesktop.org"
	<amd-gfx@...ts.freedesktop.org>,
        "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List
	<linux-kernel@...r.kernel.org>,
        Linux FS Devel
	<linux-fsdevel@...r.kernel.org>,
        "maple-tree@...ts.infradead.org"
	<maple-tree@...ts.infradead.org>,
        linux-mm <linux-mm@...ck.org>,
        "yi.zhang@...wei.com" <yi.zhang@...wei.com>,
        yangerkun
	<yangerkun@...wei.com>, "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH 6.6 00/28] fix CVE-2024-46701



> On Nov 7, 2024, at 8:19 PM, Yu Kuai <yukuai1@...weicloud.com> 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 <gregkh@...uxfoundation.org> wrote:
>>>>> 
>>>>> On Thu, Oct 24, 2024 at 09:19:41PM +0800, Yu Kuai wrote:
>>>>>> From: Yu Kuai <yukuai3@...wei.com>
>>>>>> 
>>>>>> 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.


--
Chuck Lever

Powered by blists - more mailing lists