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 <[email protected]> 于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: [email protected] # 6.2+ > > Signed-off-by: Xingjing Deng <[email protected]> > > > > --- > > > > 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: [email protected]. > > - 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
