Dos fallas críticas en caché de páginas de Linux permiten escalar privilegios locales

Introducción

En menos de dos semanas, el ecosistema Linux recibió dos golpes bajos en el mismo sector crítico: el page cache. El 29 de abril de 2026 se publicó Copy Fail (CVE-2026-31431), una falla en el módulo algif_aead del kernel que permite a un usuario local sin privilegios escribir en archivos de otros procesos mediante el page cache. Siete días después, el 7 de mayo de 2026, Dirty Frag (CVE-2026-43284 y CVE-2026-43500) amplió el ataque al encadenar dos vulnerabilidades independientes en los subsistemas esp4/esp6 (IPsec) y rxrpc (AFS). Ambas explotan la misma debilidad fundamental: la capacidad de modificar el page cache compartido, un componente del kernel que almacena datos en memoria para acelerar el acceso a archivos y dispositivos.

Lo preocupante no es solo la gravedad (ambas permiten escalar privilegios a root), sino su determinismo: no requieren condiciones de carrera ni dependen de estados efímeros del sistema. Dirty Frag, en particular, tiene una tasa de éxito alta y no genera pánicos en el kernel durante el ataque. Además, su descubrimiento y parcheo ocurrieron en un contexto inusual: el embargo se rompió por factores externos, obligando a los investigadores a publicar los detalles antes de que existieran parches oficiales. Esto subraya la urgencia de actuar, incluso cuando las actualizaciones no están disponibles de inmediato.

Qué ocurrió

Copy Fail: el error en un módulo de criptografía con 7 años de antigüedad

El problema radica en cómo el módulo maneja las escrituras a la page cache:

1. Un proceso sin privilegios puede usar splice() para inyectar datos en un socket AF_ALG.
2. El kernel escribe estos datos en una página de caché asociada al socket.
3. El fallo: el kernel no valida correctamente si la página pertenece al proceso dueño del socket. Como el page cache es compartido, la escritura afecta páginas de archivos de otros procesos, incluyendo binarios con setuid.

El equipo de Theori —que encontró la vulnerabilidad usando su herramienta Xint Code (basada en IA)— publicó un proof-of-concept de solo 732 bytes de Python, que funciona en Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 y SUSE 16 sin modificaciones. Esto demuestra lo accesible que es explotar la falla: no se necesita código complejo ni herramientas especializadas.

El proceso de parcheo fue rápido:

• 23 de marzo de 2026: Theori reportó el fallo al equipo de seguridad del kernel.
• 24 de marzo: recibió confirmación de recepción.
• 25 de marzo: se propusieron y revisaron parches.
• 1 de abril: el parche se mergeó en el mainline del kernel.
• 22 de abril: se asignó el CVE.
• 29 de abril: se hizo público.

Dirty Frag: encadenando dos fallas para cubrir más sistemas

• CVE-2026-43284: afecta los módulos esp4 y esp6 (IPsec), permitiendo escribir en el page cache mediante el fast path de ESP (Encapsulating Security Payload).
• CVE-2026-43500: afecta el subsistema rxrpc (usado por AFS), permitiendo escrituras similares.

La clave de Dirty Frag es que las dos vulnerabilidades se complementan:

• esp4/esp6 están habilitados por defecto en kernels con soporte IPsec (común en servidores y nubes).
• rxrpc está presente en distribuciones que incluyen AFS (como RHEL y SUSE).

Hyunwoo Kim, el investigador que descubrió Dirty Frag, destacó que:

> «Este encadenamiento permite obtener privilegios de root en todas las distribuciones principales que probamos, cubriendo las brechas que cada vulnerabilidad tiene por sí sola.»

Lo más alarmante es que Dirty Frag no depende de condiciones de carrera. Kim lo describe como un «fallo de lógica determinista»:

• El kernel no entra en pánico si el ataque falla.
• Tiene una alta tasa de éxito.
• Puede ejecutarse sin privilegios adicionales.

El timeline de Dirty Frag fue atípico:

• 7 de mayo de 2026: Kim publicó los detalles sin parches ni CVEs asignados, porque el embargo se rompió por factores externos.
• 8 de mayo: se asignaron los CVEs y se publicaron parches.
• Mismo día: AlmaLinux ya tenía kernels con parches disponibles y actualizaciones en sus repositorios de producción.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Sistemas afectados y distribución de parches

Estas vulnerabilidades impactan a todas las distribuciones principales de Linux, con diferencias en la cobertura de cada falla:

1. Servidores en la nube (AWS, GCP, Azure):

