Escape de invitado en el hipervisor Xen (CVE-2026-102703, CVE-2026-102704)

TL;DR

• Dos fallas de validación del grant copy de Xen permiten a un invitado malicioso leer y escribir memoria de otros dominios, incluido Dom0, el dominio de control. El Xen Project publicó el aviso XSA-523 el 3 de noviembre de 2026.
• Todas las versiones de Xen desde 4.6 están afectadas, y Xen 4.5 y anteriores no lo están. No se conoce ninguna mitigación.
• El aviso no da ninguna puntuación CVSS. No se conoce explotación. Ninguna de las dos CVE figura en el catálogo Known Exploited Vulnerabilities (KEV) de la Cybersecurity and Infrastructure Security Agency (CISA) al 4 de noviembre de 2026.
• Aplique los parches XSA-523, de 4.17 hasta unstable, a la última revisión de su rama estable, o instale la actualización de su proveedor de plataforma. Ningún tarball publicado de Xen los incluye todavía. Vea «¿Cómo corregirlo?».

¿Está afectado?

Está expuesto cuando se cumplen todas estas condiciones:

• Ejecuta el hipervisor Xen, versión 4.6 o cualquier versión posterior. El aviso indica que todas las versiones desde 4.6 son vulnerables, y que 4.5 y anteriores no lo son.
• Su despliegue ejecuta invitados no confiables. Cualquier invitado que opere una grant table puede emitir las operaciones de copia vulnerables.
• Todavía no ha aplicado los parches XSA-523. La resolución del aviso es el conjunto de parches; ningún tarball publicado de Xen lo incluye al 4 de noviembre de 2026.

Los invitados son aquí el atacante, no la víctima de un atacante de red. Un invitado cuya memoria es leída o escrita por un vecino malicioso no ve ningún indicio de ello.

XCP-ng es una plataforma del Xen Project, y su documentación indica que está construida en torno al hipervisor Xen. Compruebe lo que su equipo ejecuta realmente:

# On the host (dom0): the running Xen version
xl info | grep '^xen_version'

# In a Linux guest: confirms the hypervisor type (prints "Xen" under Xen)
cat /sys/hypervisor/type 2>/dev/null

# In a Linux guest: the hypervisor version the guest was told
cat /sys/hypervisor/version/major 2>/dev/null
cat /sys/hypervisor/version/minor 2>/dev/null

La versión indica si un equipo está en el rango afectado, y todas las versiones desde 4.6 lo están. No puede indicar si los parches XSA-523 están aplicados, porque ninguna versión publicada los incluye. Consulte en su lugar el aviso o el registro de cambios del paquete de su proveedor para XSA-523.

En una nube gestionada, la vista del invitado puede ir por detrás del estado de parcheo del equipo. Pida a su proveedor el estado XSA-523 del equipo si ejecuta invitados no confiables en él.

¿Cómo corregirlo?

1. Si compila Xen desde una rama estable, actualice primero la rama hasta su última revisión y luego aplique los parches XSA-523. Recompile Xen y reinicie el equipo con el hipervisor parcheado. El aviso señala que los parches están preparados para las ramas estables y pueden no aplicarse limpiamente sobre un tarball de versión.
2. Si ejecuta un Xen empaquetado por un proveedor de plataforma o una distribución, aplique la actualización del proveedor cuando se publique y luego reinicie el equipo. Ningún tarball publicado de Xen llevaba la corrección al 4 de noviembre de 2026.
3. Recree invitados solo en la medida en que su plan de recuperación lo exija. Aplicar el parche del hipervisor detiene ataques futuros; no le dice si ocurrió uno anterior.

No existe ninguna solución de configuración. El aviso lo dice: «There is no known mitigation» (no se conoce ninguna mitigación).

¿Cuál es la causa raíz?

El hypercall de grant copy permite a un invitado copiar datos entre grant references y números de trama de máquina. Por rendimiento, el commit d28f42f2703e («grant-table: defer releasing pages acquired in a grant copy») hizo que Xen almacenara en caché la descripción validada del elemento anterior del lote. Ese commit llegó por primera vez en Xen 4.6.0, lo que coincide con el rango vulnerable del aviso.

Un lote de operaciones grant copy suele actuar sobre rangos de direcciones adyacentes en la misma página de origen o destino. La caché se reutiliza cuando el siguiente elemento parece equivalente. Ambas fallas son condiciones incorrectas para esa reutilización, según la descripción del aviso.

CVE-2026-102703 es la comprobación de validez de la caché. En gnttab_copy_buf_valid(), p es el origen o destino del nuevo elemento, y b es el búfer en caché. has_gref indica si el nuevo elemento usa una grant reference (GREF). El código vulnerable es xen/common/grant_table.c, líneas 3082 a 3091, en xen-unstable antes de los parches:

static bool gnttab_copy_buf_valid(
    const struct gnttab_copy_ptr *p, const struct gnttab_copy_buf *b,
    bool has_gref)
{
    if ( !b->virt )
        return 0;
    if ( has_gref )
        return b->have_grant && p->u.ref == b->ptr.u.ref;
    return p->u.gmfn == b->ptr.u.gmfn;
}

El campo ->have_grant indica si la entrada en caché procede de una grant reference. El código solo lo comprueba en la ruta de grant references, antes de comparar GREF. La ruta de tramas de máquina compara p->u.gmfn == b->ptr.u.gmfn sin comprobar que la entrada en caché fuera también una entrada de trama.

La descripción del parche indica la consecuencia: una GREF de un elemento anterior del lote, probablemente inválida, puede tomarse por un número de trama de máquina (MFN) posiblemente válido.

CVE-2026-102704 es la comprobación de permisos. Copiar por número de trama, en lugar de por grant reference, solo se permite al operar sobre la memoria del propio llamador. Antes de los parches, gnttab_copy_lock_domain() impone esta regla, en las líneas 2939 a 2946 del mismo archivo:

static int gnttab_copy_lock_domain(domid_t domid, bool is_gref,
                                   struct gnttab_copy_buf *buf)
{
    /* Only DOMID_SELF may reference via frame. */
    if ( domid != DOMID_SELF && !is_gref )
        return GNTST_permission_denied;

    buf->domain = rcu_lock_domain_by_any_id(domid);

gnttab_copy_one() solo llega a esa comprobación cuando vuelve a bloquear los dominios, en las líneas 3140 a 3150. Aquí op es el elemento actual del lote, y src y dest son los búferes de origen y destino en caché:

    if ( !src->domain || op->source.domid != src->ptr.domid ||
         !dest->domain || op->dest.domid != dest->ptr.domid )
    {
        gnttab_copy_release_buf(src);
        gnttab_copy_release_buf(dest);
        gnttab_copy_unlock_domains(src, dest);

        rc = gnttab_copy_lock_domains(op, src, dest);
        if ( rc < 0 )
            goto out;
    }

Un elemento que nombra los mismos dominios que el elemento anterior se salta este bloque. Su copia por número de trama nunca se compara entonces con DOMID_SELF.

¿Cómo se explota?

Para CVE-2026-102703:

1. El invitado malicioso emite un lote GNTTABOP_copy. Un elemento anterior copia por grant reference, así que la caché contiene una entrada de grant validada.
2. Un elemento posterior del mismo lote copia por número de trama de máquina, así que Xen compara su número de trama con la entrada en caché.
3. La comparación no comprueba que la entrada en caché fuera una entrada de trama. La grant reference anterior se toma por un número de trama, y Xen reutiliza el búfer en caché.
4. La copia lee o escribe entonces una memoria que el invitado no puede legítimamente direccionar, perteneciente a otros dominios, incluido Dom0.

Para CVE-2026-102704:

1. El invitado malicioso emite un lote de copia. Un elemento inicial nombra un dominio ajeno por grant reference, lo que pasa la comprobación, y Xen bloquea ese dominio.
2. Un elemento posterior nombra el mismo dominio pero copia por número de trama. gnttab_copy_one() se salta el paso de bloqueo de dominio, así que la comprobación «solo DOMID_SELF puede referenciar por trama» nunca se ejecuta.
3. El invitado direcciona directamente por número de trama de máquina la memoria de otro dominio, sin grant.

Ninguno de los dos caminos exige una configuración especial del invitado, solo una grant table funcionando. No hay prueba de concepto pública, y los propios parches documentan el comportamiento alcanzable.

¿Cómo fluye el ataque?

Un lote de operaciones de grant copy reutiliza un estado en caché, y cualquiera de dos comprobaciones que faltan por elemento deja al invitado direccionar la memoria de otro dominio.

¿Qué puede hacer un atacante?

En palabras del aviso, un invitado malicioso puede leer y escribir memoria arbitraria perteneciente a otros dominios, incluido Dom0. Es la afirmación más fuerte que las fuentes permiten.

En la práctica, ese acceso podría exponer secretos guardados en la memoria de otro invitado o modificar el código y los datos de otro invitado. Ninguna fuente pública demuestra un ataque así. El aviso no da ninguna puntuación CVSS, y no se reporta ningún abuso real.

El atacante necesita controlar un invitado en un equipo sin parchear. Los equipos que ejecutan solo invitados de confianza solo están expuestos si uno de esos invitados se compromete primero.

¿Por qué funciona la corrección?

El parche de CVE-2026-102703 rechaza la reutilización de la caché cuando el modo de direccionamiento del nuevo elemento difiere del almacenado:

 static bool gnttab_copy_buf_valid(
     const struct gnttab_copy_ptr *p, const struct gnttab_copy_buf *b,
     bool has_gref)
 {
-    if ( !b->virt )
+    if ( !b->virt || b->have_grant != has_gref )
         return 0;
     if ( has_gref )
-        return b->have_grant && p->u.ref == b->ptr.u.ref;
+        return p->u.ref == b->ptr.u.ref;
     return p->u.gmfn == b->ptr.u.gmfn;
 }

Una grant reference ya no puede compararse con, ni confundirse por, un número de trama de máquina. La comprobación es completa para la falla reportada: la caché solo se consulta cuando los modos de direccionamiento coinciden.

El parche de CVE-2026-102704 elimina la comprobación DOMID_SELF de gnttab_copy_lock_domain() y la añade a gnttab_copy_claim_buf():

         buf->ptr.u.ref = ptr->u.ref;
         buf->have_grant = 1;
     }
