Problema

En entornos de homelab o producción ligera es frecuente ejecutar máquinas virtuales dentro de otras máquinas virtuales (nested virtualization) para probar hipervisores, CI/CD o laboratorios de seguridad. Cuando KVM está habilitado con la opción nested=1, el código de shadow paging del kernel se vuelve un punto crítico: una vulnerabilidad en esa ruta puede provocar un host crash sin necesidad de privilegios de root dentro del guest. La vulnerabilidad CVE‑2026‑53359, conocida como “Januscape”, es un ejemplo reciente que permite a un atacante dentro de una VM anidada ejecutar código que corrompe la tabla de páginas del host y lo reinicia.

El patrón es claro: cualquier kernel Linux con KVM y nested habilitado está expuesto a fallos de aislamiento que pueden ser explotados por código dentro del guest. El impacto varía desde un simple panic hasta la pérdida de datos si el host no está preparado para reiniciar de forma controlada.

Causa

  1. Shadow paging en modo nested
    KVM mantiene una copia “shadow” de la tabla de páginas del guest para traducir direcciones de manera eficiente. Cuando la virtualización está anidada, esa capa se vuelve recursiva y el kernel debe validar cada actualización de página dos veces. Un error de validación permite que una escritura maliciosa del guest sobrescriba estructuras críticas del host.

  2. Falta de parche en versiones de kernel distribuidas por Proxmox
    Proxmox utiliza kernels personalizados (proxmox‑kernel‑6.8.x‑pve, proxmox‑kernel‑7.0.x‑pve). Si el repositorio no ha recibido el parche de seguridad, la vulnerabilidad permanece activa.

  3. Configuración de “nested” global
    Muchos usuarios habilitan nested=1 a nivel de módulo (modprobe kvm_intel nested=1) o mediante sysctl sin distinguir entre VMs de confianza y VMs de prueba. Esa configuración global amplía la superficie de ataque.

  4. Entornos de multi‑tenant
    Cuando varios usuarios comparten un mismo host y algunos ejecutan workloads no confiables, la probabilidad de que un atacante aproveche la vulnerabilidad aumenta.

Solución

La estrategia se divide en tres capas: parchear, limitar la exposición y validar.

1. Aplicar el parche de kernel

Los repositorios oficiales de Proxmox publicaron versiones corregidas (proxmox‑kernel‑6.8.12‑33‑pve, proxmox‑kernel‑7.0.14‑4‑pve). Actualizar el kernel y reiniciar el host elimina la vulnerabilidad en el código de shadow paging.

2. Desactivar nested para VMs no confiables

Si no puedes actualizar inmediatamente o prefieres una defensa en profundidad, desactiva la virtualización anidada en los dominios que no la necesiten. En Proxmox esto se hace a nivel de VM con la opción nested=0 o mediante la variable de arranque cpu: host,flags=-nested. Para hosts que usan libvirt o QEMU directamente, el flag -cpu host debe omitirse o añadirse -cpu <model>,+nesting=off.

3. Aplicar políticas de host hardening

  • Bloquear módulos de KVM para usuarios que no requieran nested: echo "install kvm_intel /bin/true" > /etc/modprobe.d/disable-nested.conf.
  • Usar AppArmor o SELinux para restringir los permisos de los procesos QEMU.
  • Mantener backups de configuración antes de cualquier cambio de kernel.

4. Automatizar la detección de versiones vulnerables

Un script sencillo que consulte la versión del kernel y compare contra la lista de parches permite alertar antes de que una VM arranque.

Cuándo aplicar esta solución

  • Síntomas: host se reinicia inesperadamente al iniciar una VM anidada, logs de kernel muestran KVM: nested seguido de Oops o panic.
  • Entornos multi‑tenant donde no todos los usuarios pueden confiar en el código que ejecutan.
  • Laboratorios de pruebas que usan nested para validar hipervisores o herramientas de seguridad.
  • Situaciones de mantenimiento donde el host está ejecutando una versión de kernel anterior al parche publicado.

No aplicar si todos los workloads son de confianza absoluta y el host ya está ejecutando una versión de kernel posterior al 6.8.12‑33‑pve o 7.0.14‑4‑pve. En ese caso, la desactivación de nested podría romper funcionalidades críticas (por ejemplo, pruebas de KVM dentro de KVM).

Código

# 1. Verificar versión actual del kernel
uname -r

# 2. Instalar el kernel corregido (ejemplo para repositorio Proxmox)
apt update && apt install proxmox-kernel-6.8.12-33-pve proxmox-kernel-7.0.14-4-pve

# 3. Reiniciar al nuevo kernel
reboot

# 4. Desactivar nested globalmente (opcional, para usuarios no confiables)
echo "options kvm_intel nested=0" > /etc/modprobe.d/kvm-nested.conf
modprobe -r kvm_intel
modprobe kvm_intel

# 5. Desactivar nested por VM (ejemplo en Proxmox CLI)
qm set 101 -cpu host,flags=-nested

Verificación

  1. Comprobar que el kernel está parcheado

    uname -r | grep -E '6\.8\.12-33-pve|7\.0\.14-4-pve'

    La salida debe contener la versión exacta del parche.

  2. Confirmar que nested está desactivado

    cat /sys/module/kvm_intel/parameters/nested

    El valor debe ser N.

  3. Probar una VM anidada

    • Crea una VM con nested=0.
    • Dentro de esa VM intenta ejecutar el PoC de Januscape (si lo tienes).
    • El host no debe reiniciarse; el proceso debe fallar con un error de permiso.

  4. Revisar logs

    journalctl -k | grep -i kvm

    No debe haber mensajes de panic ni Oops relacionados con shadow paging.

Notas adicionales

  • Reboot obligatorio: la sustitución del kernel requiere reinicio completo; planifica una ventana de mantenimiento para evitar interrupciones.
  • Impacto en VMs de prueba: desactivar nested puede impedir que algunos laboratorios de CI/CD ejecuten contenedores dentro de VMs. Evalúa si esa limitación es aceptable.
  • Rollback: si el nuevo kernel introduce incompatibilidades, mantén la versión anterior disponible en el menú de GRUB y arranca desde ella mientras investigas.
  • Monitoreo continuo: integra la verificación de versión de kernel en tu sistema de monitoring (Zabbix, Prometheus) para recibir alertas cuando un host quede sin parchear.
  • Entorno de producción: en clústers de alta disponibilidad, actualiza nodos uno a uno y verifica la estabilidad antes de pasar al siguiente. La pérdida de un nodo por crash inesperado puede desencadenar failover no deseado.

Con estos pasos, cualquier administrador de Proxmox o KVM puede reducir significativamente el riesgo asociado a vulnerabilidades de kernel en entornos de virtualización anidada, sin depender de un caso puntual.