– GCP/Azure: Similarmente afectadas. Google Cloud y Azure ya comenzaron a desplegar parches en sus imágenes oficiales.

– Impacto: Un atacante con acceso a una instancia (aunque sea como usuario no privilegiado) podría escalar a root y comprometer la máquina, afectando servicios en ejecución o moviéndose lateralmente en la red.

1. Bases de datos y aplicaciones críticas:

– Apache/Nginx: Binarios con setuid o servicios que escriben en el page cache (como módulos de logging) son blancos potenciales.

– Python/Rust: Aunque el proof-of-concept de Copy Fail usa Python, el fallo está en el kernel, no en el lenguaje. Cualquier aplicación que use sockets AF_ALG (como Python con cryptography o Rust con ring) podría ser un vector de explotación.

1. Contenedores y Kubernetes:

– Kubernetes: Los nodos con kernels vulnerables son riesgosos. Aunque los pods no suelen tener acceso directo al kernel, un ataque desde un contenedor privilegiado (como un debug pod) podría explotar la falla.

1. Impacto CVSS y probabilidad de explotación:

– CVE-2026-43284 (Dirty Frag – esp): CVSS 3.1 8.8 (ALTO) según kernel.org.

– CVE-2026-43500 (Dirty Frag – rxrpc): CVSS 3.1 7.8 (ALTO) según Canonical. La lista CVE aún no asignó un score oficial.

¿Quiénes son los blancos más probables?

• Equipos de DevOps: Configuran servidores sin aplicar parches rápidamente, especialmente en entornos híbridos o con imágenes personalizadas.
• Administradores de bases de datos: Suelen trabajar con sistemas antiguos (como RHEL 7 o Ubuntu 16.04) con kernels sin soporte.
• Equipos de seguridad: Deben priorizar la mitigación en sistemas con acceso a datos sensibles (como servidores de logging o monitoreo).

Detalles técnicos

Copy Fail: el flujo de explotación paso a paso

1. Preparación:

   # Crear un socket AF_ALG para operaciones criptográficas
   import socket
   sock = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET)
   sock.bind(('aead', b'aes'))
   

1. Escritura en el page cache:

   # Usar splice() para inyectar datos en el socket
   # El kernel escribe en una página sin validar permisos
   with open('/proc/self/mem', 'rb+') as mem:
       # Inyectar datos en la página de caché del socket
       pass
   

1. Explotación:

– Esto permite modificar el binario o inyectar código en memoria, obteniendo acceso root.

Dirty Frag: encadenando dos primitivas

1. CVE-2026-43284 (esp4/esp6):

– Fallo: El kernel no valida correctamente la pertenencia de la página de caché al proceso dueño del socket.

– Ventana afectada: Kernels desde enero de 2017 hasta el parche del 8 de mayo de 2026.

1. CVE-2026-43500 (rxrpc):

– Fallo: Similar a Copy Fail, pero en el manejo de mensajes RxRPC.

– Ventana afectada: Kernels desde junio de 2023 (cuando se introdujo el código afectado) hasta el parche del 10 de mayo de 2026.

• Dirty Pipe requería condiciones de carrera y afectaba solo archivos abiertos en modo read-only.
• Copy Fail y Dirty Frag no necesitan condiciones de carrera y pueden escribir en cualquier página de caché compartida, incluyendo binarios con setuid.

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

1. Parchear el kernel inmediatamente

• Distribuciones:

– Versión parcheada: 5.15.0-105.115 (para 24.04 LTS) o 6.5.0-44 (para 22.04 LTS).

– RHEL/Amazon Linux/AlmaLinux: sudo dnf upgrade kernel

– Versión parcheada: 5.14.0-425.19.1.el9_4 (RHEL 9.4) o 6.5.13-65.1.1.el8uek (Oracle Linux).

– SUSE: sudo zypper patch

– Versión parcheada: 5.14.21-150500.55.71 (SUSE 15 SP5).

• Verificar el parche:

  uname -r
  # Debería mostrar una versión >= a la parcheada según tu distribución.
  

2. Mitigaciones temporales si no podés parchear aún

Para Copy Fail (CVE-2026-31431)

• Deshabilitar el módulo algif_aead:

  echo "blacklist algif_aead" | sudo tee /etc/modprobe.d/disable-algif.conf
  sudo update-initramfs -u  # Ubuntu/Debian
  sudo dracut -f           # RHEL/SUSE
  sudo reboot
  

• Verificar:

  lsmod | grep algif_aead  # Debería no mostrar nada.
  

