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@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Thu, Oct 24, 2024 at 09:19:41PM +0800, Yu Kuai wrote: > > > > From: Yu Kuai <yukuai3@xxxxxxxxxx> > > > > > > > > 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@xxxxxxxxxxxxxxx/ > > > > 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. - The offset values are dense, so the directory can use all 2- or 4- billion in the 32-bit integer range before wrapping. - 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! > Thanks, > Kuai > > > > > This is the first I've heard of this CVE. It > > would help if the patch authors got some > > notification when these are filed. > > > > > > > > - patches from set [1] to add helpers to maple_tree, the last patch to > > > > improve fork() performance is not backported; > > > > > > So things slowed down? > > > > > > > - patches from set [2] to change maple_tree, and follow up fixes; > > > > - patches from set [3] to convert offset_ctx from xarray to maple_tree; > > > > > > > > Please notice that I'm not an expert in this area, and I'm afraid to > > > > make manual changes. That's why patch 16 revert the commit that is > > > > different from mainline and will cause conflict backporting new patches. > > > > patch 28 pick the original mainline patch again. > > > > > > > > (And this is what we did to fix the CVE in downstream kernels). > > > > > > > > [1] https://lore.kernel.org/all/20231027033845.90608-1-zhangpeng.00@xxxxxxxxxxxxx/ > > > > [2] https://lore.kernel.org/all/20231101171629.3612299-2-Liam.Howlett@xxxxxxxxxx/T/ > > > > [3] https://lore.kernel.org/all/170820083431.6328.16233178852085891453.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > > > > > This series looks rough. I want to have the maintainers of these > > > files/subsystems to ack this before being able to take them. > > > > > > thanks, > > > > > > greg k-h > > > > -- > > Chuck Lever > > > > > -- Chuck Lever
