Re: [PATCH RFC 10/12] remoteproc: imx_rproc: always use non-blocking mailboxes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] remoteproc: stack use-after-free in imx_rproc_kick() due to non-blocking mailbox
--

commit c47129240ff337ab849e03d40342b679177d2bcf
Author: Francesco Valla <francesco@valla.it>

remoteproc: imx_rproc: always use non-blocking mailboxes

This commit changes the imx_rproc mailbox to non-blocking mode to prevent
sleeping during kick operations, aligning the behavior with other remoteproc
drivers. It also removes the close-reopen action on the mailboxes during
restart and shutdown.

> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 745ce52cd8226..100440328f92e 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
[ ... ]
> @@ -877,7 +877,7 @@ static void imx_rproc_rx_callback(struct mbox_client *cl, void *msg)
>  	queue_work(priv->workqueue, &priv->rproc_work);
>  }
>  
> -static int imx_rproc_xtr_mbox_init(struct rproc *rproc, bool tx_block)
> +static int imx_rproc_xtr_mbox_init(struct rproc *rproc)
>  {
>  	struct imx_rproc *priv = rproc->priv;
>  	struct device *dev = priv->dev;
> @@ -900,7 +900,7 @@ static int imx_rproc_xtr_mbox_init(struct rproc *rproc, bool tx_block)
>  
>  	cl = &priv->cl;
>  	cl->dev = dev;
> -	cl->tx_block = tx_block;
> +	cl->tx_block = false;

[Severity: High]
With the mailbox permanently changed to asynchronous/non-blocking mode,
mbox_send_message() will now return immediately without waiting for
transmission to complete.

Does this cause a stack use-after-free when the remote processor is kicked?
Looking at imx_rproc_kick():

static void imx_rproc_kick(struct rproc *rproc, int vqid)
{
	...
	__u32 mmsg;
	...
	mmsg = vqid << 16;
	err = mbox_send_message(priv->tx_ch, (void *)&mmsg);
	...
}

Because mmsg is allocated on the stack, queuing its pointer for asynchronous
transmission means the mailbox framework could dereference the pointer and
read garbage from the destroyed stack frame after imx_rproc_kick() returns.
This could crash the remote core or disrupt IPC.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916-remoteproc_virtio_map-v1-0-dac8c5eb4aa9@valla.it?part=10