• evaluar de forma segura la exposición sin código de explotación
• comprobar si algif_aead está disponible, cargado, integrado en el kernel o ya bloqueado
• instalar un bloqueo persistente en modprobe.d y descargar el módulo cuando sea seguro
• añadir una regla de denegación de AF_ALG a los perfiles seccomp de Docker, Podman y Kubernetes
• validar la accesibilidad de AF_ALG sin incluir código de explotación

Solución final: instala el kernel parcheado de tu proveedor y reinicia.
Esta herramienta cubre la brecha operativa entre la divulgación y el parcheo completo de la flota.

Por qué los operadores pueden confiar en ella

• Sin código de explotación: comprueba la exposición y la accesibilidad de AF_ALG sin escrituras en la page cache, splice, cambios de setuid, escalada de privilegios ni sondeos destructivos.
• Cambio de host auditable: la mitigación del host escribe un único archivo gestionado, /etc/modprobe.d/99-copyfail-guard.conf, y el rollback elimina solo ese archivo.
• Seccomp que preserva la configuración base: seccomp-patch añade una denegación de AF_ALG a un perfil seccomp existente de Docker/Podman/Kubernetes en lugar de reemplazar el endurecimiento de tu runtime.
• Listo para automatización: assess --json y los códigos de salida documentados respaldan los escaneos de flota, la captura en SIEM y la evidencia de gestión de cambios.
• Cobertura de CI: la sintaxis de shell, la generación de perfiles seccomp, la salida JSON y las pruebas de humo se ejecutan en contenedores de distribuciones Linux comunes.

Recorrido de 30 segundos

Si estás en un host Linux y necesitas una respuesta rápida:

Si el veredicto indica exposición y algif_aead es modular:

Para instalaciones repetibles, fija una etiqueta de versión:

Reemplaza v0.3.0 con la última versión etiquetada cuando haya versiones más recientes disponibles.

¿Estoy afectado?

Ejecuta primero la comprobación segura de exposición:

Cómo interpretar el resultado:

Si ejecutas contenedores no confiables, trabajos de CI, sandboxes o cargas de trabajo multiusuario, prueba también si la creación de sockets AF_ALG está bloqueada dentro de ese runtime:

PERMITTED no demuestra una explotación exitosa, pero demuestra que la API criptográfica relevante del espacio de usuario es accesible. Para operaciones defensivas, eso es razón suficiente para aplicar la mitigación mientras confirmas el despliegue del kernel parcheado.

¿Esto demuestra la vulnerabilidad?

No se incluye ninguna prueba de concepto destructiva. Eso es una característica, no una carencia.

Una prueba real de explotación de Copy Fail necesitaría validar el impacto en la memoria del kernel o en la page cache, o la escalada de privilegios. Incluir eso en un repositorio público de mitigación haría que el proyecto fuera menos seguro y menos desplegable en producción.

CopyFail Guard demuestra las cosas sobre las que los operadores pueden actuar de forma segura:

• si el componente riesgoso está disponible, cargado, integrado en el kernel o bloqueado
• si la creación de sockets AF_ALG está permitida en un runtime de destino
• si el host tiene una mitigación intermedia activa
• si la acción requerida restante es descargar el módulo, reiniciar, aplicar seccomp o parchear con el proveedor

Para conocer el estado final de vulnerabilidad, combina esta herramienta con el aviso del proveedor, el inventario de paquetes y la evidencia de reinicio.

Modelo de resolución

CopyFail Guard es mitigación, no cura. Reduce la exposición y verifica los controles intermedios. La solución duradera sigue siendo el kernel parcheado por el proveedor más el reinicio.

La herramienta está diseñada intencionalmente para clonar y ejecutar en respuesta a incidentes: no se requieren compilador, cabeceras del kernel, código de explotación ni gestor de paquetes de terceros para el flujo principal del host. python3 es necesario para la salida --json, seccomp-patch y la prueba de sockets AF_ALG sin explotación.

Inicio rápido

Clonar y ejecutar:

Instalación opcional en el sistema:

El instalador permite fijar el origen y el destino para despliegues controlados:

Usa la última versión etiquetada para COPYFAIL_GUARD_REF cuando haya versiones más recientes disponibles.

Endurecimiento de contenedores / CI:

Valida que AF_ALG está bloqueado dentro de un contenedor protegido:

Resultado protegido esperado:

Consulta Salidas de ejemplo para ver los veredictos esperados, el formato JSON y los resultados de validación de contenedores.

