Copy Fail: la vulnerabilidad crítica en Linux que amenaza Kubernetes y entornos cloud

¿Qué es la vulnerabilidad Copy Fail (CVE-2026-31431) en Linux?

CVE-2026-31431, conocida públicamente como Copy Fail, es una vulnerabilidad que permite escalar privilegios de manera local (LPE) en el kernel de Linux con severidad High y puntuación CVSS 3.1 7.8. La falla afecta la ruta criptográfica AF_ALG para operaciones AEAD y permite que un usuario local sin privilegios provoque una escritura controlada de 4 bytes sobre la page cache de archivos legibles, con impacto potencial de obtención de root y escape de contenedores en infraestructuras compartidas.

A diferencia de vulnerabilidades clásicas como Dirty COW, que dependen de condiciones de carrera, Copy Fail es un fallo lógico directo y reproducible. Esa característica incrementa el riesgo operativo en entornos cloud, multi-tenant, Kubernetes y CI/CD, donde distintas cargas comparten el mismo kernel del host.

Cómo funciona Copy Fail dentro del kernel de Linux

La vulnerabilidad reside en un fallo lógico dentro de la implementación criptográfica AEAD del kernel de Linux, específicamente en algif_aead, el componente que expone la API criptográfica del kernel al espacio de usuario mediante sockets AF_ALG.

En la mayoría de los entornos productivos, esta interfaz no es necesaria para el funcionamiento habitual del sistema. Sin embargo, suele venir habilitada por defecto en distribuciones modernas, lo que incrementa la superficie de ataque y la relevancia de esta vulnerabilidad en Linux.

Análisis técnico de la vulnerabilidad Copy Fail en Linux

El problema se origina por la interacción de tres componentes que, de forma independiente, son legitímos:

• La llamada al sistema splice(), que transfiere datos pasando referencias directas a páginas de la page cache sin copiarlas, una optimización ampliamente utilizada en el kernel.

• Una optimización introducida en 2017 en algif_aead que permite realizar operaciones de descifrado in-place, asumiendo que es seguro reutilizar la misma memoria como origen y destino.

• El algoritmo authencesn, único en el kernel que utiliza el búfer de destino como espacio de trabajo temporal durante la operación criptográfica.

Cuando estos tres elementos coinciden en una misma operación, el kernel realiza una escritura de 4 bytes fuera de los limites del búfer asignado, sobrescribiendo páginas de la page cache que pertenecen a archivos de solo lectura.

El comportamiento más relevante de esta corrupción es que la modificación ocurre en memoria RAM compartida y no se sincroniza a disco. En la práctica, el archivo en disco puede permanecer íntegro mientras que el binario ejecutado desde la page cache queda modificado. Para herramientas de verificación de integridad basadas solo en el archivo en disco, el sistema puede aparentar estar limpio.

Impacto en Kubernetes, contenedores y entornos multi-tenant

Para clusters de Kubernetes y plataformas multi-tenant, Copy Fail representa un riesgo elevado. La page cache es administrada por el host y se comparte entre distintas cargas que se ejecutan sobre el mismo kernel.

El escenario de explotación es directo. Un atacante que logra ejecución de código en un contenedor sin privilegios, ya sea por una aplicación vulnerable, una dependencia comprometida o credenciales filtradas, puede corromper la copia en page cache de un binario SUID compartido. Al invocar dicho binario, el atacante puede obtener root no solo dentro de la carga, sino sobre el host vulnerable.

Los entornos con aislamiento más fuerte entre cargas, como microVMs o sandboxes respaldados por virtualización, pueden reducir de forma significativa esta superficie de ataque al evitar que distintas cargas compartan la misma page cache del host. Las plataformas de contenedores tradicionales basadas en runc no proporcionan por defecto ese mismo nivel de aislamiento.

Como identificar si un sistema Linux es vulnerable

Para verificar si la infraestructura de la organización es vulnerable a Copy Fail, se recomienda realizar las siguientes validaciones:

Versión del kernel. Ejecutar uname -r y validar contra los avisos del proveedor. De acuerdo con NVD y las referencias publicas disponibles, las ramas afectadas y sus primeras versiones upstream corregidas son:

• 4.14 hasta < 5.10.254

• 5.11 hasta < 5.15.204

• 5.16 hasta < 6.1.170

• 6.2 hasta < 6.6.137

• 6.7 hasta < 6.12.85

• 6.13 hasta < 6.18.22

• 6.19 hasta < 6.19.12

Las ramas anteriores a 4.14 quedan fuera de la regresión pública citada. En distribuciones con backports, la validación final debe hacerse contra el aviso del proveedor y no solo por numero de versión.

Uso de la interfaz AF_ALG. Identificar si las aplicaciones legitimas del sistema están utilizando el socket afectado mediante lsof | grep AF_ALG o ss -f alg. Si ningún proceso lo utiliza, normalmente puede deshabilitarse con bajo impacto, pero conviene validar primero que no existan consumidores legítimos dependientes de esta interfaz.

Verificación del módulo criptográfico. Validar como se compilo algif_aead con el comando grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r). Si el resultado es =y, el componente esta integrado en el núcleo y herramientas como rmmod no permitirán descargarlo. En ese escenario, cualquier mitigación de arranque debe evaluarse y validarse específicamente para la plataforma afectada.

