> On Nov 6, 2024, at 1:16 AM, Greg KH <[email protected]> wrote: > > On Thu, Oct 24, 2024 at 09:19:41PM +0800, Yu Kuai wrote: >> From: Yu Kuai <[email protected]> >> >> 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/[email protected]/ 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. 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/[email protected]/ >> [2] >> https://lore.kernel.org/all/[email protected]/T/ >> [3] >> https://lore.kernel.org/all/170820083431.6328.16233178852085891453.st...@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
