Acerca de la vulnerabilidad

CVE-2026-31431, conocida públicamente como Copy Fail, es una vulnerabilidad de escalada de privilegios local en el kernel de Linux asociada con el módulo algif_aead, que implementa la interfaz AEAD de la API criptográfica del kernel en espacio de usuario a través de AF_ALG.

En términos prácticos, el problema permite que un usuario local con bajos privilegios abuse de una falla lógica en la ruta de gestión de memoria de este subsistema y escale el impacto hasta comprometer por completo la integridad del sistema. La puntuación publicada por kernel.org y reflejada en el NVD es CVSS 7.8, con el vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, lo que significa que el ataque requiere ejecución local pero tiene un alto impacto en la confidencialidad, integridad y disponibilidad.

Cuándo se introdujo y se divulgó

• La causa raíz explotable se introdujo en el kernel en 2017, cuando se añadió una optimización in-place a algif_aead.
• El CVE se publicó en el NVD el 22 de abril de 2026.
• La divulgación pública más amplia del problema, bajo el nombre Copy Fail y con una prueba de concepto pública, ocurrió el 29 de abril de 2026.
• El parche principal upstream se confirmó el 1 de abril de 2026, antes de la divulgación pública generalizada.

Qué explota

Según los avisos técnicos publicados, la falla se basa en la combinación de:

• la interfaz AF_ALG del kernel
• el módulo algif_aead
• una optimización de operación in-place introducida en 2017
• encadenar esta interfaz con splice()

El resultado práctico es la capacidad de un proceso local para realizar una pequeña escritura controlada en páginas respaldadas por caché de página de archivos legibles. En condiciones favorables, eso es suficiente para convertir un punto de apoyo local limitado en una escalada de privilegios a root.

Cómo afecta esto a la empresa

El riesgo real no es simplemente "ejecutar un kernel de Linux vulnerable", sino permitir que código local de baja confianza llegue a esta ruta del kernel. En entornos empresariales, eso generalmente significa una mayor exposición en:

• servidores multiusuario
• hosts de salto y bastiones
• runners de CI/CD
• cargas de trabajo contenerizadas que ejecutan código no confiable
• clústeres de Kubernetes
• máquinas virtuales que alojan automatización, agentes, plugins o trabajos de terceros

Si un atacante ya tiene alguna forma de ejecución local, incluso sin root, este CVE puede convertirse en el siguiente paso hacia el compromiso del host. En la práctica, eso amplía el riesgo de:

• toma completa del servidor
• modificación de binarios o artefactos locales
• robo de credenciales, tokens y secretos residentes
• movimiento lateral hacia otros activos
• sabotaje de pipelines y cadenas de compilación

Para qué se utiliza el módulo algif_aead

algif_aead forma parte de la interfaz criptográfica del kernel en espacio de usuario (AF_ALG). Permite que las aplicaciones utilicen primitivas criptográficas del kernel a través de sockets, especialmente operaciones AEAD (Cifrado Autenticado con Datos Asociados).

Este módulo generalmente no es esencial para la mayoría de las cargas de trabajo estándar de servidores. Según la guía de mitigación publicada por CERT-EU, deshabilitar algif_aead como mitigación temporal:

• no debería afectar a dm-crypt ni a LUKS
• no debería afectar a kTLS
• no debería afectar a IPsec/XFRM
• no debería afectar a OpenSSL, GnuTLS, NSS ni SSH en uso estándar

Por otro lado, deshabilitarlo puede afectar a:

• aplicaciones configuradas explícitamente para usar el motor afalg
• software que abre sockets AF_ALG directamente
• integraciones personalizadas que utilizan aead, skcipher o hash a través de la API criptográfica del kernel

En otras palabras, para la mayoría de los hosts corporativos, bloquear el módulo tiende a tener un impacto bajo. En appliances, stacks criptográficos personalizados o rutas de software altamente optimizadas, el impacto debe validarse antes del despliegue.

Impacto operativo de deshabilitar el módulo

Bloquear el módulo reduce la exposición de inmediato, pero conlleva compensaciones:

• las aplicaciones que dependen de AF_ALG pueden fallar al iniciar o perder la aceleración criptográfica respaldada por el kernel
• las cargas de trabajo personalizadas pueden fallar solo en tiempo de ejecución, no al arrancar
• si el módulo ya está cargado, la mitigación solo se completa después de una descarga exitosa o un reinicio

