Copy Fail

Copy Fail, la última gran vulnerabilidad en el kernel de Linux

Copy Fail, la última gran vulnerabilidad en el kernel de Linux, permite a un usuario sin privilegios convertirse en root ejecutando un script de apenas 732 bytes. Aquí te explicamos en qué consiste, cómo funciona exactamente, y qué medidas urgentes puedes tomar para proteger tus sistemas mientras esperas el parche oficial de tu distribución.

Resumen de la vulnerabilidad

El 29 de abril de 2026 se hizo pública una vulnerabilidad de escalada de privilegios local en el kernel de Linux, catalogada como CVE-2026-31431 y bautizada como Copy Fail. Tiene una puntuación CVSS de 7.8 (Alta), afecta a prácticamente todas las distribuciones de Linux que utilicen un kernel compilado desde 2017 y, para entonces, los parches de las distribuciones aún estaban pendientes.

La vulnerabilidad es especialmente peligrosa porque es un fallo de lógica pura: no depende de complejas condiciones de carrera y su exploit público funciona con un 100% de fiabilidad.

Un fallo de lógica, no de memoria

A diferencia de vulnerabilidades famosas como Dirty Cow o Dirty Pipe, Copy Fail no se basa en una condición de carrera. Es un error lógico introducido en 2017 en una optimización del módulo algif_aead del kernel, parte de la API criptográfica AF_ALG.

¿Cómo funciona el exploit?

El ataque, que puede ejecutar cualquier usuario local sin privilegios, sigue estos pasos:

1. Preparación: El exploit abre un socket AF_ALG y utiliza la llamada al sistema splice() para mover datos desde un archivo legible (por ejemplo, un binario con permisos SUID como /usr/bin/su) a la memoria caché de páginas (page cache).
2. Corrupción controlada: Debido al fallo en la optimización, durante una operación de descifrado AEAD, el kernel permite que el atacante sobrescriba 4 bytes específicos dentro de esa caché. El exploit elige cuidadosamente qué bytes modificar.
3. Ejecución maliciosa: Como la modificación ocurre solo en la memoria RAM (page cache) y no en el disco, las herramientas de verificación de integridad no lo detectan. Cuando el usuario ejecuta el binario corrupto (por ejemplo, el comando su), se ejecuta el código alterado, proporcionando una shell con privilegios de root.

Ejemplo práctico del flujo del exploit (Python 3.10+):

# El exploit público utiliza la librería estándar de Python
import socket, os

# 1. Abre un socket AF_ALG para el algoritmo vulnerable 'authencesn'
sock = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0)
sock.bind(('aead', 'authencesn(hmac(sha256),cbc(aes))'))

# 2. Prepara el archivo setuid (/usr/bin/su) y usa splice para cargarlo en caché
#... (lógica de preparación de splice)...

# 3. Realiza operaciones de descifrado que, debido al fallo,
#    escriben 4 bytes controlados en la caché del archivo setuid.
#... (bucle de escritura controlada)...

# 4. Ejecuta el binario modificado en memoria
os.execv('/usr/bin/su', ['su'])

Nota: El código anterior es un esquema conceptual basado en las descripciones del exploit. El script completo y funcional no se incluye por razones de seguridad.

Productos y entornos afectados

La práctica totalidad de distribuciones de Linux están afectadas. Las verificadas por los investigadores incluyen:

• Ubuntu 24.04 LTS (kernel 6.17.0-1007-aws)
• Amazon Linux 2023 (kernel 6.18.8-9.213.amzn2023)
• Red Hat Enterprise Linux 10.1 (kernel 6.12.0-124.45.1.el10_1)
• SUSE Linux Enterprise 16 (kernel 6.12.0-160000.9-default)

También están afectadas Debian, Arch, Fedora y cualquier sistema con un kernel de la rama principal entre 2017 y el parche. En entornos de contenedores como Kubernetes u OpenShift, el riesgo es crítico, ya que puede permitir la escalada de privilegios dentro del pod y, en configuraciones con privileged: true o allowPrivilegeEscalation: true, el escape al nodo host.

Cómo parchear provisionalmente y mitigar el riesgo

Dado que los parches del kernel de las distribuciones se estaban preparando pero aún no estaban universalmente disponibles, la mitigación inmediata es crucial. El objetivo es inutilizar el módulo vulnerable algif_aead.

Opción 1: Mitigación universal (recomendada para la mayoría de sistemas)

Este método deshabilita el módulo del kernel de forma persistente. No debería afectar a aplicaciones que usan cifrado estándar como OpenSSL, TLS o SSH, ya que estas realizan las operaciones criptográficas en espacio de usuario.

Ejecuta los siguientes comandos como root:

1. Crear un archivo de configuración para denegar la carga del módulo:
   bash echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
2. Descargar el módulo inmediatamente si ya está cargado en memoria:
   bash rmmod algif_aead 2>/dev/null || true
3. Verificar que el módulo ya no está cargado:
   bash grep -qE '^algif_aead ' /proc/modules && echo "Módulo CARGADO - Reinicia o fuerza descarga" || echo "Módulo NO cargado - Sistema mitigado"

Opción 2: Para sistemas Ubuntu (mitigación oficial por paquete)

Canonical publicó una actualización del paquete kmod que automatiza esta misma mitigación. Para aplicarla:

sudo apt update && sudo apt install --only-upgrade kmod

Opción 3: Refuerzo para entornos de contenedores (Kubernetes/OpenShift/Docker)

El exploit requiere sí o sí crear un socket AF_ALG. Bloquear esta llamada al sistema a nivel de contenedor proporciona una capa de defensa adicional y no depende de la configuración del módulo en el host.

• En Docker/Podman, puedes ejecutar contenedores con la bandera --security-opt no-new-privileges.
• En Kubernetes, la mitigación más robusta es desplegar un perfil seccomp personalizado que bloquee la syscall socket(AF_ALG,...) y forzar su uso en tus pods.

El siguiente es un ejemplo de un perfil seccomp en formato JSON que deniega específicamente esa operación:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ"
        }
      ]
    }
  ]
}

Tras guardar este JSON en la ruta adecuada de tus nodos, puedes referenciarlo en la especificación de seguridad de tus pods para aplicarlo de forma inmediata.

La recomendación unánime de los equipos de seguridad y las distribuciones es aplicar estas mitigaciones sin demora, especialmente en servidores expuestos a cargas de trabajo no confiables, como nodos de Kubernetes y entornos de CI/CD. Mantente atento a los canales oficiales de tu distribución para aplicar la actualización definitiva del kernel en cuanto esté disponible.

Preguntas frecuentes sobre Copy Fail

¿Qué sistemas son más vulnerables a Copy Fail?

El riesgo es mayor en entornos compartidos como clústeres de Kubernetes, servicios cloud que ejecutan código de usuarios y servidores con múltiples cuentas locales.

¿Por qué es difícil de detectar por antivirus tradicionales?

Porque el fallo ocurre en la page cache (memoria) y no modifica los archivos físicos en el disco, por lo que las comprobaciones de integridad de archivos no muestran cambios.