linux-kernel - Re: [PATCH stable 6.11.y] netfs: reset subreq->iov_iter before netfs_clear

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2024111053-expectant-moodiness-6118@gregkh>
Date: Sun, 10 Nov 2024 06:08:20 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Christian Ebner <c.ebner@...xmox.com>
Cc: dhowells@...hat.com, jlayton@...nel.org, stable@...r.kernel.org,
	netfs@...ts.linux.dev, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH stable 6.11.y] netfs: reset subreq->iov_iter before
 netfs_clear_unread() tail clean

On Thu, Nov 07, 2024 at 12:51:14PM +0100, Christian Ebner wrote:
> On 11/6/24 09:35, Greg KH wrote:
> > On Wed, Nov 06, 2024 at 09:26:46AM +0100, Christian Ebner wrote:
> > 
> > Please try testing the original fixes and providing them as a patch
> > series and send them for us to review.
> > 
> > thanks,
> > 
> > greg k-h
> 
> Hi Greg,
> 
> as mentioned, the original series does not apply on stable-6.11.y and
> securely and correctly back-porting this is out of scope for us, given
> resource and time constraints.

Please note that taking one-off backports to stable trees, increases our
workload over time and almost always is not the correct thing to do as
it diverges code streams.  So while this seems simpler "up front", from
a maintaince point of view, is almost always the wrong thing.

> The main intend was to contribute back a patch which is also back-portable
> to older kernels. This seems unfeasible with the huge original patch series.
> The submitted patch has successfully been tested on our side and fixes the
> issue for affected customers which were willing to test the patch.

That's great, but we really would want the original commits here, OR
approval from the relevant maintainers that "yes, this is really the
only way this can be done for stable trees".

thanks,

greg k-h