Cómo KernelCare corrigió Januscape antes de que OVHcloud iniciara sus reinicios masivos

Principales conclusiones:

• OVHcloud solucionó el problema de Januscape reiniciando decenas de miles de servidores a lo largo de 11 días, lo que provocó interrupciones reales del servicio, fallos de hardware y la activación de una célula de crisis global.
• KernelCare proporcionó las dos correcciones necesarias para Januscape en forma de parches sin necesidad de reinicio, también conocidos como «parches en vivo», con cobertura en el canal principal a partir del 7 de julio, antes de la primera oleada de reinicios de OVH del 8 de julio.
• La aplicación de parches que requiere reinicio deja cada host vulnerable hasta el momento del reinicio, mientras que la aplicación de parches sin reinicio cierra la ventana de vulnerabilidad en el momento en que se aplica el parche.

OVHcloud ha publicado uno de los análisis retrospectivos sobre infraestructura más sinceros que se han visto en el sector del alojamiento web en los últimos años.

Para solucionar el problema de Januscape, registrado con el número CVE-2026-53359, la empresa aplicó parches y reinició decenas de miles de hosts KVM que alojaban alrededor de un millón de máquinas virtuales. La operación se extendió por todos los continentes, requirió una respuesta de emergencia las 24 horas del día, los 7 días de la semana, y tardó 11 días en completarse.

The Register se hizo eco de la campaña. El análisis completo de OVHcloud es una lectura muy recomendable para cualquier persona responsable de un gran parque de virtualización.

Como ejemplo de gestión operativa, resulta realmente impresionante. Los equipos de OVHcloud actuaron con rapidez, gestionaron los fallos bajo presión y documentaron los resultados con una transparencia poco habitual.

Desde el punto de vista de las infraestructuras, esto plantea una cuestión más compleja.

¿Por qué fue necesario llevar a cabo una campaña de reinicio general para aplicar una corrección del núcleo?

He aquí la diferencia. En el caso de las plataformas compatibles con KernelCare, la corrección de Januscape sin necesidad de reinicio ya estaba disponible en el canal principal de parches antes de que OVH reiniciara su primer servidor. Las flotas suscritas la recibieron siguiendo el ciclo de actualización habitual. Sin reinicios. Sin interrupciones. Sin campaña.

Januscape en dos frases

Januscape es una vulnerabilidad de tipo «uso tras liberación» (use-after-free) presente en el código de gestión de la memoria sombra x86 de KVM. Un atacante con acceso de root dentro de una máquina virtual invitada podría aprovecharla para bloquear el sistema host y, potencialmente, ejecutar código con privilegios a nivel de host.

La vulnerabilidad afecta a los sistemas Intel y AMD y llevaba aproximadamente 16 años presente en el núcleo de Linux. Para solucionarla se requieren dos correcciones relacionadas entre sí en el código fuente original, asociadas a los CVE-2026-53359 y CVE-2026-46113.

Nuestro análisis técnico de Januscape aborda en detalle la vulnerabilidad, la vía de explotación y las correcciones necesarias.

También hemos organizado una retransmisión en directo en la que se analiza la vulnerabilidad, por si prefieres escuchar a dos expertos hablar sobre el CVE en lugar de seguir leyendo sobre el tema.

El artículo que estás leyendo ahora mismo trata sobre el proyecto de ley de funcionamiento.

Qué requisitos tiene la aplicación de parches que requiere reiniciar el sistema

Todo lo que se expone a continuación procede del análisis posterior al incidente de OVH y del artículo de The Register. Nada de ello es especulación.

OVHcloud probó por primera vez su procedimiento de implementación en Sídney. Esta región ofrecía un espacio físico relativamente reducido, una menor demanda nocturna y la cobertura durante el horario laboral por parte de los equipos de Europa. Una vez validado el manual de procedimientos, los reinicios se fueron extendiendo por todo el mundo mediante una operación de «seguimiento del sol».

Ese proceso implicaba mucho más que instalar un paquete del núcleo y reiniciar los servidores. Las oleadas de reinicio se regían por umbrales de interrupción. OVHcloud detenía una oleada si 15 servidores estaban inactivos simultáneamente en una región de alta densidad o si cinco lo estaban en cualquier otro lugar.

En el caso de los proyectos de los clientes distribuidos entre varios servidores, los coordinadores calculaban un gráfico de colocalización. El objetivo era evitar que dos servidores que alojaran el mismo proyecto se reiniciaran dentro del mismo intervalo de tiempo.

Los equipos también identificaron las dependencias internas de los servicios antes de cada implementación regional. Fue necesario realizar primero una migración en vivo de algunas máquinas virtuales críticas para que las bases de datos, las API, los sistemas de supervisión y otros servicios operativos siguieran estando disponibles durante los reinicios.

Los clientes cuyas instancias se encontraban todas en un único servidor sufrieron una interrupción. Se les comunicó el plazo previsto, pero la urgencia de la respuesta de seguridad hizo que no fuera viable optar por no participar.

Entonces apareció el mundo físico. La primera noche, entre 20 y 30 servidores, de un total de 6.000, no se reiniciaron por sí solos: módulos de memoria defectuosos, problemas con la BIOS, interfaces de red averiadas.

Algunas máquinas en EE. UU. requerían quitar la batería CMOS y descargar la alimentación antes de que arrancaran. Durante ese tiempo, se contó con técnicos de centros de datos en cada emplazamiento, que se encargaban de sustituir piezas y realizar tareas manuales en los racks que ningún sistema de orquestación puede automatizar.

El software también dio guerra. Las máquinas virtuales no se reiniciaban tras el reinicio del servidor anfitrión hasta que se detectó y se solucionó un conflicto de libvirt-guests. Los apagados forzados dañaron los datos de las máquinas virtuales en tres clústeres. Las API de OpenStack de París entraron en un punto muerto que provocó dos horas de errores HTTP 503, lo que retrasó una oleada. En la sede canadiense, el tráfico alcanzó 10 veces el pico habitual y desbordó al servicio de asistencia.

Hay que reconocer lo que hay que reconocer: la célula de crisis de OVH gestionó muy bien la situación, y hacer públicos los fallos requiere más valentía de la que tienen la mayoría de los proveedores.

El problema no fue la ejecución, sino el modelo de parches que la requería.

Qué hicieron, en cambio, los sistemas protegidos por KernelCare

Las flotas que utilizan KernelCare gestionaron la misma vulnerabilidad sin necesidad de recurrir a ninguno de los mecanismos operativos descritos anteriormente. Sin oleadas de reinicios, sin ventanas de mantenimiento, sin técnicos desplegados por etapas.

El objetivo actual de TuxCare en lo que respecta a las escaladas de privilegios locales y las vulnerabilidades de día cero es ofrecer parches en tiempo real en un plazo de 48 horas desde su divulgación pública. En este caso, se ha cumplido antes de ese plazo: el embargo se levantó el 6 de julio y KernelCare comenzó a distribuir ambas correcciones necesarias a la vez a través de su proceso habitual de aplicación de parches sin necesidad de reinicio, lo que a veces se denomina «parches en tiempo real», el 7 de julio (aproximadamente 24 horas después).

Tal y como se recoge en nuestro análisis técnico de Januscape, la cobertura disponible en general a fecha de 7 de julio incluía:

• La familia Enterprise Linux 10
• Ubuntu 22.04, incluidas las versiones en la nube
• Debian 13
• Sistemas Ubuntu Focal que utilizan el núcleo Jammy de habilitación de hardware
• Proxmox VE 7 y 8

Posteriormente, otras familias de kernels pasaron por las fases de desarrollo, pruebas y despliegue gradual.

OVHcloud inició sus primeras oleadas de reinicio en Sídney al día siguiente, el 8 de julio.

Así pues, mientras un grupo de operadores aún estaba programando el tiempo de inactividad, las flotas actualizadas ya estaban protegidas —con la salvedad habitual de que esto no demuestra que los parches del 7 de julio hubieran sido aplicables a los propios núcleos Debian de producción de OVHcloud—. OVHcloud no ha revelado públicamente suficiente información sobre las versiones como para poder determinarlo.

Esto demuestra la alternativa operativa de la que disponen los proveedores de alojamiento que utilizan núcleos compatibles.

Cuando el parche correspondiente, que no requería reinicio, llegaba al sistema, el código vulnerable podía sustituirse sin necesidad de reiniciar el servidor. No había que programar ningún intervalo de reinicio, no era necesario organizar las cargas de trabajo de los clientes en función de un ciclo de apagado y encendido, ni enviar ningún aviso a los clientes relacionado con el reinicio.

Tampoco había ningún problema de hardware latente que pudiera surgir durante un reinicio de emergencia.

Los administradores podrían comprobar la cobertura directamente:

kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113'

La diferencia no radica en que un grupo se tomara en serio Januscape y el otro no. Ambos lo hicieron.

El enfoque de OVH convirtió la corrección del problema en un incidente importante de infraestructura, mientras que la aplicación de parches sin necesidad de reiniciar el sistema con KernelCare lo habría convertido en una operación rutinaria de implementación de parches.

La ventana de exposición es el coste oculto

La instalación de un paquete del núcleo parcheado no protege el núcleo que se está ejecutando en ese momento. La vulnerabilidad sigue activa hasta que el equipo se reinicie con la versión actualizada.

Esto genera un periodo de vulnerabilidad en todos los hosts que aún están a la espera de su turno.

OVHcloud reconoció explícitamente este problema. Atender a los clientes de forma individual habría alargado la campaña y dejado vulnerable a gran parte de la flota durante semanas. La empresa también limitó la comunicación pública mientras se llevaba a cabo la implementación, ya que temía que los clientes pudieran probar el exploit de bloqueo, disponible públicamente, contra la infraestructura de producción.

Con la aplicación de parches sin reinicio, la ventana se cierra cuando el parche correspondiente se ha aplicado correctamente. La actualización convencional del núcleo y el reinicio pueden realizarse más tarde, durante un ciclo de mantenimiento programado, en lugar de en medio de una emergencia de seguridad.

¿Son demasiado inestables las actualizaciones sin reinicio?

OVHcloud estudió la posibilidad de aplicar parches sin interrupción del servicio y la descartó. En su análisis a posteriori se argumenta que modificar un kernel en ejecución puede reducir el nivel de seguridad y generar inestabilidad en toda la flota.

Esa inquietud merece una respuesta directa. Analicémosla desde tres perspectivas:

En primer lugar, cómo se distribuyen realmente estos parches. Cada parche de KernelCare se compila y se prueba con la versión específica del núcleo a la que va dirigido; a continuación, pasa por un proceso de validación interna y una serie de pruebas por fases antes de llegar al canal de producción. Las flotas que deseen un control adicional utilizan el ePortal de KernelCare y configuran sus propias fases de aprobación y políticas de implementación. Se trata de un proceso de distribución consolidado.

En segundo lugar, este fallo concreto. La corrección de Januscape es un ejemplo clásico de parche que no requiere reinicio: una corrección localizada en la ruta de fallos de la MMU de KVM, sin ningún estado persistente que migrar ni estructuras de datos que transformar. Si tuvieras que diseñar un CVE para demostrar para qué sirven los parches sin reinicio, sería como este.

En tercer lugar, y esta es la parte en la que vale la pena detenerse: el propio análisis posterior de OVH documenta la inestabilidad del proceso de reinicio. Docenas de servidores que nunca volvieron a funcionar. Discos dañados por apagados forzados. Un bloqueo regional de la API. Máquinas virtuales que quedaron fuera de línea debido a un conflicto de servicios. La elección nunca fue entre un parche sin reinicio arriesgado y un reinicio sin riesgos. Se trataba de elegir entre dos métodos con perfiles de riesgo diferentes y, a escala de flota, los riesgos de la ruta de reinicio son grandes, tangibles y están documentados. La estabilidad es una propiedad de todo el proceso de corrección, no del mecanismo de aplicación de parches por sí solo.

Si tu flota puede reiniciarse por completo en un plazo de 24 horas sin que ello afecte a los clientes, es posible que el cálculo sea realmente diferente en tu caso. Si una vulnerabilidad del núcleo (CVE) implica una campaña de varias semanas, una célula de crisis y técnicos en cada centro de datos, el problema está en el modelo, no en tu equipo.

Campaña de reinicio frente a la aplicación de parches sin reinicio

Probablemente esto volverá a pasar

Januscape no fue un hecho aislado.

CopyFail, DirtyFrag, GhostLock y otras vulnerabilidades graves del núcleo han obligado a los equipos de infraestructura a tomar decisiones urgentes sobre la exposición al riesgo, el tiempo de inactividad y las medidas correctivas.

El responsable de seguridad de la información (CISO) de OVHcloud reconoció que nuevas vulnerabilidades en el núcleo podrían obligar a repetir el procedimiento de emergencia. La tarea inmediata de la empresa es hacer que ese procedimiento sea más seguro y predecible la próxima vez.

Otros proveedores de alojamiento ofrecen otra opción.

Pueden reducir, en primer lugar, la frecuencia con la que una vulnerabilidad del núcleo se convierte en un incidente que afecta a la infraestructura de cara al cliente.

OVHcloud demostró lo bien que se puede llevar a cabo una campaña de reinicio a gran escala bajo presión. KernelCare demostró que, en el caso de los sistemas compatibles, era posible eliminar esa misma vulnerabilidad de un kernel en ejecución sin necesidad de poner en marcha dicha campaña.

La lección que hay que aprender de Januscape no es que los proveedores de alojamiento necesiten un manual de procedimientos de reinicio más eficaz.

Lo importante es que no tengan que activarlo cada vez que aparezca una vulnerabilidad crítica del núcleo.

Disfruta de la aplicación de parches sin necesidad de reiniciar con KernelCare →