Re: [PATCH RFC v3 9/9] tee: optee: support RPMI asynchronous notification doorbells

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] tee: optee: race between async notif callback and teardown causes UAF/NULL deref
--

commit fbdb2da759a2fc5e6692fd4d211f0b6f63644339
Author: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>

tee: optee: support RPMI asynchronous notification doorbells

This commit introduces support for RPMI asynchronous notification doorbells
in OP-TEE. It allocates a TEE-to-REE RPMI signal, passes it to OP-TEE, and
queues bottom-half processing on a private workqueue. It also adds teardown
logic to stop asynchronous notifications and drain the workqueue upon
cleanup.

> diff --git a/drivers/tee/optee/rpmi_abi.c b/drivers/tee/optee/rpmi_abi.c
> index 0ed2de96758e2..6434767a22497 100644
> --- a/drivers/tee/optee/rpmi_abi.c
> +++ b/drivers/tee/optee/rpmi_abi.c

[ ... ]

> +static void optee_rpmi_notif_callback(struct rpmi_tee_device *rdev, u32 signal,
> +				      void *cb_data)
> +{
> +	struct optee *optee = cb_data;
> +
> +	queue_work(optee->rpmi.notif_wq, &optee->rpmi.notif_work);
> +}
> +
> +/* Relinquish is not a barrier for an already-selected transport callback. */
> +static void optee_rpmi_async_notif_uninit(struct optee *optee)
> +{
> +	struct optee_rpmi *rpmi = &optee->rpmi;
> +	struct rpmi_tee_device *rdev = rpmi->rdev;
> +	int rc;
> +
> +	if (!rpmi->notif_wq)
> +		return;
> +
> +	rc = optee_stop_async_notif(optee->ctx);
> +	if (rc)
> +		dev_warn(&rdev->dev, "stop notifications failed: %d\n", rc);
> +
> +	rc = rdev->ops->notifier_ops->notify_relinquish(rdev, rpmi->signal);
> +	if (rc && rc != -EOPNOTSUPP)
> +		dev_warn(&rdev->dev,
> +			 "relinquish notification failed: %d\n", rc);
> +
> +	destroy_workqueue(rpmi->notif_wq);
> +
> +	rpmi->notif_wq = NULL;
> +}

[Severity: High]
Can an in-flight RPMI notification invoke optee_rpmi_notif_callback()
concurrently with or after this teardown process?

As the comment mentions, notify_relinquish() is not a barrier for an
already-selected transport callback. If the callback runs concurrently,
queue_work() accesses the workqueue without locking. This can cause a
use-after-free if destroy_workqueue() is executing, or a NULL pointer
dereference if rpmi->notif_wq has already been set to NULL.

Furthermore, if the callback execution is delayed until after
optee_rpmi_remove() completes, the optee structure itself is freed
via kfree(optee), which would lead to a use-after-free when the callback
dereferences optee->rpmi.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261012-rpmi-tee-service-grp-dev-v3-0-975b574667e2@oss.qualcomm.com?part=9