Zapscape y SCTPhantom: tu Proxmox no lleva el kernel de Debian

Esta semana se han publicado dos fallos del kernel Linux con nombre propio. Zapscape deja salir de una máquina virtual KVM y quedarse con el anfitrión. SCTPhantom convierte a un usuario sin privilegios en root y se lleva por delante la frontera del contenedor. Entenderlos cuesta veinte minutos. La pregunta que de verdad nos ocupó la mañana fue otra: ¿el kernel que arranca nuestros nodos ya los lleva corregidos? Y esa pregunta no la responde ninguna de las dos fichas.

Escribimos esto desde el lado del que tiene que aplicarlo. Operamos Proxmox VE con almacenamiento Ceph en producción, repartido en varios datacenters, así que el aviso no era una lectura: era una lista de nodos que tocaba reiniciar. Y al ir a comprobar lo obvio nos encontramos con el hueco del que va este artículo, que no es técnico sino de procedimiento, y que se repite en muchísimos sitios más allá de Proxmox.

Zapscape: salir de la máquina virtual

CVE-2026-64561 es un uso después de liberar en la emulación del shadow MMU de KVM en x86, concretamente en la ruta recursiva de zap que se ejecuta cuando KVM recicla páginas de sombra. El mensaje del parche lo cuenta sin adornos: hay que comprobar si la raíz es inválida u obsoleta después de dejar disponibles páginas de MMU, no antes, porque «si al reciclar páginas de sombra se destruye una raíz en uso, KVM intentará mapear memoria en una raíz inválida», y las páginas hijas heredan el rol del padre, de modo que se crean inválidas y acaban en la lista de páginas activas, que es justo lo que KVM prometía que no pasaría nunca. El arreglo es mover la comprobación detrás de make_mmu_pages_available().

Lo que hace falta para llegar ahí importa mucho, y conviene decirlo antes que el impacto: privilegio de kernel dentro del invitado L1 —en la práctica, root en la máquina virtual— y virtualización anidada, porque es lo que fuerza a KVM a usar el shadow MMU en lugar de la paginación asistida por hardware. En Intel hace falta además que a ese invitado se le hayan expuesto los recorridos de página EPT de cuatro y de cinco niveles; en AMD no hay condición equivalente. El investigador Hyunwoo Kim, a quien se acredita el hallazgo, publicó una prueba de concepto funcional contra AMD que demuestra la cadena completa sobre QEMU en modo TCG con tres capas apiladas (L0, L1 y L2). Red Hat le ha puesto de momento un 7,0 preliminar.

Hay un segundo camino que se menciona menos y que en algunos servidores es el que de verdad escuece: donde /dev/kvm es accesible para usuarios normales, no hace falta ser inquilino de nadie. Cualquiera con una cuenta puede crear una máquina virtual desechable y atacar al anfitrión desde dentro de ella. El fallo vive en el KVM del kernel, así que la versión de QEMU que uses da igual.

SCTPhantom: dieciocho años esperando

CVE-2026-64564 está en la reconfiguración dinámica de direcciones de SCTP, el mecanismo ASCONF que permite a una asociación añadir, quitar o recolocar rutas de red sobre la marcha. El kernel valida el borrado de una dirección usando la dirección de origen del paquete, pero mantiene aparte un puntero cacheado que apunta al transporte elegido por el parámetro de dirección del propio mensaje. Esas dos identidades no tienen por qué coincidir. Un solo ASCONF que lleve, en orden, [parámetro L] [DEL-IP L] [DEL-IP 0.0.0.0] supera la comprobación existente, libera el transporte al que sigue apuntando el puntero cacheado y luego lo reutiliza: la asociación acaba con cero transportes y con la ruta primaria apuntando a memoria liberada.

Lo firma el Zhuque Lab de Tencent, que le asigna un 8,5 en CVSS 4.0 con vector local (AV:L/PR:L) y dice haber conseguido root en los kernels que probó de Debian 13, Ubuntu 24.04, OpenCloudOS y Rocky Linux 9 y RHEL 9 —estos dos últimos, con el módulo SCTP cargado a mano—. La parte que más nos interesó es el escape de contenedor: la cadena llega a ejecución en los espacios de nombres iniciales sin necesitar CAP_NET_ADMIN ni CAP_SYS_ADMIN, con seis aciertos de ocho intentos. Y el código defectuoso se remonta a Linux 2.6.25, diciembre de 2007. Dieciocho años.

La antigüedad impresiona y conviene desinflarla un poco, porque no mide riesgo. En el propio parche de Zapscape hay una nota que lo explica mejor que nosotros: el defecto de fondo existía desde que KVM empezó a llevar la cuenta de raíces inválidas en 2008, pero «la verdadera maldad» solo apareció en 2020, con Linux 5.9, cuando se añadió la garantía que ahora se rompe. Dicho de otro modo: un fallo puede llevar años en el código sin ser explotable, y volverse explotable el día que alguien introduce, con toda la buena intención, una optimización a su alrededor. Que llevara dieciocho años ahí no significa que alguien los llevara usando.