Por qué esto es importante

Copy Fail es una escalada de privilegios local del kernel de Linux en el componente algif_aead de la API criptográfica AF_ALG del espacio de usuario. Los avisos públicos describen una primitiva de escritura en la page cache alcanzable por usuarios locales sin privilegios y especialmente peligrosa en sistemas con kernel compartido: nodos Kubernetes, runners de CI/CD, hosts multiinquilino, sandboxes de agentes y máquinas de desarrolladores.

La solución correcta es una actualización del kernel del proveedor que contenga la reversión/corrección upstream y un reinicio con el kernel parcheado. CopyFail Guard es una ayuda de operaciones defensivas para la ventana antes de que ese reinicio se complete en toda la flota.

Qué hace la herramienta

Requisitos de instalación

Comandos principales del host:

• Linux
• bash
• herramientas kmod: modinfo, modprobe, lsmod, rmmod donde estén disponibles
• grep, awk, mktemp, install

Herramientas de visibilidad opcionales:

• lsof o ss para comprobaciones de consumidores de AF_ALG

Parcheo de perfiles seccomp:

• python3 es necesario para --json, seccomp-patch y tools/afalg-socket-test.py

No se requieren código de explotación, compilador, cabeceras del kernel ni paquetes de terceros.

Evaluación segura vs. prueba de concepto

CopyFail Guard no incluye una prueba de concepto de explotación. Eso es intencional. Consulta ¿Esto demuestra la vulnerabilidad?.

En su lugar, assess realiza una comprobación operativa segura:

• detecta si algif_aead parece disponible, cargado, integrado en el kernel o bloqueado
• distingue entre “mitigado provisionalmente” y “realmente resuelto”
• recomienda mitigación del host, seccomp o parche/reinicio
• devuelve códigos de salida para la automatización de flotas

JSON de automatización:

Códigos de salida:

Detalles de la mitigación del host

mitigate escribe:

con:

Luego intenta:

Si el módulo está actualmente en uso, rmmod puede fallar. En ese caso, el bloqueo persistente permanece instalado; detén los consumidores de AF_ALG o reinicia después de aplicar la mitigación.

El script se niega a sobrescribir un enlace simbólico en su ruta de modprobe gestionada y escribe el archivo de forma atómica con permisos seguros.

Endurecimiento de contenedores y CI

Para cargas de trabajo no confiables, bloquea la creación de sockets AF_ALG con seccomp incluso mientras parcheas los hosts.

Ruta recomendada: parchea la configuración base de seccomp de tu runtime existente en lugar de reemplazarla:

Uso con Docker:

Uso con Podman:

Ruta solo de emergencia si no dispones de un perfil base:

El perfil de emergencia generado bloquea AF_ALG, pero por lo demás permite las llamadas al sistema. Trátalo como una solución provisional específica, no como un reemplazo del endurecimiento seccomp predeterminado normal de Docker.

Para Kubernetes, coloca el perfil bajo la raíz seccomp de kubelet, comúnmente:

Luego refiérelo con:

Consulta examples/kubernetes-seccomp-pod.yaml.

Validación segura

Este proyecto incluye una prueba de accesibilidad de AF_ALG sin explotación:

Solo intenta crear y cerrar un socket AF_ALG. No enlaza operaciones criptográficas, no llama a splice, no toca binarios setuid, no corrompe la page cache ni intenta escalar privilegios.

Resultados:

• BLOCKED significa que la política denegó AF_ALG para ese proceso.
• PERMITTED significa que la creación de sockets AF_ALG aún está permitida para ese proceso.
• UNSUPPORTED significa que AF_ALG no está disponible en ese runtime.

Validación comunitaria

CopyFail Guard necesita informes de compatibilidad del mundo real de hosts Linux, runtimes de contenedores, runners de CI y nodos Kubernetes. Si puedes probarlo de forma segura, abre un issue de Informe de compatibilidad con la salida saneada de doctor, assess --json, verify o de la prueba de sockets AF_ALG.

Los informes útiles ayudan a responder:

• qué combinaciones de distro/kernel/runtime son fáciles de mitigar
• dónde algif_aead está integrado en el kernel y solo requiere parche/reinicio
• qué configuraciones base de seccomp necesitan notas específicas del runtime
• si la documentación es lo suficientemente clara para su uso en respuesta a incidentes

Consulta la Guía de validación comunitaria.

Comandos

Las banderas se pueden colocar antes o después del comando:

