Copy Fail – CVE-2026-31431

• Un usuario local sin privilegios puede encadenar authencesn, AF_ALG y splice() para lograr una escritura de 4 bytes en la page cache de un archivo legible, y con eso escalar hasta privilegios de root
• Funciona tal cual en múltiples distribuciones Linux con un único script de Python de 732 bytes, sin offsets por kernel ni condiciones de carrera, y el mismo exploit permite obtener una root shell
• El alcance incluye a la mayoría de las principales distribuciones Linux con kernels sin parchear, y la exposición ha sido amplia desde 2017 hasta el momento del parche debido a que AF_ALG viene habilitado por defecto
• En hosts multitenant, clústeres de Kubernetes / contenedores, runners de CI y Cloud SaaS que ejecutan código de usuario, una cuenta normal o un solo pod puede terminar convirtiéndose en root del host, por lo que el parcheo debe ser prioritario
• La respuesta principal es aplicar un parche del kernel que incluya el commit mainline a664bf3d603d; antes de eso, es importante desactivar algif_aead y bloquear AF_ALG para cargas de trabajo no confiables

---

Resumen de la vulnerabilidad

• Un solo fallo lógico lineal puede encadenarse con authencesn, AF_ALG y splice() para terminar en una escritura de 4 bytes en la page cache, permitiendo una escalada local de privilegios
• Funciona de forma idéntica en distribuciones Linux publicadas desde 2017 con un único script de Python de 732 bytes, sin ventanas de carrera ni offsets específicos por kernel
• El mismo binario de exploit obtiene una root shell en varias distribuciones sin modificaciones
• Solo se necesita una cuenta local sin privilegios; no hace falta acceso de red, funciones de depuración del kernel ni primitivas adicionales preinstaladas

Alcance del impacto

• La mayoría de las principales distribuciones Linux que usan kernels sin parchear entran en el rango afectado
• En la configuración por defecto, AF_ALG de la API criptográfica del kernel está habilitado en prácticamente todas las distribuciones mainstream, dejando exposición directa desde 2017 hasta el parche
• Las distribuciones verificadas directamente fueron Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 14.3 y SUSE 16
• Debian, Arch, Fedora, Rocky, Alma, Oracle y sistemas embebidos también se ven afectados si usan un kernel vulnerable

Entornos que necesitan parche prioritario

• En hosts Linux multitenant, varios usuarios comparten el mismo kernel, así que una cuenta arbitraria puede convertirse directamente en root
• En clústeres de Kubernetes / contenedores, la page cache se comparte a nivel de todo el host, por lo que un solo pod puede tomar control del nodo y cruzar límites entre tenants
• En runners de CI y granjas de build, código no confiable de un PR ejecutado con permisos normales puede volverse root en el runner
• En Cloud SaaS que ejecuta código de usuario, un contenedor o script subido por un tenant puede terminar en root del host
• Los servidores de un solo tenant tienen más bien un perfil de LPE interna y pueden combinarse con RCE web o credenciales comprometidas
• En laptops y workstations de un solo usuario la urgencia es menor, pero la ejecución local de código puede convertirse de inmediato en elevación a root

PoC publicada y forma de uso

• La PoC se publicó para que los equipos defensivos puedan validar sistemas y confirmar parches de proveedores
• copy_fail_exp.py usa únicamente las bibliotecas estándar de Python 3.10+ os, socket y zlib
• El objetivo por defecto es /usr/bin/su y se puede pasar otro binario setuid en argv[1]
• Modifica el binario setuid dentro de la page cache; el cambio no sobrevive a un reinicio, pero la root shell obtenida sí funciona realmente
• Issue tracker

Mitigación

• Lo primero es aplicar un parche del kernel y actualizar a un kernel de la distribución que incluya el commit mainline a664bf3d603d
• Ese parche revierte la optimización in-place de algif_aead introducida en 2017 para evitar que páginas de la page cache entren en una scatterlist de destino escribible
• Antes del parche, se recomienda desactivar el módulo algif_aead
  • echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
  • rmmod algif_aead 2>/dev/null || true
• En contenedores, sandboxes y CI que ejecutan cargas no confiables, incluso si ya están parcheados, hace falta bloquear la creación de sockets AF_ALG con seccomp

Impacto de desactivarlo

• En la mayoría de los sistemas, casi no hay impacto medible
• dm-crypt / LUKS, kTLS, IPsec/XFRM, TLS dentro del kernel, builds por defecto de OpenSSL/GnuTLS/NSS, SSH y la criptografía del keyring del kernel no se ven afectados
  • Estos usan directamente la API criptográfica del kernel y no pasan por la ruta AF_ALG
