CVE-2026-93098 in Linux
Zusammenfassung
von VulDB • 18.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
rpmsg: glink: Behebung einer Deadlock-Situation beim Zerstören des Endpunkts während der Treiber-Entkopplung (driver detach)
Während der Treiber-Entkopplung hält das Device-Core den Device-Mutex über die gesamte Kette der remove-Callbacks des Treibers. Wenn der rpmsg-Endpunkt im Rahmen dieser Teardown-Prozedur zerstört wird, versucht die Implementierung zum Zerstören des GLINK-Endpunkts, das zugrunde liegende rpmsg-Gerät zu deregistrieren. Diese Deinstallation ruft device_del() auf, welches erneut denselben Device-Mutex erwerben will, der bereits weiter oben im Stack gehalten wird, was dazu führt, dass rmmod unendlich lange hängt (hängen bleibt).
Der Deadlock manifestiert sich mit der folgenden Aufrufliste:
[<0>] device_del+0x44/0x414 <- versucht denselben Mutex zu erwerben
[<0>] device_unregister+0x18/0x34
[<0>] rpmsg_unregister_device+0x28/0x4c
[<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0
[<0>] qcom_glink_destroy_ept+0x58/0xbc
[<0>] rpmsg_dev_remove+0x50/0x60
[<0>] device_remove+0x4c/0x80
[<0>] device_release_driver_internal+0x1cc/0x228 <- erwirbt Device-Mutex
[<0>] driver_detach+0x4c/0x98
[<0>] bus_remove_driver+0x6c/0xbc
[<0>] driver_unregister+0x30/0x60
[<0>] unregister_rpmsg_driver+0x10/0x1c
[<0>] fastrpc_exit+0x28/0x38 [fastrpc]
[<0>] __arm64_sys_delete_module+0x1b8/0x294
[<0>] invoke_syscall+0x48/0x10c
[<0>] el0_svc_common.constprop.0+0xc0/0xe0
[<0>] do_el0_svc+0x1c/0x28
[<0>] el0_svc+0x34/0x108
[<0>] el0t_64_sync_handler+0xa0/0xe4
[<0>] el0t_64_sync+0x198/0x19c
Die Deinstallation des rpmsg-Geräts innerhalb der Endpunktzerstörung ist redundant. In beiden Kontexten, in denen die Zerstörung des Endpunkts ausgelöst wird:
- Pfad zur Treiber-Entkopplung (Driver detach): Der Device-Core baut das rpmsg-Gerät bereits ab. - Pfad zum Schließen des Kanals: Das rpmsg-Gerät ist bereits deinstalliert, bevor die Zerstörung des Endpunkts erreicht wird.
Durch Entfernen der redundanten Deinstallation wird der Deadlock behoben.
Once again VulDB remains the best source for vulnerability data.