Januscape CVE-2026-53359: fuga del invitado en KVM

Ir directamente al resumen generado por IA de esta entrada del blog

La versión resumida

En qué consiste: Januscape (CVE-2026-53359) es una vulnerabilidad de tipo «use-after-free» en la MMU de sombra KVM/x86 del núcleo de Linux. Un sistema invitado malintencionado puede hacer que KVM reutilice una página de sombra almacenada en caché que ya no se corresponde con la asignación que se está creando, lo que deja una entrada obsoleta en el mapa inverso que apunta a memoria que KVM liberará posteriormente. Ir a la versión completa →

Impacto: El resultado público y fiable es un fallo del host. Las investigaciones públicas describen una fuga completa del invitado al host: código dentro de un invitado malicioso que se ejecuta en el host con privilegios de root. Hemos confirmado de forma independiente la corrupción de la memoria del host y la primitiva de denegación de servicio en AlmaLinux 9 y Ubuntu 24.04, aunque no hemos reproducido la cadena de fuga completa. En los sistemas de la familia RHEL en los que /dev/kvm es accesible para todos, el mismo fallo permite la escalada de privilegios local a root. Ir a la versión completa →

Estado: Corregido en el código fuente original (commit 81ccda30b4e8, integrado en la rama principal en junio de 2026). La NVD publicó el CVE el 4 de julio de 2026 y el embargo se levantó el 6 de julio. Se trataba de una propuesta de «día cero» presentada al kvmCTF; para los defensores, hoy en día es un «N-day» con una prueba de concepto pública. Ir a la versión completa →

Gravedad: NVD no había asignado una puntuación CVSS en el momento de la publicación. La ausencia de puntuación no indica que el impacto sea bajo. Clasifícala internamente como «alta» y no esperes a que aparezca un recuadro de color. Ir a la versión completa →

A quién afecta: hosts KVM/x86, tanto Intel como AMD, que permiten la virtualización anidada a los sistemas invitados. La vía de escape requiere algo más que el acceso de root en el sistema invitado: la virtualización anidada. Ir a la versión completa →

Vulnerabilidad relacionada: es necesario aplicar una segunda corrección, CVE-2026-46113, para cerrar completamente Januscape. La aplicación del parche para la vulnerabilidad anterior por sí sola no detiene Januscape. Ir a la versión completa →

Haz esto ahora mismo: aplica un parche a los hosts KVM afectados con un kernel corregido o un parche que no requiera reinicio. Los hosts que no ejecuten máquinas virtuales pueden descargar y bloquear los módulos KVM. Los hosts que ejecuten máquinas virtuales pero no necesiten virtualización anidada deben desactivarla, lo que elimina la vía de escape de los invitados no fiables. Los hosts que necesiten ambas cosas no pueden solucionarse solo con la configuración. Ir a la versión completa →

¿Necesitas aplicar parches a los hosts KVM sin tener que reiniciar todas las máquinas virtuales?

KernelCare aplica parches de seguridad del núcleo de Linux sin tiempo de inactividad, sin interrupciones en las cargas de trabajo y sin ventanas de mantenimiento de emergencia.
Estado de KernelCare: A fecha de 7 de julio de 2026, se están distribuyendo parches que no requieren reinicio y que cubren tanto el CVE-2026-53359 como su complemento obligatorio, el CVE-2026-46113, para varias familias de núcleos, y hay más en fase de desarrollo activo. A continuación se detallan el estado completo de las versiones y las etiquetas K.

Descargar KernelCare →

La versión larga

Januscape pone en tela de juicio la promesa fundamental de la virtualización.

Una máquina virtual invitada puede estar comprometida, estar bajo el control del cliente, ser obsoleta, ser intencionadamente hostil o simplemente estar mal configurada. Ninguna de estas circunstancias debería permitirle acceder a la memoria del host. La función de KVM es traducir la memoria de la máquina virtual invitada de forma segura, manteniendo esa separación. Januscape altera el mecanismo interno que sustenta dicha traducción.

El error se encuentra en arch/x86/kvm/mmu/mmu.c, en la MMU «shadow» de KVM. Este código gestiona las estructuras de las tablas de páginas del lado del host que asignan las direcciones que utiliza un invitado a la memoria que el host ha autorizado. En una secuencia controlada de cambios en la asignación del invitado, KVM reutiliza una página «shadow» existente aunque su función registrada ya no coincida con la asignación que se está creando. Esa reutilización deja una entrada de mapa inverso que apunta a una estructura que KVM libera posteriormente, y un recorrido posterior por el mapa inverso desreferencia la página liberada.

Una aclaración inicial, ya que determina quién queda expuesto. No se trata de una «carrera de datos» en el sentido clásico, ni es el mismo defecto que el de su «hermano». El núcleo clasifica Januscape como un «use-after-free» provocado por un comportamiento inesperado de la página sombra. El desencadenante consiste en modificar una asignación de invitado de forma asíncrona, desde fuera del propio recorrido de páginas del invitado, por lo que alcanzar la ventana requiere una sincronización precisa. Pero la causa raíz es la falta de una comparación, no un error de bloqueo. Hay que tener en cuenta esa distinción, ya que de ella se derivan la corrección y las medidas de mitigación.

Cómo funciona Januscape

A grandes rasgos:

[Guest with root + nested virtualization exposed]
│  forces KVM back through the legacy shadow MMU
▼
[Guest creates a large 2 MB mapping → KVM builds a direct shadow page]
│
▼
[Guest rewrites the mapping to a 4 KB page-table path]
│  new mapping needs a non-direct (direct=0) page
▼
[kvm_mmu_get_child_sp() reuses the old direct page – gfn matches, role NOT compared]
│
▼
[Cleanup computes the wrong frame number → reverse-map entry not removed]
│
▼
[Shadow page freed; stale reverse-map entry left behind]
│  later rmap walk (dirty logging / MMU-notifier invalidation)
▼
[Use-after-free write of a fixed marker into freed memory]
▼
[Host crash (public PoC)  →  or guest-to-host escape, root on host (withheld exploit)]

Analicemos este proceso en detalle: la secuencia comienza con una entrada en el directorio de páginas del invitado que describe una asignación grande de 2 MB. KVM crea una página «kvm_mmu_page» que abarca 512 entradas individuales de 4 KB y, dado que la asignación del invitado es una página grande contigua, marca la página sombra como «directa».

A continuación, la asignación se modifica fuera del flujo de ejecución normal del sistema invitado. En lugar de una página grande, la misma entrada del directorio de páginas apunta ahora a otra tabla de páginas que contiene asignaciones individuales de 4 KB. KVM necesita un tipo diferente de página sombra para esa estructura: la original tiene un rol directo, mientras que la nueva asignación requiere uno no directo. La ruta vulnerable kvm_mmu_get_child_sp() no compara ese rol completo antes de decidir reutilizar la página existente. El número de marco coincide, por lo que la página se acepta, y KVM instala una nueva entrada de hoja y registra una entrada de mapeo inverso para el marco resuelto mediante el nuevo recorrido.

El problema sale a la luz durante la limpieza. Dado que la página principal reutilizada sigue afirmando ser directa, KVM calcula el marco para la nueva entrada de 4 KB como sp->gfn + índice, en lugar de utilizar la traducción en la sombra almacenada. A continuación, busca la entrada del mapa inverso con un número de marco erróneo y no consigue eliminarla. La página en la sombra se libera, pero la entrada obsoleta del mapa inverso permanece. Cualquier operación posterior que recorra ese mapa inverso desreferencia una entrada dentro de la página liberada. El núcleo señala el registro de cambios y la invalidación del notificador de la MMU como las operaciones que provocan esto.

Hay un detalle que explica tanto el PoC público como el exploit que no se ha hecho público. Durante el desmontaje, KVM escribe una constante de marcador fija en lo que ahora podría ser memoria reasignada. Se trata de una verdadera escritura «use-after-free», pero limitada: un valor fijo en una dirección que el atacante tiene que alinear con un objeto útil del núcleo. Es difícil lograr esa alineación de forma fiable, por lo que el código público se limita a provocar un fallo en el host y no se ha publicado el escape completo.

El sistema invitado accede a este código a través de la virtualización anidada. En un host moderno que ejecuta sistemas invitados con paginación de hardware (EPT en Intel, NPT en AMD), la MMU de sombra de software no suele utilizarse. Al activar la virtualización anidada, KVM se ve obligado a recurrir a la MMU de sombra heredada, que es donde se encuentra Januscape. Esa es la razón por la que un host puede parecer moderno y, aun así, estar plenamente dentro del ámbito de aplicación.

Lo que hemos confirmado

Nuestras pruebas han confirmado que se puede acceder a la vulnerabilidad tanto en un kernel de Enterprise Linux como en Ubuntu 24.04. Hemos reproducido el ataque DoS contra el host y la corrupción de memoria. No hemos ejecutado el escape de extremo a extremo, que es el exploit que el investigador ha decidido no divulgar.

En AlmaLinux 9 con el núcleo 5.14.0-687.5.3.el9_8, el desencadenante provocó un error fatal del núcleo en la función pte_list_remove(). El host entró en pánico en un plazo de entre segundos y minutos mientras el proceso activo era qemu-kvm. Se trata de un ataque de denegación de servicio del host, desencadenado de forma fiable por el sistema invitado, en el núcleo probado.

En Ubuntu 24.04 con el núcleo 6.8.0-111-generic, la misma corrupción generó una advertencia en lugar de un pánico inmediato. El núcleo informó de una discrepancia GFN en kvm_mmu_page_set_translation() —lo que puso de manifiesto la confusión de tramas, causa raíz del problema—, seguida de una advertencia posterior en pte_list_remove(). El host sobrevivió porque, en esta versión de Ubuntu, esas comprobaciones de consistencia son de tipo advertencia en lugar de comprobaciones de error fatales, por lo que siguió funcionando con un estado de MMU sombra dañado (Tainted: G W).

Una advertencia que persiste no significa que todo esté en orden. Significa que el estado de la traducción gestionado por el host se ha vuelto incoherente y que la máquina ha superado a duras penas su propia comprobación. Para una recopilación controlada de volcados de memoria tras fallos, puedes hacer que las reproducciones de clase «advertencia» se consideren fatales:

sudo sysctl kernel.panic_on_warn=1

Se trata de una herramienta de pruebas y de asistencia para vmcore. No es una medida de mitigación.

Qué cambia con la corrección de Upstream

La corrección añade la comprobación de rol que faltaba antes de que KVM reutilice una página sombra. Antes del parche, bastaba con que el número de marco del invitado coincidiera para aceptar una página existente. A partir de ahora, la función `kvm_mmu_get_child_sp()` compara el rol completo de la página (role.word) junto con el número de marco, y solo reutiliza una página cuando ambos coinciden. Cuando el rol es incompatible, KVM elimina la entrada existente y crea la página sombra correcta, en lugar de mantener una interpretación obsoleta. Los mantenedores de KVM, Paolo Bonzini y Sean Christopherson, escribieron el parche.

Desde un punto de vista conceptual:

Before:  matching gfn → reuse shadow page → role mismatch ignored → stale reverse map → use-after-free
After:   matching gfn → compare role.word → reject incompatible page → zap old entry → build correct page

La corrección de Januscape en el código fuente original es la confirmación 81ccda30b4e83d8f5cc4fd50503c44e3a33abfeb. Su corrección asociada, la de CVE-2026-46113, es la confirmación 0cb2af2ea66ad8ff195c156ea690f11216285bdf. Cada una de ellas resuelve una condición diferente relacionada con las páginas de sombra obsoletas, por lo que ambas deben incluirse en un núcleo parcheado.

Los registros de los proveedores y de «rebootless-patch» no siempre los identifican por separado. Algunas versiones anteriores de KernelCare incluían la corrección del rol «Januscape» como un componente complementario sin CVE bajo la etiqueta CVE-2026-46113, por lo que la ausencia de una cadena CVE-2026-53359 distinta no significa por sí sola que falte la corrección del rol.

The Sibling: CVE-2026-46113

Januscape no apareció por sí solo. Antes de que se solucionara, los desarrolladores del núcleo cerraron CVE-2026-46113, otra vulnerabilidad de tipo «use-after-free» en el paginado en la sombra de KVM/x86, situada en la misma parte de la MMU. Ambas vulnerabilidades deben analizarse conjuntamente, pero sin confundirlas nunca, ya que las dos correcciones cubren fallos distintos y un servidor necesita ambas.

La vulnerabilidad CVE-2026-46113 se produce cuando KVM reutiliza una página de sombra creada para un número de marco de invitado incorrecto. El mapeo de un invitado cambia entre entradas de máquina virtual; KVM sigue utilizando una página de sombra creada para el mapeo original, y se registra una nueva entrada de tabla de páginas en un marco fuera del rango que KVM busca posteriormente durante la limpieza. La limpieza no la detecta. La página de sombra se libera. La entrada obsoleta del mapa inverso permanece. Un recorrido posterior por el mapa inverso desreferencia la página liberada.

La corrección de CVE-2026-46113, commit 0cb2af2ea66a, añadió una comprobación del número de marco del invitado: cuando KVM detecta que una página existente pertenece a un marco incorrecto, elimina la entrada antigua en lugar de reutilizarla. Januscape demostró que esa comprobación no era suficiente.

En la ruta de Januscape, el número de trama puede parecer correcto. La discrepancia radica en la función de la página de sombra:

La asignación original crea una página de sombra directa para una asignación grande de 2 MB (direct=1).
El invitado modifica esa asignación para que apunte a una tabla de páginas de nivel inferior.
La nueva ruta necesita una página de sombra no directa para asignaciones de 4 KB (directa = 0).
KVM encuentra un número de trama coincidente y reutiliza la página anterior.
El marco coincide, pero la interpretación de la página no.

CVE-2026-46113 solucionó el caso del «frame» incorrecto. Januscape solucionó el caso del «rol» incorrecto. La corrección anterior se refiere al contexto; Januscape es la vulnerabilidad de la que trata este artículo. Aplicar únicamente el parche anterior no soluciona Januscape.

¿A quién afecta?

Januscape afecta a los sistemas Linux que utilizan la MMU «shadow» de KVM/x86. Esto incluye tanto a los hosts Intel como a los AMD, ya que el código vulnerable se encuentra en la lógica compartida de la MMU de KVM/x86 y no únicamente en kvm_intel o kvm_amd. El investigador demostró que el mismo desencadenante funcionaba en ambos, cambiando únicamente los bits de la tabla de páginas específicos de cada arquitectura. Hay varios factores que determinan el grado de vulnerabilidad de un host concreto.

Hipervisores KVM que ejecutan máquinas invitadas con virtualización anidada. Prioridad máxima. Una máquina invitada maliciosa o comprometida que disponga de privilegios de root en su propia máquina virtual puede acceder a la ruta vulnerable del núcleo del host a través de la virtualización anidada. Este es el escenario de fuga de la máquina invitada al host, y es donde una sola instancia alquilada puede bloquear el host físico o, si se retiene el exploit, hacerse con el control de las máquinas invitadas ubicadas en el mismo servidor. En nuestro laboratorio, la reproducción del sistema invitado carga un módulo que controla el estado sin procesar de VMX/SVM, que es precisamente la ruta de la virtualización anidada.

Hosts KVM que ejecutan máquinas invitadas pero no exponen la virtualización anidada. Menor exposición al vector «de la máquina invitada al host», ya que la MMU de sombra del software no se activa de forma forzada para esas máquinas invitadas. Comprueba que la virtualización anidada esté realmente desactivada antes de confiar en esto.

Servidores con KVM disponible pero sin máquinas virtuales en ejecución. Estos pueden seguir exponiendo una ruta local si un usuario local no de confianza puede abrir /dev/kvm y controlar KVM directamente. Si KVM no se utiliza, descargue y bloquee los módulos.

Contenedores y CloudLinux LVE. Un contenedor normal no tiene acceso automático a KVM. Los entornos de contenedores y LVE no son vulnerables por el mero hecho de compartir el núcleo del host. La vulnerabilidad depende de si el contenedor puede acceder a /dev/kvm, controlar QEMU o utilizar virtualización anidada. No hemos probado estos entornos y no los consideramos seguros por defecto. Comprueba la configuración real de los dispositivos y los privilegios.

Versiones del núcleo empresarial. No determines la vulnerabilidad basándote únicamente en el comando «uname -r». Las distribuciones empresariales retroaportan los cambios de KVM a versiones anteriores, por lo que un núcleo EL9 basado en la versión 5.14 contiene la lógica MMU afectada, mientras que un núcleo numéricamente más reciente puede que ya incluya una retroaportación específica. Confirma la corrección del proveedor, la cobertura de KernelCare o el patrón del código fuente para conocer el núcleo exacto que se está ejecutando.

La trampa de la versión en este caso funciona al revés de lo habitual. No se trata de que «nuestro núcleo sea demasiado antiguo», sino de que «nuestro hardware es demasiado nuevo». Un host que utilice EPT o NPT parece moderno y seguro hasta el momento en que expone la virtualización anidada y redirige silenciosamente a los invitados a través de un código de MMU en la sombra con 16 años de antigüedad. Hay que razonar a partir de lo que expone el host, no del silicio en el que se ejecuta.

Comprueba la superficie de ataque del KVM

Comprueba si los módulos KVM están cargados:

lsmod | grep -E '^kvm|kvm_(intel|amd)'

Comprueba si el dispositivo KVM existe y quién tiene acceso a él:

ls -l /dev/kvm

Comprueba si hay cargas de trabajo activas de QEMU/KVM:

pgrep -a -f 'qemu-system|qemu-kvm'

Comprueba si la virtualización anidada está activada:

cat /sys/module/kvm_intel/parameters/nested   # Intel
cat /sys/module/kvm_amd/parameters/nested      # AMD

Para los hosts gestionados por libvirt:

virsh list --all

Estos comandos indican si KVM está expuesto, en uso y si permite la virtualización anidada. No permiten comprobar si Januscape está actualizado.

Actúa ya

Aquí hay medidas de mitigación reales a nivel de configuración, y cada una de ellas bloquea un vector específico. Ninguna de ellas los bloquea todos, y ahí radica precisamente la clave.

Servidores que no ejecutan máquinas virtuales. Si el sistema no necesita KVM, descarga los módulos e impide que se carguen. Utiliza «install … /bin/false» en lugar de una simple línea en la lista negra, ya que la lista negra por sí sola no impide una carga explícita o provocada por dependencias.

# unload now (fails if a VM is running, in which case this host isn't a candidate)
sudo modprobe -r kvm_intel kvm      # kvm_amd on AMD hardware

# prevent load on boot
printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' \
| sudo tee /etc/modprobe.d/disable-kvm.conf

Comprueba que el comando «lsmod | grep kvm» no devuelva ningún resultado y que «ls /dev/kvm» indique que no existe dicho archivo. Para revertir el cambio, elimina el archivo «/etc/modprobe.d/disable-kvm.conf» y ejecuta «modprobe kvm_intel» (o «kvm_amd»), o bien reinicia el sistema.

Hosts que ejecutan máquinas virtuales pero que no necesitan virtualización anidada. Esta es la medida de mitigación más eficaz, salvo la aplicación del parche. Al desactivar la virtualización anidada se elimina la ruta de acceso del invitado al host, ya que la MMU en la sombra solo entra en juego en el caso de los invitados anidados:

# Intel
echo 'options kvm_intel nested=0' | sudo tee /etc/modprobe.d/disable-nested-virt.conf
# AMD
echo 'options kvm_amd nested=0' | sudo tee /etc/modprobe.d/disable-nested-virt.conf

El cambio surtirá efecto tras recargar el módulo KVM (para lo cual es necesario que no haya máquinas virtuales en ejecución) o tras reiniciar el sistema. Compruébalo con el comando `cat /sys/module/kvm_intel/parameters/nested`, que debe devolver «N» o «0».

Equipos de la familia RHEL que deben mantener máquinas virtuales y virtualización anidada. En estas distribuciones, el directorio /dev/kvm viene configurado con permisos de acceso para todos (modo 0666), lo que permite a un usuario local sin privilegios explotar el fallo directamente. Refuerza la seguridad:

echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' \
| sudo tee /etc/udev/rules.d/65-kvm.rules
sudo udevadm control --reload-rules
sudo udevadm trigger --name-match=kvm

Compruébalo con «ls -l /dev/kvm» y «getent group kvm», e incluye en el grupo «kvm» únicamente las cuentas que necesiten KVM. De este modo se cierra el vector de ataque «unprivileged-local». Sin embargo, esto no detiene a un sistema invitado malintencionado, ya que este accede a la MMU oculta a través de su proceso QEMU autorizado, independientemente de los permisos del dispositivo del host.

Momento decisivo. Si un host no ejecuta máquinas invitadas, desinstala y bloquea KVM. Si ejecuta máquinas invitadas que no necesitan virtualización anidada, desactiva ahora mismo la virtualización anidada y aplica los parches con tu periodicidad habitual. Si ejecuta máquinas invitadas no fiables y necesita virtualización anidada —nube multitenant, alojamiento web, CI que crea máquinas virtuales anidadas—, ningún cambio de configuración te protege por completo, así que da prioridad a un parche que no requiera reinicio o a un kernel corregido. Y considera una reproducción que solo genere una advertencia como una confirmación de la vulnerabilidad, no como una prueba de seguridad.

Detección

Januscape no deja ninguna huella fiable en el disco. La corrupción se produce en la memoria del núcleo del host mientras KVM gestiona las tablas de páginas sombra y las asignaciones inversas, por lo que las herramientas de integridad de archivos pueden seguir sin presentar anomalías incluso después de que se active el estado vulnerable. Esto hace que la detección se base en el comportamiento, y cada uno de los siguientes puntos es una pista, no una prueba.

Errores o advertencias del núcleo en arch/x86/kvm/mmu/mmu.c, especialmente los relacionados con pte_list_remove().
Mensajes de «GFN-mismatch» o advertencias de la función `kvm_mmu_page_set_translation()`: la confusión entre el rol y el marco se hace evidente antes de la liberación.
El servidor entra en pánico o sufre fallos repetidos mientras qemu-kvm o qemu-system-* están activos, sin que se produzca ningún fallo de hardware correspondiente.
Un núcleo marcado con «W» tras una advertencia de la MMU de KVM.
Actividad de virtualización anidada donde no te lo esperabas, o acceso a /dev/kvm por parte de cuentas o procesos inusuales.
Una cuenta o servicio local del servidor que obtiene privilegios poco después de un episodio de inestabilidad de la MMU de KVM, sin que se haya registrado ningún evento de «sudo» o de inicio de sesión que lo justifique.

Revisar los mensajes recientes del núcleo:

journalctl -k --since "24 hours ago" \
| grep -Ei 'kvm|mmu|gfn|pte_list_remove|BUG|WARNING'

Revisa el arranque actual:

dmesg -T | grep -Ei 'kvm|mmu|gfn|pte_list_remove|BUG|WARNING'

La ausencia de estos mensajes no demuestra que el host esté actualizado. Un atacante puede evitar que se active la comprobación de consistencia, y es posible que simplemente aún no se haya ejecutado una ruta vulnerable. Si se ejecutan máquinas invitadas no fiables en un host expuesto y se observa inestabilidad en KVM-MMU, se debe considerar que el host requiere un análisis más detallado —cuentas nuevas, configuración de autenticación modificada, servicios inesperados en el host— en lugar de interpretar los hash de los archivos de las máquinas invitadas como prueba de que el host está en buen estado.

Por qué es importante Januscape

Januscape es un tipo de problema distinto al de un fallo de escalada de privilegios del núcleo local. Una escalada de privilegios local convencional requiere que el atacante ya tenga capacidad para ejecutar código en el host. Una fuga del entorno invitado parte de código que la organización ha permitido deliberadamente que se ejecute dentro de una máquina virtual, partiendo de la suposición de que KVM lo contendría. Eliminar esa suposición es la esencia misma del asunto.

Por eso esto afecta con mayor intensidad a los entornos en los que el aislamiento de los usuarios es fundamental: nubes públicas y privadas, proveedores de alojamiento, clústeres multitenant, infraestructura de integración continua (CI) y compilación, entornos de investigación en seguridad, nubes para desarrolladores y cualquier plataforma que ejecute máquinas virtuales controladas por los clientes. La antigüedad de esta suposición subyacente agrava aún más la situación. Este comportamiento se remonta a 2010 y se ha mantenido a lo largo de muchas generaciones de kernels empresariales, por lo que «utilizamos una distribución moderna» no es una excusa válida.

La razón por la que es fácil juzgar mal es la misma por la que resulta peligroso. Tres señales plausibles apuntan todas hacia lo «seguro» y todas inducen a error. El EPT o NPT por hardware da la impresión de haber retirado la MMU en la sombra, pero la virtualización anidada arrastra a los sistemas invitados de vuelta a ella. La corrección de GFN (CVE-2026-46113) da la impresión de haber cerrado este rincón de la MMU, pero en realidad ha subsanado solo la otra mitad del fallo y ha dejado abierto el caso del rol. Y una prueba de concepto (PoC) que solo bloquea un equipo de tu propiedad parece un inofensivo auto-DoS, cuando el bloqueo es la demostración pública y no el límite máximo. Si te fías de cualquiera de ellos, darás por seguro un host vulnerable.

La relación con CVE-2026-46113 es la principal fuente de falsa seguridad. Un equipo que haya corregido el anterior fallo de uso tras liberación (use-after-free) inesperado en GFN podría llegar a la conclusión de que el problema de las páginas sombra ya está resuelto. Pero no es así. La corrección anterior comprobaba si KVM había encontrado el marco correcto. Januscape demostró que KVM también tenía que verificar que había encontrado el tipo correcto de página sombra. Una coincidencia no era suficiente, y el hecho de que se haya cerrado un CVE no significa que se hayan resuelto ambos problemas.

Lista de verificación de medidas correctoras priorizadas

Registra esto como CVE-2026-53359 (Januscape), no como CVE-2026-46113.
Comprueba que los hosts afectados cuenten tanto con la corrección de Januscape como con la corrección asociada CVE-2026-46113. Ambas son necesarias.
Realiza un inventario de los servidores que tengan módulos KVM cargados, el dispositivo /dev/kvm presente o cargas de trabajo activas de QEMU, e identifica aquellos que permitan la virtualización anidada.
Da prioridad a los hosts multitenant y a cualquier host que ejecute máquinas invitadas no fiables con la virtualización anidada activada.
Desactiva por completo KVM en los servidores que no utilicen virtualización.
Desactiva la virtualización anidada cuando no sea necesaria: así se elimina la vía de escape de los invitados no fiables.
Restringe el acceso a /dev/kvm a las cuentas de confianza y al grupo «kvm» en los servidores de la familia RHEL. Esto solo bloquea el vector de ataque local sin privilegios, no un sistema invitado malicioso.
Comprueba explícitamente los servidores AMD: se ven afectados incluso cuando una prueba realizada únicamente con Intel no ha detectado ningún problema.
No se debe deducir la seguridad basándose únicamente en la versión del núcleo, y se debe considerar como una exposición cualquier caso en el que solo se reproduzca una advertencia.
Busca avisos de KVM GFN, fallos en pte_list_remove() y pánicos inexplicables del host, y considera que los hash de archivos de los invitados sin anomalías no constituyen una prueba suficiente sobre el host.
Aplica un kernel fijo del proveedor y reinicia el sistema, o utiliza el parche sin reinicio de KernelCare para el kernel que se esté ejecutando en ese momento, dando prioridad a los hosts que resulten más difíciles de reiniciar.
Comprueba que ambas correcciones cubran explícitamente los CVE, en lugar de basarte en las fechas de compilación.

Parcheo sin reinicio

Januscape es el tipo de fallo en un hipervisor que permanece expuesto mucho tiempo después de que ya esté disponible un paquete corregido. Instalar el paquete es solo el primer paso. El host aún tiene que arrancar con el kernel de sustitución, y en un clúster KVM eso implica vaciar los nodos, migrar los sistemas invitados, coordinar a los inquilinos, mantener márgenes de capacidad y rotar las máquinas durante el mantenimiento. Esas limitaciones pueden prolongar una fuga conocida de un sistema invitado durante semanas o meses de exposición residual, y son más gravosas precisamente en los hosts multinquilino que corren mayor riesgo.

Este cambio es un buen candidato para un parche sin reinicio: se trata de una pequeña corrección en la ruta de error y de mapeo inverso de la MMU, sin ningún estado persistente que se deba conservar. KernelCare integra ambas correcciones necesarias —la corrección del rol Januscape (81ccda30b4e8) y la corrección complementaria de GFN (0cb2af2ea66a)— en el núcleo en ejecución, con variantes por familia de núcleos para las líneas de retroportabilidad de EL 5.14 y los núcleos 6.x basados en la rama principal. LibCare no se aplica, ya que se trata de un error exclusivo del núcleo sin ningún componente de biblioteca del espacio de usuario.

Situación de la versión a fecha de 29 de julio de 2026.

KernelCare distribuye conjuntamente la corrección de la vulnerabilidad «Januscape» y la corrección complementaria necesaria para CVE-2026-46113, por lo que la disponibilidad se indica por familia de kernel y no por CVE.

Estable, totalmente promocionado

RHEL 10 – conjunto de parches K20260703_15

Oracle Linux 10 – K20260703_16

Rocky Linux 10 – K20260703_17

AlmaLinux 10 – K20260703_18

Debian 13 – K20260706_09

Ubuntu 22.04 – K20260706_01 (_02 para arm64, _03 para Azure, _04 para AWS)

Ubuntu 20.04 con el kernel Jammy HWE – K20260706_06 (Azure: _05, AWS: _07)

Ubuntu 24.04 – K20260707_01 (AWS: _02)

Proxmox VE 7 (5.15) – K20260706_08

Proxmox VE 8 (6.8) – K20260707_03

Enterprise Linux 9, lanzado en julio de 2026

RHEL 9 – K20260710_58

AlmaLinux 9 y CloudLinux 9 – K20260710_60

Oracle Linux 9 – K20260710_63

Rocky Linux 9 – K20260710_65

Implantación por fases

Debian 12 – K20260709_25

Debian 11 – K20260710_11

Kernel estándar de Ubuntu 20.04 – K20260710_10

CloudLinux 8 – K20260709_27

En fase de pruebas

RHEL 8 – K20260710_31

AlmaLinux 8 – K20260710_41

Rocky Linux 8 – K20260710_43

CentOS 8 – K20260710_33

Oracle Linux 8 – K20260710_35

CloudLinux 7 híbrido – K20260710_39

Aún abierto

Oracle UEK6, Oracle UEK7, Amazon Linux 2, Ubuntu 18.04.

Enterprise Linux 7 se ve afectado, pero no hay prevista ninguna actualización. El impacto práctico se limita únicamente a la denegación de servicio: un ataque DoS de inquilino a host no es viable, ya que el VMX anidado es lo suficientemente lento como para que la carrera de ejecución no sea fiable, y la vía de escalada de privilegios local está bloqueada por CONFIG_BUG_ON_DATA_CORRUPTION. Los hosts que ejecuten EL7 deben seguir aplicando las medidas de mitigación de configuración mencionadas anteriormente.

Ya está disponible la cobertura de Enterprise Linux 9 para RHEL 9, AlmaLinux 9 y CloudLinux 9, Oracle Linux 9 y Rocky Linux 9. Esto es importante porque EL9 es la plataforma en la que se produjo un fallo fatal de pánico del host en nuestro laboratorio, por lo que los hosts con EL9 expuestos siguen siendo los primeros en recibir el parche; sin embargo, ya no tienen que recurrir a medidas de mitigación de configuración mientras esperan a que esté disponible el parche. Las plataformas que aún no están cubiertas son Oracle UEK6 y UEK7, Amazon Linux 2 y Ubuntu 18.04; esos servidores siguen dependiendo de las medidas de mitigación mencionadas anteriormente o de un kernel corregido por el proveedor.

Aplicar desde el feed de pruebas:

sudo kcarectl --update --prefix test

Aplicar desde el canal de producción una vez que se haya promocionado:

sudo kcarectl --update

Confirma la compilación del parche en ejecución:

kcarectl --info | grep kpatch-build-time      # build dated 2026-07 or later

Dado que Januscape necesita ambas correcciones, comprueba que ambas estén presentes en lugar de fiarte de una fecha:

kcarectl --patch-info | grep -E

'CVE-2026-53359|CVE-2026-46113'

Dos coincidencias constituyen una respuesta clara. Una sola coincidencia con CVE-2026-46113 no es, por sí sola, prueba de que falte la corrección de roles, debido al historial de etiquetado mencionado anteriormente; en ese caso, comprueba la etiqueta K instalada con la lista de versiones anterior o el registro de cobertura de KernelCare para esa familia de kernels. La fecha de compilación por sí sola no prueba nada. Un núcleo compilado después de mediados de junio no incluye automáticamente esta corrección, y no garantiza que ambas correcciones estén presentes. Verifica la correspondencia con el CVE, la etiqueta K, la errata del proveedor o el código fuente directamente.

Januscape convierte una sutil discrepancia entre las páginas de sombra KVM en un fallo del límite entre el sistema invitado y el host. Para los parques de virtualización que no pueden permitirse reinicios de emergencia, un parche sin reinicio cierra ese límite en el núcleo en ejecución sin tener que apagar todos los nodos ni interrumpir los sistemas invitados.

Consigue KernelCare hoy mismo →