Re: [PATCH] mmc: moxart: fix potential use-after-free on remove path.
From: Greg Kroah-Hartman
Date: Mon Mar 09 2026 - 08:32:15 EST
On Mon, Mar 09, 2026 at 12:42:53PM +0100, Ulf Hansson wrote:
> On Sun, 8 Mar 2026 at 19:03, Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Wed, Mar 04, 2026 at 05:25:25PM +0100, Ulf Hansson wrote:
> > > On Mon, 23 Feb 2026 at 14:48, Greg Kroah-Hartman
> > > <gregkh@xxxxxxxxxxxxxxxxxxx> 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.
> > >
> > > mmc_remove_host() doesn't actually free the host, but it reverses what
> > > mmc_add_host() did during probe.
> > >
> > > Since the moxart driver uses devm_mmc_alloc_host() the last reference
> > > to the host will be dropped after ->remove() completes, leading to
> > > mmc_free_host() to be called for it.
> >
> > Then how did commit bd2db32e7c3e ("moxart: fix potential use-after-free
> > on remove path") do anything? It really wasn't needed either? And so
> > the CVE related to it should be rejected?
>
> No, commit bd2db32e7c3e is perfectly okay and solves the intended problem.
>
> Before the moxart driver was converted to use devm_mmc_alloc_host() in
> commit 973aa22b9f1a, it used mmc_alloc_host() during probe.
Ah, that makes more sense, thanks, I was confused.
> Calling mmc_free_host() is needed in these cases, but it should
> typically be the final thing a ->remove() callback does, in order to
> clean up correctly and prevent use-after-free bugs.
I moved the call to be the "final thing" in these patches, so they are
ok?
thanks,
greg k-h