Re: [PATCH 5.4 058/194] mtd: Fix gluebi NULL pointer dereference caused by ftl notifier

[Zhihao Cheng]

在 2024/2/9 15:09, Martin Kepplinger-Novakovic 写道:
> Am Montag, dem 22.01.2024 um 15:56 -0800 schrieb Greg Kroah-Hartman:
> > 5.4-stable review patch.  If anyone has any objections, please let me
> > know.
> >
> > ------------------
> >
> > From: ZhaoLong Wang <wangzhaolong1@xxxxxxxxxx>
> >
> > [ Upstream commit a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6 ]

[...]

> > diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
> > index 0c05f77f9b21..dd0d0bf5f57f 100644
> > --- a/drivers/mtd/mtd_blkdevs.c
> > +++ b/drivers/mtd/mtd_blkdevs.c
> > @@ -533,7 +533,7 @@ static void blktrans_notify_add(struct mtd_info
> > *mtd)
> >   {
> >          struct mtd_blktrans_ops *tr;
> >   
> > -       if (mtd->type == MTD_ABSENT)
> > +       if (mtd->type == MTD_ABSENT || mtd->type == MTD_UBIVOLUME)
> >                  return;
> >   
> >          list_for_each_entry(tr, &blktrans_majors, list)
> > @@ -576,7 +576,7 @@ int register_mtd_blktrans(struct mtd_blktrans_ops
> > *tr)
> >          list_add(&tr->list, &blktrans_majors);
> >   
> >          mtd_for_each_device(mtd)
> > -               if (mtd->type != MTD_ABSENT)
> > +               if (mtd->type != MTD_ABSENT && mtd->type !=
> > MTD_UBIVOLUME)
> >                          tr->add_mtd(tr, mtd);
> >   
> >          mutex_unlock(&mtd_table_mutex);
>
> Hi Greg, hi patch-developers,
>
> wait a second. this already went into v5.4.268 but still: Doesn't this
> break userspace?
>
> According to
> https://lore.kernel.org/lkml/441107100.23734.1697904580252.JavaMail.zimbra@xxxxxx/
> where this solution seems to come from, the behaviour changes: "no
> mtdblock (hence, also no FTLs) on top of gluebi."
>
> I fell accross this because of an out-of-tree module that does
> sys_mount() an mtdblock, so I won't complain about my code specifically
> :) But doesn't it break mounting, say, jffs2 inside an ubi via
> mtdblock? If so, is this really something that you want to see
> backported to old kernels?
>
> Or differently put: Has this patch been picked up for old stable
> kernels by scripts or by a human?
>
> I just want to make sure, and who knows, it might help others too, who
> would just do a (possibly dangerous?) revert in their trees.

This change does affect the mounting(mtdblock based on gluebi) behavior 
in userspace. It was picked into stable versions because the fixed 
problem is serious and easy to be reproduced, I guess.
A temporary solution is that modify mounting source target in userspace, 
just replace mtdblock with mtd char device. For example, mount -t jffs2 
mtd0 /mnt