La pregunta incómoda: ¿estoy parcheado?

Las versiones corregidas que circulan en todas las coberturas son estas: 6.6.148, 6.12.101, 6.18.42, 7.1.6 y la 7.2-rc5 de desarrollo. Ahora ejecuta uname -r en un nodo Proxmox VE. Va a responder algo parecido a 6.8.12-x-pve, 6.14.11-x-pve, 6.17.13-x-pve o 7.0.14-x-pve. Ninguna de esas ramas aparece en la lista. Ni para bien ni para mal: simplemente no son las mismas ramas.

Debian publicó el aviso DSA-6415-1, que cierra ambos fallos en trixie con el paquete linux en versión 6.12.101-1. Perfecto, salvo por un detalle: ese no es el kernel que arranca tu nodo. Proxmox VE es Debian, pero su kernel no viene de Debian, viene de Ubuntu. Lo dice su propia documentación: Proxmox VE 9.0 se basó en el 6.14 derivado de Ubuntu 25.04, Proxmox VE 9.1 pasó al 6.17 derivado de Ubuntu 25.10 y Proxmox VE 9.2, publicado el 21 de mayo de 2026, estrenó el kernel 7.0 como nuevo estándar, también derivado de Ubuntu. Puedes tener el paquete linux de Debian perfectamente actualizado en la máquina y no arrancarlo jamás.

Vale para cualquier sistema con kernel de fabricante —una cabina de almacenamiento, un NAS—: la ficha del CVE y el aviso de tu distribución te dicen que el fallo existe, no si el binario que tú arrancas lo lleva corregido.

La respuesta, con números: el -9 no basta

La respuesta está en el repositorio de pve-kernel, no en ningún boletín. En la rama 7.0, que es la que lleva Proxmox VE 9.2, el historial es explícito:

• 7.0.14-9 — «cherry-pick fix for CVE-2026-64561». Aquí entra Zapscape, junto con los arreglos de CVE-2026-64562 y CVE-2026-64047 y otros que el propio commit agrupa como «further CVEs».
• 7.0.14-10 — «backport sctp: don't free the ASCONF's own transport…». Ese es SCTPhantom, y llega en el bump siguiente.
• 7.0.14-11 — un backport adicional de x86/bugs («Make Safe-RET robust against interrupts»). Es la última publicada mientras escribimos esto: si vas a reiniciar, reinicia a esta.

De ahí sale el dato práctico de todo el artículo: si te quedaste en 7.0.14-9 tienes Zapscape corregido y SCTPhantom no. Dos fallos con nombre, dos bumps consecutivos, y una diferencia de un dígito que no aparece en ninguna noticia. Quien reinició en cuanto vio el primero se ha ganado un segundo reinicio; quien esperó un día se ahorró una ventana. Conviene además mirar de qué repositorio comes: el -9 apareció primero en pve-test y solo al día siguiente en pve-no-subscription, y la de suscripción suele ir por detrás.

¿Y si no estás en la 7.0? Aquí es donde este artículo se habría quedado a medias, porque el mismo git responde por las otras ramas. En Proxmox VE 8.x, el personal de Proxmox indica en su foro que Zapscape queda cubierto en proxmox-kernel-6.8.12-40-pve, y ojo, porque ahí se repite el patrón exacto: el backport de SCTP entra en el bump siguiente, 6.8.12-41, junto con el mismo arreglo de x86/bugs. Con el -40 tienes Zapscape; SCTPhantom empieza en el -41. Y en las ramas 6.17 (Proxmox VE 9.1) y 6.14 (Proxmox VE 9.0) el git es elocuente por omisión: no registran ningún commit relacionado con estos dos fallos, y su último movimiento es del 20 de julio y del 15 de mayo respectivamente. Si estás ahí, todavía no lo tienes.

Cómo se comprueba en tu nodo

Cuatro órdenes. Las dos primeras dicen lo que corre; las dos últimas, lo que tienes puesto:

uname -r                              # lo que corre AHORA, en memoria
pveversion -v | grep -i kernel        # versión de Proxmox y kernel activo
apt list --installed 'proxmox-kernel-*'   # lo que está INSTALADO en disco
proxmox-boot-tool kernel list         # kernels sincronizados al ESP (si usas proxmox-boot-tool)

La cuarta solo aplica si el arranque lo gestiona proxmox-boot-tool —instalaciones sobre ZFS o con systemd-boot—; en una instalación con GRUB clásico no te va a servir. Y lista los kernels que se sincronizan al ESP, no cuál ganará el arranque: eso se fija con proxmox-boot-tool kernel pin.

