Re: [RFC PATCH v6.6 00/10] Address CVE-2024-46701

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

On Thu, Jan 30, 2025 at 09:02:41AM -0500, Chuck Lever wrote:
> On 1/30/25 3:45 AM, Greg Kroah-Hartman wrote:
> > On Wed, Jan 29, 2025 at 11:37:51AM -0500, Chuck Lever wrote:
> >> On 1/29/25 10:21 AM, Greg Kroah-Hartman wrote:
> >>> On Wed, Jan 29, 2025 at 10:06:49AM -0500, Chuck Lever wrote:
> >>>> On 1/29/25 9:50 AM, Greg Kroah-Hartman wrote:
> >>>>> On Wed, Jan 29, 2025 at 08:55:15AM -0500, Chuck Lever wrote:
> >>>>>> On 1/24/25 2:19 PM, cel@kernel.org wrote:
> >>>>>>> From: Chuck Lever <chuck.lever@oracle.com>
> >>>>>>>
> >>>>>>> This series backports several upstream fixes to origin/linux-6.6.y
> >>>>>>> in order to address CVE-2024-46701:
> >>>>>>>
> >>>>>>>      https://nvd.nist.gov/vuln/detail/CVE-2024-46701
> >>>>>>>
> >>>>>>> As applied to origin/linux-6.6.y, this series passes fstests and the
> >>>>>>> git regression suite.
> >>>>>>>
> >>>>>>> Before officially requesting that stable@ merge this series, I'd
> >>>>>>> like to provide an opportunity for community review of the backport
> >>>>>>> patches.
> >>>>>>>
> >>>>>>> You can also find them them in the "nfsd-6.6.y" branch in
> >>>>>>>
> >>>>>>>      https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
> >>>>>>>
> >>>>>>> Chuck Lever (10):
> >>>>>>>      libfs: Re-arrange locking in offset_iterate_dir()
> >>>>>>>      libfs: Define a minimum directory offset
> >>>>>>>      libfs: Add simple_offset_empty()
> >>>>>>>      libfs: Fix simple_offset_rename_exchange()
> >>>>>>>      libfs: Add simple_offset_rename() API
> >>>>>>>      shmem: Fix shmem_rename2()
> >>>>>>>      libfs: Return ENOSPC when the directory offset range is exhausted
> >>>>>>>      Revert "libfs: Add simple_offset_empty()"
> >>>>>>>      libfs: Replace simple_offset end-of-directory detection
> >>>>>>>      libfs: Use d_children list to iterate simple_offset directories
> >>>>>>>
> >>>>>>>     fs/libfs.c         | 177 +++++++++++++++++++++++++++++++++------------
> >>>>>>>     include/linux/fs.h |   2 +
> >>>>>>>     mm/shmem.c         |   3 +-
> >>>>>>>     3 files changed, 134 insertions(+), 48 deletions(-)
> >>>>>>>
> >>>>>>
> >>>>>> I've heard no objections or other comments. Greg, Sasha, shall we
> >>>>>> proceed with merging this patch series into v6.6 ?
> >>>>>
> >>>>> Um, but not all of these are in a released kernel yet, so we can't take
> >>>>> them all yet.
> >>>>
> >>>> Hi Greg -
> >>>>
> >>>> The new patches are in v6.14 now. I'm asking stable to take these
> >>>> whenever you are ready. Would that be v6.14-rc1? I can send a reminder
> >>>> if you like.
> >>>
> >>> Yes, we have to wait until changes are in a -rc release unless there are
> >>> "real reasons to take it now" :)
> >>>
> >>>>> Also what about 6.12.y and 6.13.y for those commits that
> >>>>> will be showing up in 6.14-rc1?  We can't have regressions for people
> >>>>> moving to those releases from 6.6.y, right?
> >>>>
> >>>> The upstream commits have Fixes tags. I assumed that your automation
> >>>> will find those and apply them to those kernels -- the upstream versions
> >>>> of these patches I expect will apply cleanly to recent LTS.
> >>>
> >>> "Fixes:" are never guaranteed to show up in stable kernels, they are
> >>> only a "maybe when we get some spare cycles and get around to it we
> >>> might do a simple pass to see what works or doesn't."
> >>>
> >>> If you KNOW a change is a bugfix for stable kernels, please mark it as
> >>> such!  "Fixes:" is NOT how to do that, and never has been.  It's only
> >>> additional meta-data that helps us out.
> >>>
> >>> So please send us a list of the commits that need to go to 6.12.y and
> >>> 6.13.y, we have to have that before we could take the 6.6.y changes.
> >>
> >> 903dc9c43a15 ("libfs: Return ENOSPC when the directory offset range is
> >> exhausted")
> >> d7bde4f27cee ("Revert "libfs: Add simple_offset_empty()"")
> >> b662d858131d ("Revert "libfs: fix infinite directory reads for offset dir"")
> >> 68a3a6500314 ("libfs: Replace simple_offset end-of-directory detection")
> >> b9b588f22a0c ("libfs: Use d_children list to iterate simple_offset
> >> directories")
> > 
> > Cool, thanks for the list (and not all were marked with fixes, i.e.
> > those reverts, I guess we need to start checking for reverts better.  I
> > have tooling set up for that but not integrated yet...)
> > 
> > I'll just queue them all up now.
> 
> My thinking was the patches marked "Fixes:" would show an obvious need
> for applying the unmarked patches as pre-requisites first.

For when you send us a patch series for inclusion, sure, all is fine.  I
mean for when you merge stuff to Linus and expect us to pick them up.

> I promise to do better marking patches with "Cc: stable". But also let
> me know if there's a way to label pre-req patches more clearly. Maybe
> "Cc: stable" without "Fixes:" is the way to go there.

Both is best, that way if you have a Fixes: tag in it, and a patch does
not apply properly, you will get a "FAILED" email sent to you.  If you
only have the cc: stable then we just do a best-effort attempt and stop
backporting when it doesn't apply and don't notify you at all about any
failures.

thanks,

greg k-h