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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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@linuxfoundation.org> 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@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.
> > >
> > > 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