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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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






[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux