On Thu, Jan 09, 2025 at 11:09:02AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 07, 2025 at 04:16:04PM +0900, Dominique Martinet wrote:
> > This is a pre-requisite for the backport of commit 74363ec674cb ("zram:
> > fix uninitialized ZRAM not releasing backing device"), which has been
> > implemented differently in commit 7ac07a26dea7 ("zram: preparation for
> > multi-zcomp support") upstream.
> >
> > We only need to ensure that zcomp_destroy is not called with a NULL
> > comp, so add this check as the other commit cannot be backported easily.
> >
> > Stable-dep-of: 74363ec674cb ("zram: fix uninitialized ZRAM not releasing backing device")
> > Link: https://lore.kernel.org/Z3ytcILx4S1v_ueJ@xxxxxxxxxxxxx
> > Suggested-by: Kairui Song <kasong@xxxxxxxxxxx>
> > Signed-off-by: Dominique Martinet <dominique.martinet@xxxxxxxxxxxxxxxxx>
> > ---
> > This is the fix suggested by kasong in reply to my report (his mail
> > didn't make it to lkml because of client sending html)
> >
> > This applies cleanly on all 3 branches, and I've tested it works
> > properly on 5.10 (e.g. I can allocate and free zram devices fine)
> >
> > I have no preference on which way forward is taken, the problematic
> > patch can be dropped for a cycle while this is sorted out...
> >
> >
> > Also, Kasong pointed to another issue he sent a patch for just now:
> > https://lore.kernel.org/all/20250107065446.86928-1-ryncsn@xxxxxxxxx/
> >
> > 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...
greg k-h
