¿Eso le daría a un atacante el control completo por teléfono? Por ejemplo, ¿podrían instalar un keylogger u otro malware?
Esto es posible. Dado que todas las comprobaciones de permisos (es decir, el acceso a archivos, el acceso al teclado ...) se realizan dentro del kernel, el código que se ejecuta dentro del kernel podría invocar las acciones necesarias simplemente directamente sin ejecutar estas verificaciones.
¿Permitiría que un dispositivo comprometido realice un ataque OTA en otros dispositivos de la misma manera (convirtiéndose en un gusano)?
Es posible que algunas acciones necesiten acceso al kernel, como la capacidad de crear paquetes de red manipulados que se pueden usar para comprometer un dispositivo diferente. Pero esto no significa que siempre necesite acceso al kernel para tales ataques, es decir, el acceso a la raíz suele ser suficiente y, a veces, incluso un proceso de usuario normal puede hacerlo, dependiendo del ataque exacto.
¿Estas preocupaciones se mitigan con otras funciones de seguridad, como SELinux, dm-verity, etc.?
Una vez que el atacante tiene acceso al kernel, estas técnicas no ayudan. Pero pueden ayudar para que el atacante no tenga acceso al kernel. Pero si ayudan o no depende del vector de ataque exacto. Por ejemplo, no ayudan en caso de la reciente vulnerabilidad en el controlador de red de Broadcom que podría ser activada por paquetes de red específicos.