Un kernel instalado no es un kernel arrancado. Escribimos hace unos días sobre el ritmo de parcheo de Chrome y la brecha entre descargar la actualización y reiniciar el navegador; aquí es lo mismo pero sin margen de interpretación, porque un kernel solo entra reiniciando. No hay parcheo en caliente que valga en un despliegue Proxmox estándar.

En un clúster, el reinicio es el trabajo de verdad. Nuestro orden es siempre el mismo: migrar en vivo las cargas del nodo, vaciarlo, y solo entonces reiniciar. Si hay Ceph por debajo, poner noout antes de tocar nada evita que el clúster empiece a rebalancear terabytes porque un nodo lleva cuatro minutos fuera. Y después del arranque, comprobar que uname -r dice lo que esperabas antes de pasar al siguiente nodo. El resto del criterio con el que dejamos un clúster listo está en el checklist de hardening que publicamos.

Quién tiene que correr y quién no

Aquí es donde nos separamos del tono de las coberturas. Zapscape necesita que alguien tenga privilegio de kernel dentro de un invitado y que ese invitado tenga virtualización anidada disponible. Si todas las máquinas virtuales de tu clúster son tuyas o de tu cliente, si nadie ajeno tiene root dentro de ellas y si no expones anidamiento, esto es una ventana de parcheo ordinaria, no una emergencia de sábado. Decirlo al revés vende más artículos, pero desgasta la credibilidad del que luego avisa de algo urgente de verdad.

Ahora, si vendes VPS, si entregas máquinas virtuales a terceros con root dentro, si mantienes anidamiento encendido para laboratorios o formación, o si /dev/kvm está abierto a usuarios normales en una máquina compartida: ahí sí, esto se parchea ya. La diferencia entre los dos escenarios no es el fallo, es quién tiene root dentro de tus invitados, que es una pregunta de diseño y no de seguridad reactiva.

SCTPhantom tiene un freno parecido y menos conocido: hace falta que SCTP esté alcanzable. En la lista oss-security, Solar Designer matizó que en la familia RHEL el módulo llega en kernel-modules-extra con blacklist sctp y blacklist sctp_diag, de modo que el administrador tiene que instalarlo y cargarlo a propósito para quedar expuesto. En Debian y Ubuntu, en cambio, Tencent obtuvo root en las instalaciones que probó. La comprobación cuesta un segundo: lsmod | grep sctp.

Fronteras de gestión, no muros

Lo que nos parece más interesante del par no es ninguno de los dos fallos por separado, sino lo que dicen juntos. Uno rompe la máquina virtual, el otro rompe el contenedor, y los dos aparecen la misma semana en el mismo kernel. Son las dos fronteras sobre las que apoyamos casi todo, y las dos son, en el fondo, código C que alguien escribió hace años.

La conclusión que sacamos no es dejar de confiar en la virtualización —sería absurdo, la operamos todos los días— sino tratarla como lo que es: una frontera de gestión excelente y una frontera de seguridad razonable pero no absoluta. Eso cambia decisiones concretas: no mezclar en el mismo anfitrión cargas con niveles de confianza muy distintos, no dejar anidamiento encendido «por si acaso», y no tratar «está en otra VM» como equivalente a «está en otra máquina». La misma lógica que aplicamos al decidir cuándo un clúster tiene que partirse en dos: lo que separa de verdad es la frontera que has elegido, no la que das por supuesta.

Lo que no haríamos

• Reiniciar el clúster entero a la vez. Nodo a nodo, migrando y comprobando. Un fallo local que exige estar dentro no justifica quedarse sin quórum a media tarde.
• Dar por parcheado el nodo porque salió el aviso de la distribución. Es el error concreto que motiva este artículo. Comprueba la versión del kernel que arrancas, no la del paquete que existe.
• Bloquear SCTP a ciegas. Para la mayoría de servidores es una limpieza sensata, pero si operas señalización de telecomunicaciones el protocolo está en uso de verdad. Mira lsmod antes de escribir un blacklist.
• Tratar «no está siendo explotado» como un permiso indefinido. Hay prueba de concepto pública para Zapscape. Su autor avisa de que no es un exploit listo para usar —hay que llevar las acciones de L1 a un módulo del kernel invitado y portarlo al kconfig del anfitrión—, pero añade en la misma frase que no es una tarea difícil. Eso acorta el plazo aunque hoy no haya campañas.

La parte aburrida de esto es la que realmente decide el resultado: saber qué kernel arranca cada máquina, tener una ventana en la que reiniciar sin pedir permiso a nadie y que alguien mire el historial del fabricante cuando el boletín genérico no llega. Es exactamente el trabajo del mantenimiento de un parque gestionado, y no se nota hasta la semana en que hacen falta dos reinicios seguidos por un dígito de diferencia. Si quieres que revisemos cómo está tu virtualización, escríbenos.