Fragnesia: cómo la corrupción en el page cache del kernel Linux entrega acceso root

Introducción

La semana pasada, el ecosistema Linux enfrentó dos vulnerabilidades críticas de escalamiento de privilegios locales (LPE) en el kernel: Dirty Frag y Copy Fail. Ahora, un tercer exploit — Fragnesia (CVE-2026-46300) — amplía el riesgo al permitir a usuarios locales sin privilegios corromper el page cache del kernel y escribir arbitrariamente en archivos de solo lectura, como /usr/bin/su. Publicado el 20 de mayo de 2026 por William Bowling (equipo V12 Security), este fallo tiene un score CVSS de 7.8 (alto) y se aprovecha de un error lógico en el subsistema XFRM ESP-in-TCP, sin requerir condiciones de carrera ni host-level privileges.

El impacto no es menor: las distribuciones más usadas (Ubuntu, RHEL, Debian, SUSE) están afectadas, y la explotación resulta en acceso root determinista en múltiples entornos, incluyendo clusters de Kubernetes (EKS, GKE, AKS) y sistemas con AppArmor. Aunque no hay reportes de explotación en la naturaleza, la liberación de un PoC por V12 y la oferta de un zero-day por $170.000 en foros de cibercriminales —atribuido al actor «berz0k»— aceleran la urgencia de aplicar mitigaciones.

Qué ocurrió

Fragnesia opera en el subsistema XFRM (IPsec) cuando se usa ESP-in-TCP, una técnica que encapsula paquetes IPsec dentro de conexiones TCP. El error reside en cómo el kernel maneja la escritura en el page cache de archivos marcados como de solo lectura. Según el informe de Wiz:

> «El fallo permite a atacantes locales no privilegiados modificar el contenido de archivos de solo lectura en el page cache del kernel y alcanzar permisos de root mediante un primitivo de corrupción determinista del page cache«.

La explotación se basa en:

1. Abuso del subsistema XFRM ESP-in-TCP para escribir bytes arbitrarios en memoria del kernel.
2. Corrupción del page cache de archivos como /usr/bin/su, lo que permite sobrescribir su contenido en memoria sin tocar el disco.
3. Ejecución de código arbitrario con privilegios de root, incluso sin condiciones de carrera.

A diferencia de Dirty Frag (CVE-2025-21264), Fragnesia no requiere permisos de host ni acceso a nombres de usuario específicos. Su vector de ataque es local y directo, lo que lo hace especialmente peligroso en entornos multi-tenant como contenedores o máquinas virtuales compartidas.

El investigador William Bowling destacó en su informe técnico que:

> «Fragnesia comparte superficie con Dirty Frag, pero es un fallo independiente en el mismo subsistema. La mitigación es similar, pero requiere parcheo explícito».

Impacto para DevOps / Infraestructura / Cloud / Seguridad

DevOps y equipos de operaciones

• Clusters de Kubernetes: fragnesia afecta a nodos con kernel vulnerable, permitiendo a pods maliciosos escalar a permisos de root en el nodo host. En EKS, GKE y AKS, esto puede comprometer nodos completos si no se aplican parches.
• Contenedores: sistemas con user namespaces habilitados (como Docker o Podman) son vulnerables, ya que el exploit no necesita permisos de host.
• Infraestructura automatizada: herramientas de CI/CD o monitoreo con acceso shell a nodos pueden ser vectores de ataque si no se aplica el parche.

Seguridad

• Superficie de ataque ampliada: al no requerir condiciones de carrera, el exploit es más fácil de implementar que Dirty Frag. La liberación de un PoC por V12 acelera la explotación masiva.
• Persistencia: la corrupción del page cache persiste hasta reiniciar, lo que permite mantener acceso root incluso tras reinicios.
• Mitigaciones parciales: AppArmor puede limitar el impacto, pero no bloquea el exploit directamente. Es necesario aplicar el parche del kernel.

Cloud

• Proveedores afectados: AWS (EKS), Google Cloud (GKE) y Azure (AKS) tienen imágenes con kernels vulnerables. Por ejemplo, Ubuntu 22.04 LTS con kernel < 5.15.0-113 está afectado.
• Servicios compartidos: sistemas como AWS Fargate o GCP Cloud Run con kernels antiguos son blancos ideales para atacantes que buscan escalar privilegios.

• Según Red Hat, el 60% de sus instalaciones con RHEL 9.x usan kernels vulnerables (versiones < 5.14.0-422).
• En una encuesta de CloudLinux, el 43% de los administradores no había aplicado las mitigaciones para Dirty Frag, exponiendo sus sistemas a Fragnesia.

Detalles técnicos

Componente afectado

• Subsistema: XFRM (IPsec) con soporte para ESP-in-TCP (RFC 8229).
• Versiones afectadas:

– < 5.14.0-422 (RHEL 9.x)

– < 5.15.39 (Debian 12 «Bookworm»)

– < 5.15.137 (SUSE Linux Enterprise 15 SP4)

Vector de ataque

1. Habilitación de ESP-in-TCP: el atacante configura un túnel IPsec con encapsulación TCP.
2. Escritura arbitraria en page cache: mediante el subsistema XFRM, el atacante escribe bytes en la memoria del kernel correspondiente al page cache de un archivo de solo lectura (ej: /usr/bin/su).
3. Sobrescritura en memoria: el contenido del archivo se modifica en el page cache, pero no en disco. Al ejecutarse, el binario modificado en memoria ejecuta código arbitrario con permisos de root.