En Silent4Labs también hemos creado un script que puede ayudar a la identificación segura de esta vulnerabilidad en sistemas Linux, ya que no realiza cambios en el sistema.

Puede encontrarse en: https://github.com/Silent4Labs/check-copyfail-cve-2026-31431

Mitigación y contención

El enfoque defensivo requiere implementar controles inmediatos y de mediano plazo.

1. Aplicar el parche oficial del kernel

La mitigación definitiva es la actualización del kernel. El fix principal publicado upstream revierte la optimización introducida en 2017 y elimina el encadenamiento de páginas de page cache hacia una ruta de escritura in-place en algif_aead.

La referencia pública principal para el fix es el commit a664bf3d603d. En escenarios con backports manuales o series de parches propias del proveedor, la validación debe hacerse contra el aviso del distribuidor o contra la serie completa aplicada, no suponiendo que un cambio aislado por nombre o mensaje sea suficiente.

2. Deshabilitar el módulo vulnerable si no es posible parchear de inmediato

Si no se puede aplicar el parche de inmediato, la mitigación temporal públicamente mejor respaldada consiste en impedir la carga de algif_aead, por ejemplo con una regla install algif_aead /bin/false en modprobe.d, y descargar el módulo si ya esta activo.

Esta acción tiene implicaciones que se deben considerar:

• Los protocolos de seguridad como SSH, cifrado de disco (LUKS) y kTLS no se ven interrumpidos en el caso habitual, porque no dependen de esta interfaz de espacio de usuario.

• La aceleración criptográfica por hardware vía esta API queda deshabilitada.

• Las aplicaciones que utilicen esta interfaz, como los motores afalg de OpenSSL, deben estar configuradas para hacer un fallback a funciones de software. De lo contrario, pueden fallar tras el reinicio que requiere el cambio para tomar efecto.

Por lo anterior, se recomienda validar el comportamiento en entornos de pruebas antes de aplicar el cambio en producción.

Como alternativa técnica adicional, si CONFIG_CRYPTO_USER_API_AEAD=y y el componente esta integrado en el kernel, puede evaluarse un workaround de arranque como initcall_blacklist=algif_aead_init. Esa opción conviene tratarla como una mitigación de contingencia a validar caso por caso, no como la recomendación temporal principal.

3. Robustecimiento de contenedores con Seccomp

Para clusters de Kubernetes y runners de integración continua (CI/CD), la protección más recomendada en el corto plazo es la aplicación estricta de políticas de Seccomp para bloquear la creación de sockets AF_ALG. Este control interrumpe la cadena de explotación en su primer paso, sin requerir cambios en el kernel del host.

Es recomendable validar si el perfil Seccomp por defecto del runtime utilizado, como Docker, containerd o CRI-O, o el RuntimeDefault de Kubernetes ya cubre esta restricción. En muchos casos no lo hace, por lo que el robustecimiento explícito del perfil resulta necesario.

Conclusiones sobre la vulnerabilidad Copy Fail en Linux

El análisis de Copy Fail y de la técnica de modificación en page cache muestra un cambio relevante en la forma en que el código malicioso puede evadir controles de monitoreo perimetral y de integridad de archivos en disco.

Los datos convergen en cuatro recomendaciones accionables para equipos de ciberseguridad, operaciones y plataformas.

1. Aplicar el parche oficial lo antes posible. La referencia pública principal del fix es el commit a664bf3d603d, pero en entornos con backports o series de parches del proveedor debe validarse la corrección efectiva contra el aviso oficial correspondiente.

2. Endurecer los perfiles Seccomp en entornos de contenedores. Bloquear la creación de sockets AF_ALG corta la cadena de explotación en el primer paso. Esta medida es aplicable de manera inmediata sin necesidad de actualizar el kernel del host.

3. No depender exclusivamente de controles de integridad basados en disco. Las herramientas que validan integridad mediante sumas de verificación contra archivos en disco son ciegas a este tipo de corrupción en page cache.

4. Reevaluar el modelo de aislamiento en cargas multi-tenant. Para infraestructura que ejecuta cargas de múltiples “inquilinos” con datos sensibles, es recomendable migrar hacia entornos con aislamiento más fuerte, como microVMs o sandboxes respaldados por virtualización. El aislamiento lógico de un contenedor no es equivalente a una barrera de seguridad completa.

Referencias

• NVD, CVE-2026-31431: https://nvd.nist.gov/vuln/detail/CVE-2026-31431

• CERT-EU, Security Advisory 2026-005: https://cert.europa.eu/publications/security-advisories/2026-005/

• Ubuntu Security, CVE-2026-31431: https://ubuntu.com/security/CVE-2026-31431

• Ubuntu Blog, mitigaciones y fixes disponibles: https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available

• Sitio técnico del caso copy.fail: https://copy.fail

• Xint / Theori, análisis técnico principal: https://xint.io/blog/copy-fail-linux-distributions

• Repositorio público del PoC: https://github.com/theori-io/copy-fail-CVE-2026-31431

• Fix principal upstream en kernel.org, commit a664bf3d603d: https://git.kernel.org/stable/c/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5

• Script de evaluación de Silent4Labs: https://github.com/Silent4Labs/check-copyfail-cve-2026-31431