[PATCH] mmc: meson-gx: fix potential use-after-free on remove path.

[PATCH] mmc: meson-gx: fix potential use-after-free on remove path.

[Greg Kroah-Hartman]

Just like in commit bd2db32e7c3e ("moxart: fix potential use-after-free
on remove path"), we should wait until after we are finished writing to
the mmc host device before removing it, otherwise it could have been
already freed.

Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: stable <stable@kernel.org>
Assisted-by: gkh_clanker_2000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/mmc/host/meson-gx-mmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index 694bb443d5f3..9557f6816af3 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -1297,13 +1297,13 @@ static void meson_mmc_remove(struct platform_device *pdev)
 {
 	struct meson_host *host = dev_get_drvdata(&pdev->dev);
 
-	mmc_remove_host(host->mmc);
-
 	/* disable interrupts */
 	writel(0, host->regs + SD_EMMC_IRQ_EN);
 	free_irq(host->irq, host);
 
 	clk_disable_unprepare(host->mmc_clk);
+
+	mmc_remove_host(host->mmc);
 }
 
 static const struct meson_mmc_data meson_gx_data = {
-- 
2.53.0

Re: [PATCH] mmc: meson-gx: fix potential use-after-free on remove path.

[Ulf Hansson]

On Mon, 23 Feb 2026 at 14:49, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> Just like in commit bd2db32e7c3e ("moxart: fix potential use-after-free
> on remove path"), we should wait until after we are finished writing to
> the mmc host device before removing it, otherwise it could have been
> already freed.
>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: stable <stable@kernel.org>
> Assisted-by: gkh_clanker_2000
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  drivers/mmc/host/meson-gx-mmc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index 694bb443d5f3..9557f6816af3 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -1297,13 +1297,13 @@ static void meson_mmc_remove(struct platform_device *pdev)
>  {
>         struct meson_host *host = dev_get_drvdata(&pdev->dev);
>
> -       mmc_remove_host(host->mmc);
> -

No, this is actually correct.

My reply for the other patch to the moxart driver explains why.


>         /* disable interrupts */
>         writel(0, host->regs + SD_EMMC_IRQ_EN);
>         free_irq(host->irq, host);
>
>         clk_disable_unprepare(host->mmc_clk);
> +
> +       mmc_remove_host(host->mmc);
>  }
>
>  static const struct meson_mmc_data meson_gx_data = {
> --
> 2.53.0
>

Kind regards
Uffe

Re: [PATCH] mmc: meson-gx: fix potential use-after-free on remove path.

[Greg Kroah-Hartman]

On Wed, Mar 04, 2026 at 05:29:23PM +0100, Ulf Hansson wrote:
> On Mon, 23 Feb 2026 at 14:49, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > Just like in commit bd2db32e7c3e ("moxart: fix potential use-after-free
> > on remove path"), we should wait until after we are finished writing to
> > the mmc host device before removing it, otherwise it could have been
> > already freed.
> >
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Cc: stable <stable@kernel.org>
> > Assisted-by: gkh_clanker_2000
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> >  drivers/mmc/host/meson-gx-mmc.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> > index 694bb443d5f3..9557f6816af3 100644
> > --- a/drivers/mmc/host/meson-gx-mmc.c
> > +++ b/drivers/mmc/host/meson-gx-mmc.c
> > @@ -1297,13 +1297,13 @@ static void meson_mmc_remove(struct platform_device *pdev)
> >  {
> >         struct meson_host *host = dev_get_drvdata(&pdev->dev);
> >
> > -       mmc_remove_host(host->mmc);
> > -
> 
> No, this is actually correct.
> 
> My reply for the other patch to the moxart driver explains why.

Ok, then the commit above should probably be reverted or at the very
least, have the CVE rejected for it.

thanks,

greg k-h