[PATCH 6.6 00/28] fix CVE-2024-46701

[Liam R. Howlett]

* Greg KH <gregkh at linuxfoundation.org> [241106 01:16]:
> On Thu, Oct 24, 2024 at 09:19:41PM +0800, Yu Kuai wrote:
> > From: Yu Kuai <yukuai3 at huawei.com>
> > 
> > Fix patch is patch 27, relied patches are from:
> > 
> >  - patches from set [1] to add helpers to maple_tree, the last patch to
> > improve fork() performance is not backported;
> 
> So things slowed down?

Fork got faster in modern kernels.  The backport contains helpers as
they are dependencies for later patches.

> 
> >  - 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.

You reverted and forward ported a patch but didn't Cc the author of the
patch you changed.  That is probably one of the most important Cc's to
have on this list.

By the way, that fix is already in 6.6

> > 
> > (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.

The entire backporting of all of this to fix an issue is extreme, and
although it will solve the issue, you end up running something very
different than 6.6 for a single fix.

Looking at the details of the cve, it seems very odd.  This is an issue
in libfs and the affected kernel is 6.6 to 6.10.7.  It then goes into
details of how the maple tree allows this - but 6.6 doesn't use the
maple tree in libfs so either the patch needs to be backported to an
older stable (6.6) or the CVE is wrong.

Almost all of these patches are to backport using the maple tree in
libfs and that should not be done.

I don't know if the CVE is incorrectly labeled or if the patch wasn't
backported far enough because I was not involved in the discussion of
this CVE - which seems like an oversight if this is specifically caused
by the maple tree?

The patch in question is 64a7ce76fb90 ("libfs: fix infinite directory
reads for offset dir").  I think we just need the one?

To be clear:
 - Do not take this serioes
 - Someone in libfs land should respond stating if the fix above needs
   to be backported.

Thanks,
Liam