Para entornos de producción, el enfoque más seguro es aplicar la mitigación en una ventana de mantenimiento controlada y validar las aplicaciones críticas después.

Corrección permanente recomendada

Incluir el módulo en la lista negra es solo una mitigación temporal. La corrección permanente es:

1. instalar un kernel parcheado proporcionado por el proveedor de la distribución
2. reiniciar el host para que el nuevo kernel se cargue realmente
3. validar que el host ya no se reporte como afectado
4. solo entonces decidir si la lista negra del módulo debe permanecer

Medidas adicionales recomendadas:

• priorizar el parcheo en hosts con usuarios locales, contenedores o ejecución de código no confiable
• restringir la creación de sockets AF_ALG con seccomp en contenedores y pipelines cuando corresponda
• revisar dónde se utiliza explícitamente afalg o la API criptográfica del kernel
• mantener un inventario de versiones del kernel y reinicios pendientes
• tratar los runners de CI/CD y los nodos de Kubernetes como alta prioridad

Qué comprueba el script

El script inspecciona:

• nombre de host
• versión del kernel en ejecución
• sistema operativo mediante /etc/os-release
• presencia del módulo algif_aead
• si el módulo está cargado actualmente
• si el módulo está bloqueado por una regla de modprobe
• si el host requiere reinicio (/var/run/reboot-required)
• estado reportado por Ubuntu Pro mediante pro fix CVE-2026-31431 --dry-run, cuando esté disponible

Con base en eso, devuelve una de las siguientes clasificaciones:

• PATCHED_OR_NOT_AFFECTED
• LIKELY_NOT_VULNERABLE
• MITIGATED
• VULNERABLE_MODULE_LOADED
• POTENTIALLY_VULNERABLE
• UNKNOWN

Lógica de clasificación

En resumen:

• Si las herramientas de Ubuntu indican que el host no está afectado o ya está corregido, el estado se convierte en PATCHED_OR_NOT_AFFECTED.
• Si el módulo algif_aead no existe en el kernel actual, el estado tiende a ser LIKELY_NOT_VULNERABLE.
• Si el módulo existe pero está bloqueado y no cargado, el estado se convierte en MITIGATED.
• Si Ubuntu indica que el host está afectado y el módulo está cargado, el estado se convierte en VULNERABLE_MODULE_LOADED.
• Si el módulo existe y es cargable pero no se puede confirmar el estado del parche, el estado se convierte en POTENTIALLY_VULNERABLE.

Requisitos

• Bash
• modinfo
• modprobe
• lsmod
• awk
• grep
• hostname
• uname
• apt-get para --update
• sudo al ejecutarse como usuario no root
• pro opcionalmente, para enriquecer el análisis en Ubuntu

Uso

Si el archivo del script se llama check_cve_2026_31431.sh:

Verificación predeterminada

Ejemplo de salida:

Salida JSON

Ejemplo:

Esta salida es útil para automatización, inventario de activos y pipelines de cumplimiento.

Mitigación

El modo --mitigate crea el archivo:

Con el siguiente contenido:

Después de eso, el script intenta eliminar el módulo de la memoria con:

Uso:

Si el usuario no es root, el script intentará usar sudo.

Actualización

El modo --update ejecuta:

Uso:

Este modo intenta actualizar los paquetes relacionados con el kernel en sistemas basados en Debian y Ubuntu. En otros entornos, este paso puede no aplicar.

Ayuda

Salida:

Limitaciones importantes

• El script utiliza heurísticas. No demuestra explotación; estima la exposición y el estado de mitigación.
• Los campos ubuntu_affected y fix_available dependen de la presencia del comando pro.
• El paso --update utiliza patrones de paquetes orientados a Ubuntu y Debian y puede no cubrir todos los kernels personalizados.
• En algunas distribuciones, el módulo puede existir con un comportamiento diferente al que espera el script.
• Bloquear el módulo puede requerir un reinicio en algunos entornos para garantizar un estado consistente.

Flujo de trabajo recomendado

1. Ejecutar --check para evaluar el host.
2. Si el módulo está disponible y no se ha aplicado ningún parche, ejecutar --mitigate.
3. Ejecutar --update o aplicar la actualización oficial del proveedor.
4. Reiniciar el host si es necesario.
5. Ejecutar --check --json para validar el estado final y conservar evidencia.

Nota

Para mayor claridad en la publicación, el script debería idealmente usar un nombre descriptivo como:

Créditos

Material organizado y publicado con crédito a SEC17.

Sitio web oficial:

• https://sec17.com