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

[Chuck Lever <chuck.lever@oracle.com>]

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.


> 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.


-- 
Chuck Lever