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?
thanks,
greg k-h
