Executive brief
A deadlock condition in the Linux kernel's rpmsg glink subsystem can cause driver unloading to hang indefinitely. When rpmsg devices are unloaded, the endpoint destroy implementation attempts to re-acquire a mutex already held by the device core, causing the system to deadlock. This prevents proper cleanup during driver detach operations, affecting systems that rely on rpmsg communication.
Technical details
The vulnerability is a deadlock triggered during rpmsg endpoint destruction in the glink driver. The root cause is a redundant device_unregister() call within qcom_glink_destroy_ept() that attempts to unregister the rpmsg device while the device core already holds the device mutex. During driver detach, device_release_driver_internal() acquires the mutex, then the endpoint destroy code attempts to acquire the same mutex via device_del(), causing a deadlock. The attack vector is local (requires module unload) and affects the driver detach path. The fix is to remove the redundant unregistration since the device core already tears down the rpmsg device during both driver detach and channel close scenarios.
Affected products
- Linux Linux kernel all versions with rpmsg glink support
Timeline
- 2026-09-17: disclosed