Infinity Core demuestra que las partes «silenciosas» del núcleo no son seguras

La versión resumida

Ir a la versión completa ↓

En qué consiste: «Infinity Core» es el nombre que Hyunwoo Kim (@v4bel) ha dado a seis fallos de seguridad en el código central del núcleo, que afectan a los temporizadores de CPU POSIX, la entrega de señales, el «page table walker», los futexes, la contabilidad de la caché del programador y el asignador SLUB. Kim publicó los detalles y el código de explotación en oss-security el 16 de octubre de 2026, tan pronto como expiró el embargo de linux-distros. Ir a esta sección →

Repercusión: Cinco de las seis vulnerabilidades cuentan con una demostración pública de concepto que parte de una cuenta normal sin privilegios y termina con un shell de root. Kim también clasifica estas mismas cinco como «escapes de contenedor». La sexta, en SLUB, por el momento solo provoca un error de pánico en el núcleo. Ir a esta sección →

Gravedad: Las puntuaciones no reflejan bien la situación. Amazon Linux califica los errores relacionados con el temporizador y la señal con un 7,0 según el CVSS 3.1, y el error MM con un 6,3; todos ellos con un vector de ataque local y una complejidad de ataque alta. Esas calificaciones se publicaron antes de que se hicieran públicos los exploits de root que funcionaban. Ir a esta sección →

¿A quién afecta?: Ubuntu 26.04 es la versión más afectada. Los exploits de root para los fallos relacionados con el temporizador, las señales, MM y futex se escribieron y probaron en su 7.0.0-30-generic kernel, y el equipo de kernel de TuxCare también ha conseguido obtener privilegios de root con las cuatro vulnerabilidades en Ubuntu 26.04. El fallo del temporizador también afecta a los kernels de EL9 y EL10, a Debian 12 y 13, y a Ubuntu 24.04, donde las pruebas de TuxCare han provocado fallos del sistema, pero no han permitido obtener privilegios de root —al menos, de momento—. Los fallos del programador y de SLUB solo están presentes en la versión 7.2 y posteriores. Ir a esta sección →

Estado: Existen correcciones en el código fuente para las seis vulnerabilidades, y cuatro de los registros CVE ya se hicieron públicos entre el 4 de septiembre y el 6 de octubre. Los núcleos de las distribuciones se están poniendo al día de forma desigual. Debian, por ejemplo, ya ha publicado núcleos de seguridad corregidos tanto para «bookworm» como para «trixie», y Red Hat corrigió el fallo «futex» para RHEL 9 el pasado 1 de octubre. No hay constancia de que se hayan explotado en la red. Se trata de vulnerabilidades «n-day» con exploits públicos, no de «zero-day».

Hazlo ahora mismo: no se conoce ningún sysctl ni módulo que permita desactivarlo. Instala primero los kernels corregidos en los servidores con Ubuntu 26.04, empezando por aquellos que ejecutan código de personas en las que no confías plenamente, como servidores de alojamiento compartido, ejecutores de CI y servidores de contenedores multitenant. Si tu distribución ya incluye una corrección, instálala y programa el reinicio. Desactivar los espacios de nombres de usuario sin privilegios no servirá de nada, ya que ninguno de estos errores los necesita. Para ver qué kernel se está ejecutando realmente:

uname -r

Compáralo con las recomendaciones de tu proveedor, no con los números de versión de las versiones anteriores. Los núcleos de las distribuciones incorporan correcciones sin aumentar la versión base.

Ir a esta sección →

Muchas de las escaladas de privilegios del núcleo que aparecen en las noticias provienen de los mismos ámbitos: redes, sockets, BPF y perf. Se trata de errores a los que solo se puede acceder desde un espacio de nombres de usuario sin privilegios. Las guías de refuerzo de la seguridad llevan años enseñando a los administradores a aislar esos ámbitos, y muchas empresas han hecho precisamente eso.

Infinity Core lo evita todo. Kim omitió deliberadamente esas áreas y se centró en el código que ejecuta cada proceso sin pensárselo dos veces, como por ejemplo: exec(), gestión de señales, mincore() y futexes. El resultado fue que se detectaron cuatro vulnerabilidades que permiten obtener privilegios de root en una instalación estándar de Ubuntu 26.04, una más en Arch Linux, y no se conoce ningún ajuste de sysctl ni de módulos que permita eliminarlas.

Las correcciones ya están en el código fuente original. Lo que les falta a muchos servidores es un núcleo en funcionamiento que las incorpore.

Lo que llegó el 16 de octubre

Kim informó de los errores de forma privada, los trató a través de la lista de correo «linux-distros» y los publicó una vez que expiró el embargo, el 16 de octubre de 2026. La entrada de «oss-security» y el repositorio de InfinityCore incluyen descripciones detalladas de cada error y el código de explotación. Tampoco es la primera vez que Kim aparece en este blog. Este mismo investigador descubrió Januscape y Zapscape, las vulnerabilidades de KVM de principios de este año.

Cuatro de los seis ya contaban con registros CVE públicos antes del día de la divulgación. El CNA del núcleo publicó el CVE de futex el 4 de septiembre, el de MM el 11 de septiembre y los de timer y signal el 6 de octubre. Cada uno de ellos se publicó con el tipo de título seco, al estilo de un commit, habitual en los CVE del núcleo, sin nada en él que sugiriera que se avecinaba un exploit de root. Un CVE que parece un parche de limpieza es fácil de dejar de lado hasta la siguiente ventana de mantenimiento. No ocurre lo mismo con el mismo CVE si hay un exploit de root disponible en GitHub.

Todavía queda un detalle por revelar. Kim afirma que el fallo del temporizador también otorga privilegios de root completos en un Samsung Galaxy S26 Ultra partiendo de una aplicación normal, y que ese exploit se mantendrá en secreto hasta que Samsung lance una solución o alguien más publique una antes.

Los errores del temporizador y de la señal comparten un desencadenante, y es uno bastante peculiar. Cuando un hilo que no es el líder del proceso llama a exec() y, si el proceso avanza lo suficiente, el núcleo intercambia los identificadores de los hilos para que el hilo que realiza la llamada asuma el papel de nuevo líder. Ambos errores se encuentran en la limpieza que se lleva a cabo en torno a ese intercambio.

CVE-2026-98260, el fallo del temporizador, requiere que se active un temporizador de CPU POSIX por hilo en ese hilo. Si exec() si falla tras el intercambio de ID, el temporizador se libera mientras su nodo sigue en la cola de una tarea activa, y posteriormente el proceso de limpieza accede directamente a ese nodo liberado. Un caso clásico de «uso tras liberación». El exploit público lo convierte en un shell de root en Ubuntu 26.04, y la corrección, acb03d388181, traslada la limpieza del temporizador para que se realice inmediatamente después de de_thread() para que no quede nada sin resolver cuando exec() fianzas.

CVE-2026-98256, el fallo de señales, es una situación de carrera por el mismo momento. Una ruta vacía las señales pendientes del líder que está a punto de fallar sin adquirir un bloqueo, mientras que otra sigue el PID intercambiado y vincula un sigqueue entrada en la cola del nuevo líder. Si se corrompen los enlaces, una entrada perdura más allá de la vida útil del objeto al que pertenece. El exploit de Kim utiliza esa entrada residual como oráculo para detectar cuándo se ha reutilizado la memoria liberada y, a continuación, aprovecha la ruta que retira de la cola la señal manipulada para obtener un shell de root. La solución es d2710c8d938a.

Los programas fallan exec() Durante todo el día. Un camino erróneo, un intérprete que falta, una señal en el momento equivocado. Sin embargo, ninguno de los dos fallos se activa por cualquiera de esas causas. El fallo del temporizador requiere que se produzca un error tras el intercambio de ID de hilo, y el fallo de la señal necesita que un atacante gane una carrera de acceso en torno a ese mismo intercambio. Desde fuera, el intento sigue pareciendo una actividad normal del proceso, por lo que no hay una forma clara de filtrarlo, salvo mediante un parche.

La vulnerabilidad CVE-2026-89754 se encuentra en el «page table walker». Durante una situación de carrera con madvise(MADV_DONTNEED), un indicador de reintento de un nivel inferior se filtra hacia arriba, y mincore() recorre el mismo rango dos veces. Para entonces, su cursor de salida ya se ha desplazado, por lo que la segunda pasada escribe más allá de un búfer temporal que tiene exactamente una página de longitud. El exploit de Kim coloca un bloque de credenciales en la página física siguiente y utiliza el desbordamiento para poner a cero los campos UID y GID de un struct cred. En lo que respecta al LPE del núcleo, no hay nada más directo que eso. La solución es aedf2efd1897.

CVE-2026-80775, el fallo de futex, requiere que dos tareas compartan una mm_struct, que contenía vfork() se produce una vez que se elimina el «hijo mediano». Ambos compiten por instalar el primer contador de referencias para el hash privado de futex. Solo sobrevive un almacenamiento, por lo que dejan de registrarse las referencias realizadas al otro contador y se libera un hash que aún está en uso. El exploit lo recupera mediante un «pipe ring» y sobrescribe la caché de páginas de /usr/bin/passwd. Esto modifica lo que el núcleo devuelve para el archivo sin guardar el cambio en el disco, por lo que la manipulación podría desaparecer una vez que se vacíe la página almacenada en caché o se reinicie el servidor. Buena suerte investigando eso después. La solución es bde023808364.

