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

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

 



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@xxxxxxxxxx wrote:
From: Chuck Lever <chuck.lever@xxxxxxxxxx>

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

--
Chuck Lever




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux