Vulnerabilidad en kernel de Linux (CVE-2022-49236)
Fecha de publicación:
26/02/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Arreglar UAF debido a la ejecución entre btf_try_get_module y load_module Mientras trabajaba en el código para rellenar los conjuntos de ID de BTF de kfunc para el módulo BTF desde su initcall, noté que para el momento en que se invoca la initcall, el espacio de usuario (y el verificador BPF) ya puede ver el módulo BTF. El btf_try_get_module existente llama a try_module_get, que solo falla si mod->state == MODULE_STATE_GOING, es decir, puede incrementar la referencia del módulo cuando la initcall del módulo está sucediendo en paralelo. Actualmente, el análisis de BTF ocurre desde la devolución de llamada del notificador MODULE_STATE_COMING. En este punto, las initcalls del módulo no han sido invocadas. La devolución de llamada del notificador analiza y prepara el módulo BTF, asigna un ID, que lo publica en el espacio de usuario y luego lo agrega a la lista btf_modules, lo que permite que el núcleo invoque btf_try_get_module para el BTF. Sin embargo, en este punto, el módulo no se ha inicializado por completo (es decir, sus llamadas de inicio no han finalizado). El código en module.c aún puede fallar y liberar el módulo, sin preocuparse por otros usuarios. Sin embargo, nada impide que btf_try_get_module tenga éxito entre la transición de estado de MODULE_STATE_COMING a MODULE_STATE_LIVE. Esto conduce a un problema de use-after-free cuando el programa BPF se carga correctamente en la transición de estado, la llamada do_init_module de load_module falla y libera el módulo, y el programa BPF fd al cerrar llama a module_put para el módulo liberado. El parche futuro tiene un caso de prueba para verificar que no retrocedamos en esta área en el futuro. Hay varios puntos después de prepare_coming_module (en load_module) donde puede ocurrir un fallo y la carga del módulo puede devolver un error. Ilustramos y probamos la ejecución usando el último punto donde puede ocurrir prácticamente (en la función __init del módulo). Una ilustración de la ejecución: CPU 0 CPU 1 load_module notifier_call(MODULE_STATE_COMING) btf_parse_module btf_alloc_id // Publicado en el espacio de usuario list_add(&btf_mod->list, btf_modules) mod->init(...) ... ^ bpf_check | check_pseudo_btf_id | btf_try_get_module | devuelve verdadero | ... ... | módulo __init en progreso devuelve prog_fd | ... ... V if (ret < 0) free_module(mod) ... close(prog_fd) ... bpf_prog_free_deferred module_put(used_btf.mod) // use-after-free Solucionamos este problema estableciendo un indicador BTF_MODULE_F_LIVE, desde la devolución de llamada del notificador cuando se alcanza el estado MODULE_STATE_LIVE para el módulo, de modo que devolvamos NULL desde btf_try_get_module para los módulos que no están completamente formados. Dado que try_module_get ya verifica que el módulo no esté en el estado MODULE_STATE_GOING, y esa es la única transición que un módulo activo puede hacer antes de ser eliminado de la lista btf_modules, esto es suficiente para cerrar la ejecución y evitar el error. Un parche de autoprueba posterior crea la condición de ejecución artificialmente para verificar que se ha solucionado, y que el verificador no puede cargar el programa (con ENXIO). Por último, un par de comentarios: 1. Incluso si esta ejecución no existiera, parece más apropiado acceder solo a los recursos (ksyms y kfuncs) de un módulo completamente formado que se haya inicializado por completo. 2. Este parche nació de la necesidad de sincronización con el módulo initcall para el próximo parche, por lo que es necesario para la corrección incluso sin la condición de ejecución mencionada anteriormente. Los recursos BTF inicializados por el módulo initcall se configuran una vez y luego solo se buscan, por lo que simplemente esperar hasta que el initcall haya terminado garantiza un comportamiento correcto.
Gravedad CVSS v3.1: ALTA
Última modificación:
25/03/2025
