Re: [PATCH v2 1/3] EDAC/versalnet: Fix teardown ordering in mc_remove()

[Borislav Petkov]

On Thu, Apr 09, 2026 at 03:03:29PM +0530, Prasanna Kumar T S M wrote:
> Sashiko review says
> -------------------
> If an MCDI response message arrives after priv->mcdi is freed but before the
> RPMSG endpoint is destroyed, could the still-active rpmsg_cb() pass the
> dangling priv->mcdi pointer to cdx_mcdi_process_cmd(), leading to a
> use-after-free?
> -------------------

Sashiko says:

"If an error message or MCDI response arrives from the remote processor during
this race window, rpmsg_cb() will execute concurrently. When processing an
error, it calls handle_error(), which dereferences the memory controllers
already freed by edac_mc_free() in remove_versalnet()."

IOW, handle_error() does:

	mci = priv->mci[ctl_num];

however, remove_versalnet() has *done* *already*:

        mci = priv->mci[i];
        device_unregister(mci->pdev);
        edac_mc_del_mc(mci->pdev);
        edac_mc_free(mci);

How is that a false positive if you change the teardown sequence to:

  remove_versalnet
  cdx_mcdi_finish
  unregister_rpmsg_driver
  rproc_shutdown
  rproc_put

?

IOW, the proper fix in all this gunk of unwinding sequences is to *prevent*
the hw from sending *any* more messages before you start tearing down things.

I'd leave that to Shubhrajyoti to figure out how to do properly.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette