fastrpc_init_create_static_process() may free cctx->remote_heap on the
err_map path but does not clear the pointer. Later, fastrpc_rpmsg_remove()
frees cctx->remote_heap again if it is non-NULL, which can lead to a
double-free if the INIT_CREATE_STATIC ioctl hits the error path and the rpmsg
device is subsequently removed/unbound.
Clear cctx->remote_heap after freeing it in the error path to prevent the
later cleanup from freeing it again.

Fixes: 0871561055e66 ("misc: fastrpc: Add support for audiopd")
Cc: stable@vger.kernel.org # 6.2+
Signed-off-by: Xingjing Deng <xjdeng@buaa.edu.cn>

---

v3:
- Adjust the email format.
- Link to v2: https://lore.kernel.org/linux-arm-msm/2026011650-gravitate-happily-5d0c@gregkh/T/#t

v2:
- Add Fixes: and Cc: stable@vger.kernel.org.
- Link to v1: https://lore.kernel.org/linux-arm-msm/2026011227-casualty-rephrase-9381@gregkh/T/#t

 drivers/misc/fastrpc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index ee652ef01534..fb3b54e05928 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -1370,6 +1370,7 @@ static int fastrpc_init_create_static_process(struct fastrpc_user *fl,
 	}
 err_map:
 	fastrpc_buf_free(fl->cctx->remote_heap);
+	fl->cctx->remote_heap = NULL;
 err_name:
 	kfree(name);
 err:
-- 
2.25.1

On Sat, Jan 17, 2026 at 10:09:59PM +0800, Xingjing Deng wrote:
> fastrpc_init_create_static_process() may free cctx->remote_heap on the
> err_map path but does not clear the pointer. Later, fastrpc_rpmsg_remove()
> frees cctx->remote_heap again if it is non-NULL, which can lead to a
> double-free if the INIT_CREATE_STATIC ioctl hits the error path and the rpmsg
> device is subsequently removed/unbound.
> Clear cctx->remote_heap after freeing it in the error path to prevent the
> later cleanup from freeing it again.
> 
> Fixes: 0871561055e66 ("misc: fastrpc: Add support for audiopd")
> Cc: stable@vger.kernel.org # 6.2+
> Signed-off-by: Xingjing Deng <xjdeng@buaa.edu.cn>
> 
> ---
> 
> v3:
> - Adjust the email format.
> - Link to v2: https://lore.kernel.org/linux-arm-msm/2026011650-gravitate-happily-5d0c@gregkh/T/#t
> 
> v2:
> - Add Fixes: and Cc: stable@vger.kernel.org.
> - Link to v1: https://lore.kernel.org/linux-arm-msm/2026011227-casualty-rephrase-9381@gregkh/T/#t
> 
>  drivers/misc/fastrpc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index ee652ef01534..fb3b54e05928 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
> @@ -1370,6 +1370,7 @@ static int fastrpc_init_create_static_process(struct fastrpc_user *fl,
>  	}
>  err_map:
>  	fastrpc_buf_free(fl->cctx->remote_heap);
> +	fl->cctx->remote_heap = NULL;
>  err_name:
>  	kfree(name);
>  err:
> -- 
> 2.25.1
> 
> 

How was this found and tested?

And randomly setting a pointer to null doesn't really document what is
happening here, what would you want to see here if you were to look at
this code in 5 years?

thanks,

greg k-h

This issue was also identified through static program analysis and
subsequently verified via manual inspection. I believe I have
uncovered a potential risk of abnormal execution here, hence I’m
reporting this problem.

Greg KH <gregkh@linuxfoundation.org> 于2026年1月26日周一 23:24写道：
>
> On Sat, Jan 17, 2026 at 10:09:59PM +0800, Xingjing Deng wrote:
> > fastrpc_init_create_static_process() may free cctx->remote_heap on the
> > err_map path but does not clear the pointer. Later, fastrpc_rpmsg_remove()
> > frees cctx->remote_heap again if it is non-NULL, which can lead to a
> > double-free if the INIT_CREATE_STATIC ioctl hits the error path and the rpmsg
> > device is subsequently removed/unbound.
> > Clear cctx->remote_heap after freeing it in the error path to prevent the
> > later cleanup from freeing it again.
> >
> > Fixes: 0871561055e66 ("misc: fastrpc: Add support for audiopd")
> > Cc: stable@vger.kernel.org # 6.2+
> > Signed-off-by: Xingjing Deng <xjdeng@buaa.edu.cn>
> >
> > ---
> >
> > v3:
> > - Adjust the email format.
> > - Link to v2: https://lore.kernel.org/linux-arm-msm/2026011650-gravitate-happily-5d0c@gregkh/T/#t
> >
> > v2:
> > - Add Fixes: and Cc: stable@vger.kernel.org.
> > - Link to v1: https://lore.kernel.org/linux-arm-msm/2026011227-casualty-rephrase-9381@gregkh/T/#t
> >
> >  drivers/misc/fastrpc.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> > index ee652ef01534..fb3b54e05928 100644
> > --- a/drivers/misc/fastrpc.c
> > +++ b/drivers/misc/fastrpc.c
> > @@ -1370,6 +1370,7 @@ static int fastrpc_init_create_static_process(struct fastrpc_user *fl,
> >       }
> >  err_map:
> >       fastrpc_buf_free(fl->cctx->remote_heap);
> > +     fl->cctx->remote_heap = NULL;
> >  err_name:
> >       kfree(name);
> >  err:
> > --
> > 2.25.1
> >
> >
>
> How was this found and tested?
>
> And randomly setting a pointer to null doesn't really document what is
> happening here, what would you want to see here if you were to look at
> this code in 5 years?
>
> thanks,
>
> greg k-h

On Tue, Jan 27, 2026 at 10:19:50AM +0800, Xingjing Deng wrote:
> This issue was also identified through static program analysis and
> subsequently verified via manual inspection. I believe I have
> uncovered a potential risk of abnormal execution here, hence I’m
> reporting this problem.

Again, you need to document this fact, please read the rules for
submitting patches that are found by tools.  And say you have not tested
this, because that means there is a much lower chance that the change is
correct.

thanks,

greg k-h