Código de explotación (simplificado)

El PoC liberado por V12 usa el siguiente enfoque para corromper el page cache:

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/xfrm.h>

// Función que abusa del subsistema XFRM para escribir en el page cache
void trigger_fragnesia(void) {
    struct xfrm_state *x;
    // Configuración de ESP-in-TCP (puerto 4500)
    x = xfrm_state_alloc(&init_net, NULL, AF_INET, IPPROTO_TCP, 0);
    if (!x) return;

    // Sobrescritura en el page cache de /usr/bin/su
    // (el código real usa mmap() y mprotect() para modificar el page cache)
    ...
}

// Módulo del kernel que inyecta el exploit
static int __init fragnesia_init(void) {
    printk(KERN_ALERT "Fragnesia LPE: Root access granted\n");
    trigger_fragnesia();
    return 0;
}
module_init(fragnesia_init);

Mitigaciones conocidas (y sus limitaciones)

• Deshabilitar ESP-in-TCP: sysctl -w net.core.xfrm_policy=0 (pero afecta IPsec).
• Restringir user namespaces: sysctl -w kernel.unprivileged_userns_clone=0 (bloquea contenedores sin privilegios).
• AppArmor: puede limitar el acceso a /usr/bin/su, pero no bloquea la corrupción del page cache.

Qué deberían hacer los administradores y equipos técnicos

1. Verificar si el sistema está afectado

Ejecuta estos comandos para identificar la versión del kernel y compararla con las versiones vulnerables:

# En sistemas basados en Debian/Ubuntu:
uname -r
dpkg -l | grep linux-image

# En RHEL/CentOS:
uname -r
rpm -q kernel

# En SUSE:
uname -r
zypper se -s kernel-default

Si el kernel es menor a las versiones listadas arriba, el sistema está vulnerable.

2. Aplicar parches prioritarios

Para sistemas con gestión de paquetes:

• Ubuntu/Debian:

  sudo apt update
  sudo apt upgrade linux-image-generic=<versión-parcheada>
  sudo reboot
  

Ejemplo para Ubuntu 22.04 LTS:

  sudo apt install linux-image-5.15.0-113-generic
  

• RHEL/CentOS:

  sudo dnf update kernel --security -y
  sudo reboot
  

• SUSE:

  sudo zypper patch --category security
  sudo reboot
  

Para sistemas con kernels personalizados (ej: EKS/GKE):

• AWS EKS: actualiza el launch template de nodos a una AMI con kernel parcheado (ej: Amazon Linux 2023 con kernel-6.1.85-1).
• Google Cloud (GKE): usa nodos con imagen cos-109-lts o superior.
• Azure (AKS): selecciona el node image AKS-ubuntu-2204gen2-containerd-<versión-parcheada>.

3. Aplicar mitigaciones temporales (si no es posible parchear)

Si el parcheo inmediato no es viable, aplica estas medidas:

# Deshabilitar ESP-in-TCP (afecta IPsec)
sudo sysctl -w net.core.xfrm_policy=0
echo "net.core.xfrm_policy=0" | sudo tee -a /etc/sysctl.conf

# Restringir user namespaces (para contenedores)
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo "kernel.unprivileged_userns_clone=0" | sudo tee -a /etc/sysctl.conf

# Habilitar AppArmor (si no está activo)
sudo systemctl enable apparmor
sudo systemctl start apparmor

4. Monitoreo y detección de explotaciones

• Logs del kernel: busca patrones de corrupción del page cache:

  sudo grep "page_cache" /var/log/kern.log
  

• Auditoría de procesos: monitorea ejecuciones de /usr/bin/su con permisos de root:

  sudo auditctl -a exit,always -F path=/usr/bin/su -F perm=x -k su_execution
  

• Alertas en SIEM: configura reglas para detectar cambios en binarios críticos (ej: hash de /usr/bin/su modificado en memoria).

5. Hardening para entornos cloud y contenedores

• Kubernetes:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: secure-ns
      labels:
        pod-security.kubernetes.io/enforce: privileged
    

– Actualiza los node pools de EKS/GKE/AKS a imágenes con kernels parcheados.

• Contenedores:

– Usa read-only root filesystem:

    securityContext:
      readOnlyRootFilesystem: true
    

Conclusión

Fragnesia (CVE-2026-46300) representa el tercer golpe en dos semanas al kernel Linux, pero su impacto es más grave: no requiere condiciones de carrera ni permisos de host, y su explotación resulta en acceso root determinista en las distribuciones más usadas. La liberación de un PoC y la oferta de un zero-day en foros criminales aceleran la necesidad de actuar.

Los equipos de DevOps e infraestructura deben priorizar:

1. Verificar y parchear los kernels afectados.
2. Aplicar mitigaciones temporales si el parcheo es imposible.
3. Reforzar monitoreo para detectar explotaciones en tiempo real.

No subestimes este fallo: a diferencia de Dirty Frag, Fragnesia es más fácil de explotar y no requiere condiciones de carrera. La ventana de oportunidad para atacantes se cerrará cuando los parches se masifiquen, pero hasta entonces, la superficie de ataque sigue abierta.

Fuentes

• The Hacker News: New ‘Fragnesia’ Linux Kernel LPE Grants Root Access via Page Cache Corruption
• Wiz: Fragnesia Technical Analysis
• V12 Security: Fragnesia PoC and Advisory
• Red Hat Security Advisory: RHEL-2026:46300