Hi Jens,
Thanks. Sent a patch. Not tested, just wanted to confirm you are ok with it :).
Regards, Amir
On 6/2/2025 11:07 PM, Jens Wiklander wrote:
Hi Amir,
On Thu, May 29, 2025 at 1:47 AM Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com wrote:
Hi Jens, Sumit,
The following change has recently been merged: tee: optee: Fix supplicant wait loop (https://github.com/torvalds/linux/commit/70b0d6b0a199c5a3ee6c72f5e61681ed6f7...).
This fix addresses the issue where the supplicant may terminate before the client due to the shutdown sequence or a crash. However, it introduces a potential new issue - now that the client is killable, what happens if it terminates before the supplicant?
During cleanup, the client would remove/free the request, while the request would still be available in the request idr for the supplicant. Although I have not been able to reproduce it, this could theoretically result in a kernel page fault.
You're right, a use-after-free is possible.
To address this, there are a few options: (1) Use rcu and access request under a read lock in optee_supp_recv and optee_supp_send. (2) Reuse supp->mutex, ensuring that most of these functions run within the lock, even though it may not always be necessary.
Could you confirm whether this behavior was intentional? If not, I am happy to prepare a patch. Additionally, please let me know whether you prefer solution (1) or (2), or if you have any other suggestions.
A patch to fix this is welcome. I generally prefer a less complicated alternative, so if possible, please avoid RCU.
Cheers, Jens
Thank you for your time.
Regards, Amir