Greg Kroah-Hartman wrote on Thu, Jan 09, 2025 at 11:09:38AM +0100:
> On Thu, Jan 09, 2025 at 11:09:02AM +0100, Greg Kroah-Hartman wrote:
> > > Before 74363ec674cb ("zram: fix uninitialized ZRAM not releasing backing
> > > device") that was indeed not a problem so I confirm this is a
> > > regression, even if it is unlikely.
> > > It doesn't look exploitable by unprivileged users anyway so I don't have
> > > any opinion on whether the patches should be held until upstream picks
> > > this latest fix up as well either.
> >
> > Looks like Sasha just dropped the offending commit from the 5.10 and
> > 5.15 queues (but forgot to drop some dep-of patches, I'll go fix that
> > up), so I'll also drop the patch from the 6.1.y queue as well to keep
> > things in sync.
> >
> > If you all want this change to be in 6.1.y (or any other tree), can you
> > provide a working backport, with this patch merged into it?
>
> Oops, nope, this was already in a 6.1.y release, so I'll go apply this
> patch there now. Sorry for the noise...
Thank you! I hadn't even noticed the patch had made it to 6.1.122
earlier, good catch.
So to recap:
- 6.1 is now covered;
- for 5.15/5.10, you suggested squashing this prereq directly into the
74363ec674cb ("zram: fix uninitialized ZRAM not releasing backing
device") backport ; given the patch got merged to 6.1 as is does it
still make sense?
I can resend both patches together as a set if it's become more
preferable.
(... Perhaps adding a tag like [ v6.1 tree commit xyz123 ] even if I
doubt it's standard)
- (for completeness I checked 5.4, 74363ec674cb doesn't apply so I won't
bother)
- I don't think there's any rush for the latest fix[1], so it'll get
picked up through the Fixes tag when it does and I won't wait for it to
resend whichever version.
[1] https://lore.kernel.org/all/20250107065446.86928-1-ryncsn@xxxxxxxxx/
Thanks!
--
Dominique
