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.
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.
Thank you for your time.
Regards, Amir
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
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
op-tee@lists.trustedfirmware.org
-
Amirreza Zarrabi -
Jens Wiklander