[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2026012641-snazzy-upstate-a815@gregkh>
Date: Mon, 26 Jan 2026 16:24:18 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Xingjing Deng <micro6947@...il.com>
Cc: srini@...nel.org, amahesh@....qualcomm.com, arnd@...db.de,
dri-devel@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, Xingjing Deng <xjdeng@...a.edu.cn>,
stable@...r.kernel.org
Subject: Re: [PATCH v3] misc: fastrpc: possible double-free of
cctx->remote_heap
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@...r.kernel.org # 6.2+
> Signed-off-by: Xingjing Deng <xjdeng@...a.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@...r.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
Powered by blists - more mailing lists