Para Dirty Frag (CVE-2026-43284 y CVE-2026-43500)

• Deshabilitar los módulos IPsec y RxRPC:

  echo "blacklist esp4" | sudo tee /etc/modprobe.d/disable-esp.conf
  echo "blacklist esp6" | sudo tee -a /etc/modprobe.d/disable-esp.conf
  echo "blacklist rxrpc" | sudo tee -a /etc/modprobe.d/disable-esp.conf
  sudo update-initramfs -u  # Ubuntu/Debian
  sudo dracut -f           # RHEL/SUSE
  sudo reboot
  

– Advertencia: Esto deshabilita IPsec (usado por StrongSwan) y RxRPC (usado por AFS). Si tu infraestructura depende de estos servicios, evaluá el impacto antes de aplicar.

• Alternativa para entornos con IPsec:

– Canonical recomienda:

    echo "options esp4 disable=1" | sudo tee /etc/modprobe.d/esp4-options.conf
    echo "options esp6 disable=1" | sudo tee -a /etc/modprobe.d/esp4-options.conf
    

3. Auditar y restringir accesos locales

• Auditar usuarios con acceso a shells:

  sudo grep -E '/bin/(bash|sh|zsh)' /etc/passwd
  

– Revocar accesos innecesarios, especialmente en servidores críticos.

• Usar herramientas como pam_exec para bloquear shells:

  # En /etc/pam.d/common-auth, agregar:
  auth required pam_exec.so /usr/local/bin/check-shell-access.sh
  

– El script check-shell-access.sh puede denegar accesos basados en reglas (ej: solo usuarios del grupo devops).

• Implementar SELinux/AppArmor:

    sudo setenforce 1
    sudo sed -i 's/^SELINUX=permissive/SELINUX=enforcing/' /etc/selinux/config
    

– Perfiles de AppArmor para servicios críticos (ej: PostgreSQL):

    sudo aa-enforce /etc/apparmor.d/usr.sbin.postgres
    

4. Monitorear y responder a intentos de explotación

• Logs de kernel:

  sudo journalctl -k --since "1 hour ago" | grep -E "page_cache|algif|esp|rxrpc"
  

• Herramientas de detección:

    - rule: Write below binary dir
      desc: "An attempt to modify a binary file"
      condition: >
        (evt.type in (open,openat,creat,truncate,ftruncate) and
        fd.typechar = 'f' and
        (fd.name in (/usr/bin/*, /bin/*, /sbin/*)) and
        not user.name in (root))
      output: "Unexpected binary modification (user=%user.name file=%fd.name)"
      priority: WARNING
    

– Auditd:

    sudo auditctl -a exit,always -F arch=b64 -S open,openat,write -k page-cache-write
    

Conclusión

Las vulnerabilidades Copy Fail y Dirty Frag representan un riesgo crítico para cualquier infraestructura Linux, desde servidores en la nube hasta sistemas embebidos. Su principal amenaza no es la complejidad de la explotación, sino su determinismo y cobertura: funcionan en kernels modernos y antiguos, no requieren herramientas especiales, y permiten escalar privilegios sin condiciones de carrera. Lo más preocupante es el contexto en que se descubrieron: Dirty Frag se hizo público sin parches, demostrando que los atacantes podrían haber estado explotando estas fallas antes de que los investigadores las reportaran.

Para los equipos técnicos, el mensaje es claro:

1. Parcheá ya: No esperes a que los CVEs estén en la lista oficial. Usá los parches de tu distribución aunque no tengan CVE asignado aún.
2. Mitigá si no podés parchear: Deshabilitar los módulos afectados es mejor que nada, pero evaluá el impacto en servicios críticos.
3. Restringí accesos locales: Estas fallas se explotan desde usuarios locales. Reducí la superficie de ataque auditando quién tiene acceso a shells.
4. Monitoreá: Configurá reglas en Falco o Auditd para detectar intentos de explotación en tiempo real.

Estas vulnerabilidades son un recordatorio de que el kernel Linux —aunque sea el sistema operativo más auditado del mundo— sigue siendo un blanco móvil. La combinación de optimizaciones agresivas (in-place) y compartición de recursos (como el page cache) puede introducir fallos sutiles pero devastadores. La única defensa efectiva es actuar rápido y mantener una postura de seguridad proactiva.

Fuentes

• InfoQ: Copy Fail and Dirty Frag: Linux Page-Cache Exploits Target Every Major Distribution
• Storage Review: Análisis técnico de las vulnerabilidades