CVE-2026-93098 in Linux
Sumário
de VulDB • 18/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
rpmsg: glink: corrige bloqueio morto (deadlock) na destruição do endpoint durante o desanexo do driver
Durante o desanexo do driver, o núcleo do dispositivo mantém o mutex do dispositivo por toda a cadeia de callbacks de remoção do driver. Quando o endpoint rpmsg é destruído como parte desse processo de encerramento, a implementação da destruição do endpoint GLINK tenta registrar (unregister) o dispositivo rpmsg subjacente. Esse registro negativo chama device_del(), que tenta readquirir o mesmo mutex do dispositivo já mantido em níveis superiores da pilha, fazendo com que rmmod fique pendurado indefinidamente.
O bloqueio morto se manifesta com a seguinte cadeia de chamadas:
[<0>] device_del+0x44/0x414 <- tenta adquirir o mesmo mutex
[<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 <- adquire o mutex do dispositivo
[<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
O registro negativo do dispositivo rpmsg dentro da destruição do endpoint é redundante. Em ambos os contextos em que a destruição do endpoint é acionada:
- Caminho de desanexo do driver: o núcleo do driver já encerra (tears down) o dispositivo rpmsg.
- Caminho de fechamento do canal: o dispositivo rpmsg já está registrado negativamente antes que se alcance a destruição do endpoint.
Remova o registro negativo redundante para corrigir o bloqueio morto.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.