+    /* Only DOMID_SELF may reference via frame. */
+    else if ( ptr->domid != DOMID_SELF )
+        return GNTST_permission_denied;
     else
     {
         rc = get_paged_frame(ptr->u.gmfn, &buf->mfn, &buf->page,

gnttab_copy_claim_buf() se ejecuta siempre que un elemento no puede reutilizar el búfer en caché. Por tanto, la comprobación de permiso ya no depende de si se ejecutó el paso de bloqueo de dominio.

Con ambos parches, cada elemento del lote pasa dos guardas antes de reutilizar nada:

¿Cómo sé si fui comprometido?

No hay indicadores publicados. El aviso no describe ninguna firma de detección, y una lectura o escritura de memoria entre dominios no deja rastro visible para el invitado víctima.

En el equipo, el ataque es un invitado emitiendo hypercalls de grant copy ordinarias, que parecen actividad normal de grant table en los registros. Los equipos que ejecutaron invitados no confiables antes de aplicar el parche deben tratar los secretos de los inquilinos como potencialmente expuestos. Pregunte a su proveedor de Xen por soporte de detección.

Cronología

• 2015-01-29: El commit d28f42f2703e añade la caché de grant copy al árbol de Xen.
• 2015-10-07: El Xen Project etiqueta Xen 4.6.0, la primera versión que contiene el commit.
• 2026-11-03: El Xen Project publica XSA-523 versión 2 públicamente a las 12:00 UTC, con parches para Xen 4.17 hasta unstable y los dos identificadores CVE.

FAQ

¿Afecta a los equipos con KVM, Hyper-V o VMware?

No. Las fallas están en el código de grant table de Xen, específico de ese hipervisor. Los equipos con otros hipervisores no están afectados.

¿Están publicados los registros CVE?

No. Al 4 de noviembre de 2026, la base de datos CVE no tiene registro para CVE-2026-102703 ni CVE-2026-102704. El aviso nombra ambos identificadores, así que remítase al aviso hasta que los registros se publiquen.

¿Quién encontró la falla?

Anthropic la descubrió usando Claude, y Stephan Lipp de Ada Logics validó el hallazgo, según los créditos del aviso. El equipo CodeAnt AI Security Research la reportó de forma independiente. Los parches llevan una línea «Assisted-by: Claude». El aviso no da la fecha del primer informe.

Ejecuto una rama al final de su vida útil, 4.16 o anterior. ¿Qué hago?

El Xen Project no proporciona parches para esas ramas. Pásese a una rama mantenida, 4.17 o posterior, y aplique en ella los parches XSA-523.

Mi proveedor de nube ejecuta Xen. ¿Debo hacer algo?

No puede parchear el equipo de un proveedor desde un invitado. Pida al proveedor su estado de XSA-523, y trate los secretos entre inquilinos como responsabilidad suya hasta que confirme el parche.

Encuentre y parchee sus equipos Xen antes de que un inquilino los explote

Los equipos que ejecutan Xen para invitados no confiables son aquí la exposición, y el atacante es un inquilino del mismo equipo, no un escáner en Internet. El descubrimiento de superficie de ataque de Ostorlab inventaría los servidores e interfaces de administración que expone a Internet, lo que da una primera lista de equipos Xen cuyo estado de XSA-523 comprobar. Los equipos accesibles solo desde su red interna requieren su propio inventario.

Referencias

• Xen Security Advisory 523 versión 2, «arbitrary read/write via grant copy», publicación pública 2026-11-03: https://xenbits.xenproject.org/xsa/advisory-523.html (consultado el 4 de noviembre de 2026)
• Parche XSA-523 1, «gnttab: complete checking in gnttab_copy_buf_valid()», CVE-2026-102703: https://xenbits.xenproject.org/xsa/xsa523-1.patch (consultado el 4 de noviembre de 2026)
• Parche XSA-523 2, «gnttab: move 'only local domain may copy by frame' check», CVE-2026-102704: https://xenbits.xenproject.org/xsa/xsa523-2.patch (consultado el 4 de noviembre de 2026)
• Copia de XSA-523 versión 2 en la lista OSS Security: https://www.openwall.com/lists/oss-security/2026/11/03/6 (consultado el 4 de noviembre de 2026)
• Código fuente de Xen, xen/common/grant_table.c antes de los parches XSA-523 (commit c89185286cbe): https://github.com/xen-project/xen/blob/c89185286cbe74f584e2ddca9bfa6654a8600502/xen/common/grant_table.c (consultado el 4 de noviembre de 2026)
• Commit de Xen d28f42f2703e, «grant-table: defer releasing pages acquired in a grant copy», 2015-01-29: https://github.com/xen-project/xen/commit/d28f42f2703e483116bafd2b0b76a32af67d83ad (consultado el 4 de noviembre de 2026)
• Etiqueta de versión de Xen 4.6.0, RELEASE-4.6.0, 2015-10-07: https://github.com/xen-project/xen/releases/tag/RELEASE-4.6.0 (consultada el 4 de noviembre de 2026)
• Xen Project, página del proyecto XCP-ng: https://xenproject.org/projects/xcp-ng/ (consultada el 4 de noviembre de 2026)
• Documentación de XCP-ng, «XCP-ng contains multiple components, built around the Xen Hypervisor»: https://docs.xcp-ng.org/ (consultada el 4 de noviembre de 2026)
• Catálogo Known Exploited Vulnerabilities de CISA, feed JSON, búsqueda de ambos identificadores CVE: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (consultado el 4 de noviembre de 2026)