Qué no debería romperse

En configuraciones típicas, no se espera que deshabilitar algif_aead afecte a:

• LUKS / dm-crypt
• SSH
• compilaciones predeterminadas de OpenSSL, GnuTLS, NSS
• kTLS / TLS en el kernel
• IPsec / XFRM
• consumidores criptográficos normales del kernel

Puede afectar a aplicaciones configuradas explícitamente para usar el motor AF_ALG o a aplicaciones que crean sockets AF_ALG directamente. Comprueba primero:

Documentación para operadores

• Runbook de respuesta a incidentes
• Guía de despliegue en flota
• Guía de validación comunitaria
• Salidas de ejemplo
• Lista de verificación de versiones
• Notas de validación de seccomp
• Modelo de evaluación segura
• Política de seguridad
• Política de soporte
• Guía de contribución
• Registro de cambios

Madurez del proyecto

• Alcance actual: evaluación defensiva, mitigación del host para algif_aead modular, endurecimiento seccomp para cargas de trabajo no confiables y rollback.
• Usuario admitido: operadores familiarizados con el endurecimiento de hosts Linux y contenedores.
• Estilo de versionado: versiones etiquetadas, entradas de changelog, pruebas de humo con GitHub Actions y plantillas de issues para informes reproducibles.
• Señal comunitaria: los informes de compatibilidad son la señal de confianza más sólida; la evidencia de campo puede convertirse en documentación, pruebas y ejemplos.
• Promesa de estabilidad: evitar comportamientos de explotación, mantener acotadas las escrituras en el host, documentar la semántica de los códigos de salida y preservar las configuraciones base de seccomp existentes del runtime.

Limitaciones

CopyFail Guard no:

• parchea tu kernel
• demuestra si tu compilación exacta del kernel es explotable
• incluye código de explotación
• protege contra usuarios root ya comprometidos
• reemplaza el EDR, el inventario de flota, los avisos del proveedor ni la planificación de reinicios

La mitigación del módulo del host funciona para algif_aead modular. Si algif_aead está integrado en tu kernel, modprobe.d y rmmod no pueden deshabilitarlo; el parche/reinicio es obligatorio y se debe usar seccomp para las cargas de trabajo no confiables mientras se parchea.

Seccomp protege solo las cargas de trabajo lanzadas con el perfil. Los contenedores o pods existentes en ejecución deben reiniciarse con el perfil endurecido.

Rollback

El rollback elimina solo el archivo gestionado por esta herramienta. No vuelve a cargar el módulo. Reinicia o ejecuta manualmente modprobe algif_aead solo si lo necesitas explícitamente y has aceptado el riesgo o has parcheado el kernel.

Preguntas frecuentes

¿Esto reemplaza al parcheo?

No. El parche y el reinicio siguen siendo la solución final.

¿Esto prueba la explotación?

No. El proyecto evita intencionalmente los comportamientos de explotación. tools/afalg-socket-test.py solo comprueba si la creación de sockets AF_ALG es accesible.

¿Por qué bloquear AF_ALG en contenedores incluso después de la mitigación del host?

Defensa en profundidad. Las cargas de trabajo de contenedores y CI son lugares habituales donde se ejecuta código no confiable sobre un kernel compartido. Seccomp hace que el primer paso de esta clase de ataque sea inalcanzable para esa carga de trabajo.

¿Por qué parchear un perfil seccomp existente en lugar de generar uno nuevo?

Porque los perfiles predeterminados del runtime contienen muchas decisiones de endurecimiento. Reemplazarlos con un perfil de emergencia mínimo puede eliminar protecciones accidentalmente. seccomp-patch conserva tu configuración base y añade la denegación de AF_ALG.

¿Puedo usarlo en toda una flota?

Sí. Comienza con doctor y assess --json, prueba la mitigación en una pequeña muestra de Linux y luego despliega la mitigación del host y los cambios de perfiles seccomp por separado. Consulta la Guía de despliegue en flota.

Referencias

• NVD: CVE-2026-31431
• Aviso CERT-EU: vulnerabilidad alta en el kernel de Linux (“Copy Fail”)
• Entrada de vulnerabilidades explotadas conocidas de CISA
• Aviso técnico público de copy.fail
• Corrección estable de Linux: crypto: algif_aead - Revert to operating out-of-place

Autor

Creado por Julio César Suástegui Calderón.

Ingeniería de seguridad, sistemas Linux y automatización defensiva práctica.

Licencia

MIT