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

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

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.

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.

Thank you, Greg, for your time.


-- 
Chuck Lever