Ejecutar código en el "espacio del kernel" significa ejecutarlo en el espacio del anillo 0. En otras palabras, es la definición estricta de "tener el control total".
La única excepción sería si está ejecutando un hipervisor. En tal caso, ejecutar el código en el anillo 0 del sistema operativo virtualizado "solo" le daría el control total del dispositivo virtualizado, no del hipervisor (que se dice que se ejecuta en el anillo -1) en el que se está ejecutando. Necesitarías un exploit de escape separado para llegar a eso.
¿Eso le daría a un atacante control total sobre el teléfono? Por ejemplo, ¿podrían instalar un keylogger u otro malware?
Esto es posible. Dado que las comprobaciones de permisos (es decir, acceso a archivos, acceso al teclado...) se realizan dentro del kernel, el código que se ejecuta dentro del kernel podría invocar las acciones necesarias directamente sin ejecutar estas comprobaciones.
¿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 pueden usarse 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.
¿Están estas preocupaciones mitigadas por otras funciones de seguridad, como SELinux, dm-verity, etc.?
Una vez que el atacante tiene acceso al kernel, estas técnicas no ayudan. Pero podrían ayudar a que el atacante no obtenga acceso al kernel. Pero si ayudan o no, depende del vector de ataque exacto. Por ejemplo, no ayudan en caso de una vulnerabilidad reciente en el controlador de red de Broadcom que podría activarse por paquetes de red específicos.