[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZyzRsR9rMQeIaIkM@tissot.1015granger.net>
Date: Thu, 7 Nov 2024 09:41:53 -0500
From: Chuck Lever <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 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.
- 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@bytedance.com/
> > > > [2] https://lore.kernel.org/all/20231101171629.3612299-2-Liam.Howlett@oracle.com/T/
> > > > [3] https://lore.kernel.org/all/170820083431.6328.16233178852085891453.stgit@91.116.238.104.host.secureserver.net/
> > >
> > > 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
Powered by blists - more mailing lists