Los dos últimos tienen menos importancia para la mayoría de las flotas. CVE-2026-98385 es un error de «uso tras liberación» en el sistema de contabilidad de la caché del programador que requiere CONFIG_SCHED_CACHE=y en la compilación, la contabilidad de la caché del programador activada en tiempo de ejecución y una topología de CPU con más de una caché de último nivel. Su exploit consiguió privilegios de root en Arch Linux con un kernel 7.2.4. CVE-2026-97941 es una carrera de acceso (ABA) en la recarga de objetos SLUB que corrompe una lista parcial. Su desencadenante público simplemente provoca un pánico en el núcleo, y no se ha publicado ningún exploit de root para ella. Ambas se encuentran en código que apareció por primera vez en la versión 7.2, por lo que ningún núcleo de distribución compatible con KernelCare las contiene.

En el momento de redactar este artículo, aún no se habían publicado las puntuaciones del NVD para los errores relacionados con el temporizador y las señales. Amazon Linux ha publicado las puntuaciones de tres de ellos, otorgando un 7,0 a los errores relacionados con el temporizador y las señales con el vector AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, y 6.3 por el error de MM.

En AC:H Esta parte merece una mirada más atenta. La mayoría de estos casos son una carrera, y «es una carrera» solía ser una razón válida para relegar algo al final de la cola. Un exploit público que ya ha hecho el trabajo duro de ganar la carrera cambia las reglas del juego. Un 7.0 que incluye un shell de root operativo, en un servidor donde los usuarios no de confianza pueden ejecutar código, merece un puesto cerca de la parte superior de la lista. Eso dice más sobre la urgencia que el número en sí.

¿Quién debería preocuparse primero?

Cada una de ellas parte de una cuenta local básica, sin privilegios, sin espacio de nombres de usuario y sin acceso a dispositivos especiales. Así pues, la verdadera pregunta es: ¿quién puede ejecutar código en tus servidores sobre los que no tienes un control total?

Los servidores de alojamiento compartido con shells SSH o de panel de control de los clientes son la respuesta obvia. Los ejecutores de CI que crean pull requests arbitrarias son otra. También lo es cualquier host que ejecute contenedores para usuarios que no confían entre sí. Kim clasifica los cinco errores de raíz como fugas de contenedores, y eso tiene sentido. Todos los contenedores comparten el kernel del host, y las llamadas al sistema implicadas son las habituales que las cargas de trabajo de los contenedores utilizan constantemente. A menos que un perfil seccomp o una política LSM bloqueen precisamente esa ruta, no cuentes con que el límite del contenedor te salve.

Un servidor de bases de datos de uso específico con tres administradores es otra historia. Sigue necesitando la corrección, pero no es la prioridad.

¿Es «Infinity Core» una vulnerabilidad de día cero?

No. Todas las correcciones se aplicaron en la versión original antes de que se hicieran públicos los exploits, y el registro CVE más antiguo es anterior a la divulgación en unas seis semanas. No hay constancia de que se hayan aprovechado en el mundo real. Se trata de «n-days» con exploits públicos, lo que puede poner a los defensores en una situación aún peor. Ahora, el tiempo lo marca la rapidez con la que las distribuciones lanzan los núcleos corregidos y la rapidez con la que los administradores los instalan realmente.

Exposición de las distribuciones compatibles con KernelCare a fecha de 19 de octubre de 2026, según el análisis propio de TuxCare y al margen del estado del núcleo de cada proveedor:

La expresión «fallos detectados hasta ahora» requiere una matización. Un exploit de root que funcione en una versión del kernel supone una gran ventaja de cara a la siguiente, aunque adaptarlo siga requiriendo un esfuerzo considerable. Aunque no se ha demostrado que exista acceso root en esas distribuciones, la escalada de privilegios locales supone un riesgo real en ellas, y la prioridad a la hora de aplicar parches debería reflejarlo.

Como se ha mencionado al principio, una cadena de versión por sí sola no resuelve nada en este caso. Solo lo hace un aviso del fabricante o un parche verificado para ese núcleo concreto.

Consigue KernelCare hoy mismo →

Por qué no hay una solución rápida

En muchos de los LPE recientes del núcleo, la solución provisional consistía en una sola línea de código: incluir un módulo en la lista negra, cambiar un parámetro sysctl o desactivar los espacios de nombres de usuario sin privilegios. Esta vez, nada de eso funciona. Kim ha omitido a propósito los errores que requieren un espacio de nombres de usuario, y el resto se encuentran en exec(), gestión de señales, mincore() y código futex que ningún sistema en funcionamiento puede descargar ni desactivar. TuxCare no ha identificado ninguna solución alternativa fiable. Las medidas habituales, como desactivar los espacios de nombres de usuario sin privilegios o incluir un módulo en la lista negra, no afectan a las rutas de código vulnerables, y no se ha verificado ninguna solución alternativa específica para cada fallo.

