Hi Christian, Thank you for the review and for catching this. You are absolutely right, and my analysis was flawed. Adding the lock inside `drm_prime_remove_buf_handle` would indeed cause a recursive deadlock.
The syzkaller crash was originally triggered on the v6.18 kernel. When investigating, I checked the latest mainline source for `drm_prime_remove_buf_handle` itself. Since I didn't see any synchronization changes within that specific function, I incorrectly assumed the concurrency issue was still completely unhandled, failing to notice that the upstream tree properly holds the lock in the caller (`drm_gem_object_release_handle`). I will dive deeper into the code to see if there is still any hidden race condition under the current locking scheme, or if this is strictly a legacy issue that might only require a stable-tree backport. If a fix is still warranted, I will send a v2 patch. Thanks again for your time and guidance! Best regards, Mingyu Wang