• Si en OpenSSL se habilitó explícitamente el motor afalg, algunas rutas de offload criptográfico embebido y aplicaciones que hagan bind directo a sockets aead/skcipher/hash sí pueden verse afectadas
  • Puede verificarse con lsof | grep AF_ALG o ss -xa
• Aunque se desactive AF_ALG, los objetivos que nunca lo usaron no se vuelven más lentos, y los que sí lo usaban vuelven a bibliotecas criptográficas normales en userspace

Qué lo diferencia de un LPE típico en Linux

• A diferencia de un LPE común en Linux, no tiene condición de carrera ni requiere offsets por distribución
• También se presenta con una confiabilidad de 100% en un solo intento, y cubre un período largo de 2017 a 2026 en lugar de una franja estrecha de versiones
• Con apenas 732 bytes y usando solo la biblioteca estándar de Python, no necesita payload compilado ni dependencias extra
• La ruta de escritura evade el VFS y la página corrompida no se marca como dirty, así que nada se escribe en disco
• Como la page cache se comparte en todo el host, funciona no solo como un LPE simple sino también como una primitiva de escape de contenedor

Principio de funcionamiento y características de detección

• Un usuario local sin privilegios puede escribir 4 bytes controlables en la page cache de archivos legibles de un sistema Linux y usar eso para obtener root
• El objetivo no es el archivo real en disco sino la page cache en memoria; si se modifica la copia cacheada de /usr/bin/su, desde la perspectiva de execve es como cambiar el binario mismo
• Como no hay cambios en disco, inotify no se activa, y tras reiniciar o expulsar la caché vuelve a cargarse el archivo original
• Herramientas de hash comunes como sha256sum, AIDE y Tripwire leen la page cache mediante read(), así que mientras la corrupción siga en caché pueden diferir del hash de referencia
• Cuando la caché se expulsa o el sistema reinicia, el hash vuelve a coincidir con el original, y en una imagen forense de disco solo queda el archivo sin modificar
• En IMA appraisal enforcing mode, si está habilitada la medición en cada lectura, el binario corrompido puede detectarse en el momento de execve antes de ejecutarse

Diferencias frente a otras vulnerabilidades

• Pertenece a la misma familia que Dirty Pipe, en el sentido de que corrompe la page cache desde userspace sin privilegios y permite escribir sobre binarios setuid sin cambios en disco para obtener root
• El mecanismo es distinto: Dirty Pipe abusaba de pipe buffer flags, mientras que Copy Fail abusa de una AEAD scratch write que cruza límites de scatterlist encadenadas
• Dirty Pipe requería kernels 5.8 o superiores con cierto parche, pero Copy Fail cubre la ventana de 2017 a 2026
• A diferencia de Dirty Cow, no hace falta ganar una carrera COW basada en TOCTOU ni intentarlo varias veces ni desestabilizar el sistema

Detalles adicionales

• /usr/bin/su no es obligatorio; cualquier binario setuid-root legible por el usuario puede servir, como passwd, chsh, chfn, mount, sudo o pkexec
• No es una vulnerabilidad remota; primero se necesita ejecución local de código con privilegios de usuario normal
• Si un RCE web cae sobre una cuenta de servicio sin privilegios, o se combina con un acceso SSH inicial o un PR malicioso en un runner de CI, puede terminar en root
• El parche revierte la optimización in-place de algif_aead para volver a separar req->src y req->dst en scatterlists distintas
• Las páginas de la page cache quedan solo en la fuente de solo lectura, y el único destino escribible para la operación criptográfica pasa a ser el buffer de usuario

Cronología pública y materiales de seguimiento

• Reportada al equipo de seguridad del kernel Linux el 2026-03-23
• Confirmación inicial el 2026-03-24
• Parche propuesto y revisado el 2026-03-25
• Parche integrado al mainline el 2026-04-01
• Asignación de CVE-2026-31431 el 2026-04-22
• Divulgación pública el 2026-04-29 en https://copy.fail/
• Análisis técnico en el blog de Xint
  • Incluye root cause, diagramas de scatterlist, cronología 2011→2015→2017 y walkthrough del exploit
  • La Parte 2, centrada en escape de contenedores en Kubernetes, se publicará más adelante

Información relacionada con Xint Code

• Fue encontrado de forma asistida por IA; el punto de partida fue una investigación humana sobre cómo splice() entrega páginas de la page cache al subsistema crypto y sobre la posibilidad de que el origen de páginas en scatterlist fuera una clase de bugs poco explorada
• Después, Xint Code amplió esa auditoría a todo el subsistema crypto/ de Linux en alrededor de una hora, y el hallazgo más severo de ese resultado fue Copy Fail
• Xint Code
  • Write-up del blog de Xint
  • En el mismo escaneo también se encontraron otros bugs de alto riesgo, que siguen bajo coordinated disclosure