Eso nos deja con las opciones menos satisfactorias. Reducir el número de usuarios que tienen un shell local en hosts expuestos hasta que se apliquen los parches. Trasladar a los inquilinos que realmente no confían entre sí a máquinas virtuales independientes, en lugar de contenedores en un núcleo compartido. Y estar atentos al registro del núcleo. Varias de estas situaciones son carreras de acceso, y un intento fallido puede provocar un «oops» o un «panic» en el núcleo en lugar de fallar silenciosamente, aunque un registro limpio no prueba que no haya pasado nada:

journalctl -k | grep -iE 'BUG:|Oops|general protection'

Un error inexplicable ocurrido esta semana en un servidor multiusuario merece que se le preste más atención.

La solución definitiva consiste en utilizar un núcleo que incorpore los parches de origen, ya sea el de tu distribución o uno que hayas compilado tú mismo. La instalación del paquete no afecta al núcleo que ya se está ejecutando en memoria, por lo que, hasta que el equipo se reinicie con el nuevo, no habrá cambiado nada. Comprueba qué es lo que se está ejecutando realmente:

uname -r

Un servidor en el que se haya instalado un kernel corregido y que nunca se haya reiniciado sigue ejecutando el kernel vulnerable. Los servidores de alojamiento compartido y los grupos de infraestructura como código (CI) suelen ser los que presentan más problemas, ya que reiniciarlos implica avisar a los clientes o interrumpir los trabajos en curso.

Una vez publicados para tu kernel, los parches sin reinicio de KernelCare aplican la corrección al kernel en ejecución sin necesidad de reiniciar. Cuando las actualizaciones automáticas están activadas, el sistema detecta el parche en la siguiente comprobación programada, una vez que este se encuentra en el canal de actualizaciones del kernel en ejecución, y kcarectl --update lo solicita cuando es necesario. Para comprobar la cobertura de los cuatro errores que afectan a los núcleos de las distribuciones compatibles:

kcarectl --patch-info | grep -E 'CVE-2026-(98260|98256|89754|80775)'

Las vulnerabilidades CVE relacionadas con el programador y SLUB se han excluido deliberadamente de ese patrón, ya que ningún kernel de distribución compatible las incluye. A fecha de 19 de octubre de 2026, el único parche de Infinity Core publicado es la corrección de futex para una rama del kernel de AlmaLinux 9. Aún no se ha publicado nada para el fallo del temporizador en ninguna distribución, ni para los cuatro fallos de Ubuntu 26.04. Consulta esta publicación para conocer las novedades en los próximos días. Una vez que un parche llegue a tu versión del kernel, comprueba que KernelCare lo haya aplicado realmente al kernel en ejecución y mantén un control estricto del acceso hasta que se verifique la cobertura de los CVE pertinentes.

Por qué es importante Infinity Core

El endurecimiento por sustracción tiene un límite máximo. Los administradores se han vuelto expertos en eliminar la superficie de ataque que no necesitan, y ese esfuerzo da sus frutos. Pero nadie puede eliminar exec(). Kim se adentró en subsistemas con un historial de seguridad discreto y regresó con seis fallos. Un código maduro y muy utilizado no es sinónimo de código seguro, y el refuerzo de la seguridad por sí solo no basta para salvar esa brecha.

Si utilizas Ubuntu 26.04 con usuarios locales sin privilegios, esa es la primera tarea de aplicación de parches de esta semana. En servidores con EL, Debian y Ubuntu 24.04, hay que dar máxima prioridad al fallo del temporizador, aunque las pruebas solo hayan provocado fallos del sistema hasta ahora, ya que el exploit público de Ubuntu hace que obtener privilegios de root sea un siguiente paso muy probable. Y cuando un reinicio supone agotar un grupo de CI o enviar correos electrónicos a unos cientos de clientes de alojamiento, los parches sin reinicio de KernelCare están pensados para corregir estos fallos en el kernel en ejecución a medida que se dispone de la cobertura necesaria, sin necesidad de una ventana de mantenimiento.

Consigue KernelCare hoy mismo →

Cronología

Referencias

La publicación de Kim sobre Infinity Core en oss-security (16 de octubre de 2026), el repositorio de InfinityCore con el código de explotación y los informes detallados de cada fallo, los registros CVE para CVE-2026-98260, CVE-2026-98256, CVE-2026-89754, CVE-2026-80775, CVE-2026-98385 y CVE-2026-97941; el conjunto completo de commits de correcciones del proyecto original que figuran en el repositorio de Kim, incluidas la corrección del temporizador acb03d388181 y la corrección de futex bde023808364; la entrada del sistema de seguimiento de seguridad de Debian para CVE-2026-98260, el RHSA-2026:74438 de Red Hat y la puntuación de Amazon Linux para CVE-2026-98260, CVE-2026-98256 y CVE-2026-89754.