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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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.

> 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" :)

thanks,

greg k-h