Re: [PATCH] Revert "libfs: Use d_children list to iterate simple_offset directories"

[Greg Kroah-Hartman]

On Wed, Feb 26, 2025 at 03:33:56PM -0500, Chuck Lever wrote:
> On 2/26/25 2:13 PM, Greg Kroah-Hartman wrote:
> > On Wed, Feb 26, 2025 at 11:28:35AM -0500, Chuck Lever wrote:
> >> On 2/26/25 11:21 AM, Greg Kroah-Hartman wrote:
> >>> On Wed, Feb 26, 2025 at 10:57:48AM -0500, Chuck Lever wrote:
> >>>> On 2/26/25 9:29 AM, Greg Kroah-Hartman wrote:
> >>>>> This reverts commit b9b588f22a0c049a14885399e27625635ae6ef91.
> >>>>>
> >>>>> There are reports of this commit breaking Chrome's rendering mode.  As
> >>>>> no one seems to want to do a root-cause, let's just revert it for now as
> >>>>> it is affecting people using the latest release as well as the stable
> >>>>> kernels that it has been backported to.
> >>>>
> >>>> NACK. This re-introduces a CVE.
> >>>
> >>> As I said elsewhere, when a commit that is assigned a CVE is reverted,
> >>> then the CVE gets revoked.  But I don't see this commit being assigned
> >>> to a CVE, so what CVE specifically are you referring to?
> >>
> >> https://nvd.nist.gov/vuln/detail/CVE-2024-46701
> > 
> > That refers to commit 64a7ce76fb90 ("libfs: fix infinite directory reads
> > for offset dir"), which showed up in 6.11 (and only backported to 6.10.7
> > (which is long end-of-life).  Commit b9b588f22a0c ("libfs: Use
> > d_children list to iterate simple_offset directories") is in 6.14-rc1
> > and has been backported to 6.6.75, 6.12.12, and 6.13.1.
> > 
> > I don't understand the interaction here, sorry.
> 
> Commit 64a7ce76fb90 is an attempt to fix the infinite loop, but can
> not be applied to kernels before 0e4a862174f2 ("libfs: Convert simple
> directory offsets to use a Maple Tree"), even though those kernels also
> suffer from the looping symptoms described in the CVE.
> 
> There was significant controversy (which you responded to) when Yu Kuai
> <yukuai3@xxxxxxxxxx> attempted a backport of 64a7ce76fb90 to address
> this CVE in v6.6 by first applying all upstream mtree patches to v6.6.
> That backport was roundly rejected by Liam and Lorenzo.
> 
> Commit b9b588f22a0c is a second attempt to fix the infinite loop problem
> that does not depend on having a working Maple tree implementation.
> b9b588f22a0c is a fix that can work properly with the older xarray
> mechanism that 0e4a862174f2 replaced, so it can be backported (with
> certain adjustments) to kernels before 0e4a862174f2.
> 
> Note that as part of the series where b9b588f22a0c was applied,
> 64a7ce76fb90 is reverted (v6.10 and forward). Reverting b9b588f22a0c
> leaves LTS kernels from v6.6 forward with the infinite loop problem
> unfixed entirely because 64a7ce76fb90 has also now been reverted.
> 
> 
> >> The guideline that "regressions are more important than CVEs" is
> >> interesting. I hadn't heard that before.
> > 
> > CVEs should not be relevant for development given that we create 10-11
> > of them a day.  Treat them like any other public bug list please.
> > 
> > But again, I don't understand how reverting this commit relates to the
> > CVE id you pointed at, what am I missing?
> > 
> >> Still, it seems like we haven't had a chance to actually work on this
> >> issue yet. It could be corrected by a simple fix. Reverting seems
> >> premature to me.
> > 
> > I'll let that be up to the vfs maintainers, but I'd push for reverting
> > first to fix the regression and then taking the time to find the real
> > change going forward to make our user's lives easier.  Especially as I
> > don't know who is working on that "simple fix" :)
> 
> The issue is that we need the Chrome team to tell us what new system
> behavior is causing Chrome to malfunction. None of us have expertise to
> examine as complex an application as Chrome to nail the one small change
> that is causing the problem. This could even be a latent bug in Chrome.
> 
> As soon as they have reviewed the bug and provided a simple reproducer,
> I will start active triage.

What ever happened with all of this?

thanks,

greg k-h