Re: [PATCH v5 2/3] misc: fastrpc: move ADSP duplicate session creation to the driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] misc: fastrpc: duplicated ADSP sessions leak due to probe race condition
--

commit 6af4cd918024ca72389e7e81cea29baaabd3588c
Author: Vinayak Katoch <vinayak.katoch@oss.qualcomm.com>

misc: fastrpc: move ADSP duplicate session creation to the driver

This commit removes the qcom,nsessions DT property read from
fastrpc_cb_init() and stops duplicating sessions at the context bank level.
Instead, it adds a fixed loop in fastrpc_rpmsg_probe() that duplicates the
last ADSP session FASTRPC_DUP_SESSIONS times.

> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index f20d3e5ecc81f..b29c1fd00de28 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c

> [ ... ]

> @@ -2669,6 +2658,22 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
>  	if (err)
>  		goto err_deregister_fdev;
>  
> +	if (data->domain_id == ADSP_DOMAIN_ID && data->sesscount > 0) {
> +		struct fastrpc_session_ctx *last_sess;
> +		struct fastrpc_session_ctx *dup_sess;
> +		unsigned long flags;
> +
> +		spin_lock_irqsave(&data->lock, flags);
> +		last_sess = &data->session[data->sesscount - 1];
> +		for (i = 0; i < FASTRPC_DUP_SESSIONS; i++) {
> +			if (data->sesscount >= FASTRPC_MAX_SESSIONS)
> +				break;
> +			dup_sess = &data->session[data->sesscount++];
> +			memcpy(dup_sess, last_sess, sizeof(*dup_sess));

[Severity: Medium]
Can this sequence result in leaked duplicate sessions?

Looking at fastrpc_rpmsg_probe(), the misc device is registered via
fastrpc_device_register() and exposed to userspace before we reach this loop.

If a concurrent userspace application calls open() and triggers
fastrpc_session_alloc(), it could mark the last session's used flag as true.

Since this loop uses memcpy() to duplicate last_sess, wouldn't it blindly
copy the used = true state into all the newly created duplicate sessions?

If so, these duplicates would be permanently marked as in-use without being
assigned to an active user context, causing them to leak and remain
permanently unavailable.

> +		}
> +		spin_unlock_irqrestore(&data->lock, flags);
> +	}
> +
>  	return 0;
>  
>  err_deregister_fdev:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923-dup-sessions-v5-0-e953133a1827@oss.qualcomm.com?part=2