Por qué «Copy Fail» es diferente de los anteriores exploits del núcleo de Linux

Ir directamente al resumen generado por IA de esta entrada del blog

La versión resumida

Qué: Una vulnerabilidad de escalada de privilegios locales en Linux denominada «Copy Fail» (CVE-2026-31431), un fallo lógico en la ruta AEAD de autenticación del núcleo al que se puede acceder desde el espacio de usuario a través de la interfaz de sockets AF_ALG y la función splice(2).

Repercusión: Se ha publicado una prueba de concepto de 732 bytes capaz de elevar de forma fiable los privilegios de un usuario local sin privilegios a root en las principales distribuciones de Linux que ejecutan núcleos vulnerables.

Estado: AlmaLinux, Ubuntu y otras distribuciones derivadas ya están distribuyendo kernels parcheados. La CISA añadió CVE-2026-31431 a su catálogo de vulnerabilidades explotadas el 1 de mayo. CVSS 7.8 (ALTA).

Gravedad: Vektor local, no requiere privilegios, no requiere interacción del usuario, explotación altamente fiable. En muchos entornos de contenedores o de ejecución compartida, una explotación exitosa desde el interior de un contenedor podría dar lugar a un compromiso del sistema host.

Actúe de inmediato: proteja los núcleos afectados sin demora. Las organizaciones que utilicen parches en tiempo real sin necesidad de reiniciar pueden neutralizar la vía de explotación sin esperar a las ventanas de mantenimiento ni a los reinicios. De lo contrario, implemente los núcleos parcheados por el proveedor tan pronto como sea operativamente posible. Si ninguna de estas opciones es posible de inmediato, desactive temporalmente la vía AF_ALG AEAD vulnerable siguiendo las instrucciones de mitigación que se indican a continuación.

Copy Fail es preocupante porque reúne tres características que a los defensores de la seguridad no les gusta ver juntas: un amplio alcance de distribución, una explotación muy fiable y una prueba de concepto pública publicada el mismo día de la revelación.

¿Me afecta esto?

Es casi seguro, a menos que ya hayas instalado el parche.

La vulnerabilidad «Copy Fail» afecta a las versiones de Linux anteriores a partir del kernel 4.14, lo que significa que casi todas las distribuciones empresariales que reciben mantenimiento activo han heredado la ruta de código vulnerable:

Versiones de Ubuntu anteriores a Resolute (26.04)
Red Hat Enterprise Linux 8, 9 y 10
AlmaLinux 8, 9, 10 y Kitten 10
Equivalentes de Rocky Linux, CentOS Stream y Oracle Linux
Fedora (actual y versiones recientes)
Debian estable y testing
openSUSE Tumbleweed y Leap
La mayoría de las versiones derivadas, incluidas las variantes de CloudLinux

La mayor preocupación son los dispositivos que no forman parte de flotas empresariales con mantenimiento activo: dispositivos con Linux integrado, núcleos OEM en equipos de red, sistemas industriales e instalaciones al final de su vida útil que quizá nunca reciban un parche. Si un dispositivo no ha recibido actualizaciones del núcleo por parte del fabricante recientemente, hay que dar por hecho que puede permanecer expuesto de forma permanente.

La vulnerabilidad depende de que el núcleo exponga algif_aead, que se configura de una de estas dos formas, dependiendo de la distribución.

Comprobación rápida:


# Check if loaded as a module (Debian, Ubuntu, Arch-family)

lsmod | grep '^algif_aead '

# Check if built into the kernel (RHEL, AlmaLinux, Rocky, CentOS Stream, Oracle, CloudLinux)

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Que la salida de «lsmod» esté vacía no significa que todo esté en orden, como podría parecer. En las distribuciones de la familia Debian, Ubuntu y Arch, «algif_aead» se carga automáticamente bajo demanda: un proceso sin privilegios puede activar la carga simplemente abriendo un socket AF_ALG con un nombre de algoritmo coincidente. En las distribuciones de la familia RHEL, el código se compila directamente en el kernel (CONFIG_CRYPTO_USER_API_AEAD=y) y nunca aparece en lsmod, independientemente del estado. Considere que el host está expuesto a menos que la línea de comandos del kernel incluya explícitamente en la lista negra la llamada de inicio AEAD o el kernel esté parcheado.

Tampoco estás protegido por el mero hecho de que tu distribución refuerce los espacios de nombres de usuario. El disparador «Copy Fail» no requiere la creación de un nuevo espacio de nombres: se puede acceder a la familia de sockets AF_ALG directamente desde un proceso estándar sin privilegios en las instalaciones predeterminadas.

Qué es un error de redacción

Copy Fail es una vulnerabilidad de escalada de privilegios locales en el subsistema de cifrado del núcleo de Linux. El fallo se encuentra en la plantilla AEAD de authencesn —el modo de cifrado autenticado utilizado para IPsec ESN— y puede ser explotado cuando se accede a él a través de AF_ALG junto con splice(2).

La combinación vulnerable surgió de tres cambios realizados con años de diferencia, ninguno de los cuales era erróneo por sí solo. La plantilla «authencesn», añadida en 2011 para gestionar los números de secuencia extendidos de IPsec ESP, utilizaba el búfer de destino del llamante como espacio temporal —algo inofensivo cuando solo la capa «xfrm» interna del núcleo la invocaba—. Posteriormente, AF_ALG expuso las operaciones AEAD al espacio de usuario. En 2017, una optimización del rendimiento eliminó una copia interna en la ruta AEAD, lo que permitió al núcleo operar directamente sobre la página de memoria suministrada. La combinación se volvió peligrosa cuando la ruta de datos se originó a partir de splice(2) contra una página de la caché de páginas respaldada por un archivo.

El propio descubrimiento es parte del motivo por el que este fallo es relevante. El investigador de Theori, Taeyang Lee, planteó la hipótesis de que la combinación de sockets AF_ALG con splice(2) podría crear una superficie de ataque poco explorada en torno al origen de las páginas de la lista de dispersión. En lugar de realizar una auditoría manual, el equipo introdujo esa hipótesis de una sola línea en Xint Code —su sistema de análisis asistido por IA— y lo orientó hacia el directorio crypto/. Aproximadamente una hora después, Copy Fail apareció como el hallazgo de mayor gravedad. Otros errores de alta gravedad detectados en el mismo escaneo siguen siendo objeto de una divulgación coordinada.

La corrección en el código fuente consiste en una reversión directa de la confirmación de la optimización original (a664bf3d603d). Este detalle es importante porque ilustra cómo estos errores suelen pasar desapercibidos durante la revisión: la optimización en sí misma parecía correcta aisladamente, pero nunca se modelaron las rutas de ejecución adyacentes en relación con ella.

Por qué «Copy Fail» es diferente

Esta es la parte a la que hay que prestar atención si has seguido el flujo constante de vulnerabilidades de tipo LPE en Linux durante la última década: Dirty COW, Dirty Pipe, StackRot, Dirty Frag y otras de la misma familia.

«Dirty Pipe» fue importante porque convirtió la corrupción de la caché de páginas en una técnica básica y práctica para la escalada de privilegios. Sin embargo, la mayoría de los fallos de esta categoría seguían planteando dificultades operativas: presentaban condiciones de carrera, dependían de versiones concretas del núcleo, requerían módulos poco habituales, se veían bloqueados por restricciones de espacios de nombres o eran tan poco fiables que los defensores podían, de hecho, ganar tiempo.

Copy Fail elimina gran parte de esas dificultades.

Según se informa, el exploit publicado funciona con pocas o ninguna modificación en las principales distribuciones de Linux más extendidas que han probado los investigadores. No hay una tabla de desplazamientos extensa por distribución ni una lógica de selección de objetivos prolongada. La ruta del exploit es inusualmente portátil.

El periodo de vulnerabilidad es, además, inusualmente amplio. La optimización vulnerable se incorporó a las versiones preliminares de Linux en 2017 y se extendió a los núcleos con soporte a largo plazo que aún se encuentran dentro de los periodos de soporte de los proveedores. Esto incluye sistemas empresariales, implementaciones integradas, dispositivos y infraestructuras «congeladas» cuya actualización las organizaciones suelen posponer durante años.

Y lo más importante: la explotación es muy fiable. Muchas LPE modernas del núcleo implican un comportamiento probabilístico —como el «heap shaping», el «race timing» o cadenas complejas que incluyen múltiples primitivas—. En cambio, «Copy Fail» es relativamente sencillo. Los intentos o bien tienen éxito o bien fracasan de forma clara, sin desestabilizar el sistema host.

La superficie de ataque accesible también es inusualmente habitual. A diferencia de los módulos especializados implicados en algunas vulnerabilidades recientes del núcleo, algif_aead se incluye de forma generalizada en las principales distribuciones y se compila de forma integrada o se carga automáticamente cuando se solicita. Las instalaciones predeterminadas en servidores, ordenadores de sobremesa y hosts de contenedores suelen dejar al descubierto una ruta accesible desde un proceso sin privilegios hasta el código vulnerable.

El resultado es que muchas de las hipótesis tradicionales de «ganar tiempo» no sirven de mucho en este caso. En la práctica, para reducir el riesgo de forma significativa hay que aplicar un parche al núcleo o bloquear el acceso a la ruta vulnerable.

Por qué las infraestructuras modernas agravan la situación

El término «atacante local» solía referirse a algo relativamente limitado: acceso físico, una credencial SSH robada o una vulnerabilización previa de la red.

Esa definición ya no refleja cómo funciona la infraestructura de Linux en 2026.

Las infraestructuras modernas se basan en la ejecución compartida. Los nodos de Kubernetes alojan conjuntamente cargas de trabajo de diferentes espacios de nombres. Los ejecutores de CI/CD ejecutan código de solicitudes de incorporación de cambios procedente de colaboradores externos. Los cuadernos de trabajo en la nube, los entornos de pruebas para desarrolladores, las plataformas SaaS multitenant y los sistemas de compilación ejecutan habitualmente código parcialmente fiable en núcleos compartidos.

En ese contexto, el término «local» se asemeja cada vez más a lo que antes significaba «conectado a Internet».

Una dependencia maliciosa de npm que llega a la integración continua (CI), una vulnerabilidad de ejecución remota de código (RCE) en una aplicación web que permite obtener un shell con privilegios reducidos, una cuenta de desarrollador comprometida o una cadena de escape de contenedor incompleta pueden convertirse en peldaños hacia el acceso completo como root. Copy Fail acorta la distancia entre el punto de acceso inicial y el control total a nivel del núcleo.

La vulnerabilidad no puede explotarse de forma remota por sí sola. Un atacante sigue necesitando ejecutar código en algún punto del host. Sin embargo, en entornos de ejecución compartida, la cantidad de posibles puntos de acceso ya es lo suficientemente grande como para que esta distinción tenga menos importancia que antes.

Cómo funciona realmente la vulnerabilidad

Linux pone a disposición del espacio de usuario las funciones de cifrado del núcleo a través de sockets AF_ALG. Un proceso puede solicitar algoritmos como authencesn(hmac(sha256),cbc(aes)) y transmitir datos a través de interfaces estándar de lectura y escritura.

La optimización de 2017 tenía como objetivo mejorar el rendimiento evitando copias internas innecesarias durante determinadas operaciones AEAD. En lugar de copiar los datos de entrada en búferes temporales y volver a copiar los resultados, el núcleo podía, en algunos casos, operar directamente sobre la página de memoria proporcionada.

Esa suposición deja de ser válida cuando la entrada procede, a través de splice(2), de un descriptor respaldado por un archivo. A diferencia de las operaciones habituales de lectura y escritura, splice puede transferir referencias a páginas ya almacenadas en caché en lugar de copiar los datos. La ruta de cifrado trató erróneamente esas páginas como espacio de trabajo en el que se podía escribir y aplicó una transformación in situ sobre ellas.

Este comportamiento es específico de authencesn. Otros algoritmos AEAD estándar —GCM, CCM, authenc normal— limitan sus escrituras al área de salida legítima. La plantilla authencesn, escrita originalmente para una ruta de código IPsec interna que controlaba ambos extremos de la operación, trata la lista de dispersión de destino del llamante como espacio temporal. Cuando AF_ALG expuso esa ruta al espacio de usuario y splice inyectó en ella páginas respaldadas por archivos, el resultado fue una primitiva que escribe 4 bytes controlados por operación en la caché de páginas de cualquier archivo legible.

En realidad, todas las operaciones fallan: la verificación HMAC falla porque el texto cifrado es falso, y recvmsg() devuelve un error al llamante. No obstante, la escritura de 4 bytes se lleva a cabo. Al repetir la operación en los desplazamientos seleccionados, un atacante introduce código de shell en la imagen almacenada en caché de un binario setuid, como /usr/bin/su.

El contenido del disco nunca cambia. La modificación solo existe en la memoria hasta que se expulsa la página almacenada en caché. Por lo tanto, es posible que las herramientas de integridad del sistema de archivos, el hash de archivos y el análisis forense de discos no detecten nada inusual, aunque la imagen ejecutable almacenada en caché haya sido alterada durante el tiempo suficiente para que el atacante pueda ejecutarla con privilegios de root.

La cadena de prueba pública sigue una cadena relativamente corta:

Abrir un socket AF_ALG vinculado a authencesn
Abrir un binario con permiso setuid, como /usr/bin/su, en modo lectura
Utiliza «splice» para trasladar las páginas almacenadas en caché del destino a la ruta AF_ALG
Activa la operación criptográfica in situ, que escribe 4 bytes elegidos por el atacante por cada llamada
Repite el proceso en todos los desplazamientos para insertar el código shell en la imagen almacenada en caché
Ejecuta el binario almacenado en caché modificado como root

Ya existen reimplementaciones en C, Go y en arm64, además del PoC original en Python. El hecho de que el sistema de destino utilice una versión antigua de Python no supone un obstáculo significativo. El artículo original de Xint/Theori sigue siendo la mejor referencia técnica para los defensores que necesiten conocer los detalles de implementación con mayor profundidad.

Mitigación

La mejor forma de solucionar el problema es proteger inmediatamente el núcleo en ejecución. Existen tres formas prácticas de reducir la vulnerabilidad, que se enumeran a continuación por orden de rapidez e impacto operativo.

1. Aplicación de parches sin necesidad de reiniciar (la opción más rápida, sin interrupciones del servicio)

KernelCare publicó parches en tiempo real para la vulnerabilidad «Copy Fail» en los núcleos empresariales compatibles que estaban en funcionamiento, antes de que varias distribuciones derivadas lanzaran versiones actualizadas de los paquetes del núcleo.

El parche sin reinicio neutraliza la vía de explotación en el núcleo en ejecución sin necesidad de reiniciar inmediatamente, lo que reduce la vulnerabilidad de forma inmediata en lugar de esperar al siguiente ciclo de mantenimiento.

Es posible que algunos escáneres de vulnerabilidades sigan indicando temporalmente que hay versiones del núcleo afectadas incluso después de aplicar parches sin necesidad de reiniciar, ya que las versiones de los paquetes de los proveedores y la lógica de detección de los escáneres pueden ir por detrás del estado actual del núcleo en ejecución protegido.

Para las organizaciones que gestionan infraestructuras en las que el tiempo de actividad es fundamental, esta es la forma más rápida de solucionar el problema.

¿Aún no es cliente de KernelCare? Las tarifas para nuevos clientes tienen un descuento hasta finales de junio. Más información sobre KernelCare aquí.

2. Instala un núcleo parcheado y reinicia el sistema

El procedimiento habitual para solucionar el problema consiste en instalar el paquete del núcleo parcheado proporcionado por el proveedor y reiniciar los sistemas afectados.

Las organizaciones deben comprobar la disponibilidad de parches para su distribución y dar prioridad a los entornos en los que se puede ejecutar código de confianza parcial, incluidos los nodos de Kubernetes, los ejecutores de CI/CD, los servidores compartidos, la infraestructura de desarrollo y las plataformas de aplicaciones multitenant.

3. Medidas de mitigación manuales temporales (si hay que esperar para aplicar el parche)

Si no se dispone ni de parches en tiempo real ni de ventanas de reinicio inmediato, la superficie de ataque de AF_ALG AEAD se puede desactivar temporalmente mediante la línea de comandos del núcleo.

Lea esto primero: las medidas de mitigación que se indican a continuación eliminan la superficie de ataque de AF_ALG AEAD. La mayoría de las cargas de trabajo se ven afectadas de forma controlada: dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS y SSH no dependen de ello. Las aplicaciones que utilicen explícitamente el motor afalg de OpenSSL, la descarga de cifrado por hardware a través de AF_ALG o el enlace directo de sockets AEAD pueden fallar o perder rendimiento. Compruébalo antes de una implementación generalizada.

En primer lugar, comprueba cómo se incluye algif_aead en tu kernel:

# Loadable module (Debian, Ubuntu, Arch family)

grep -qE '^algif_aead ' /proc/modules && echo "loaded as module" || echo "not currently loaded"

# Built-in (RHEL, AlmaLinux, Rocky, CentOS Stream, Oracle Linux, CloudLinux)

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Si el comando «config grep» devuelve «=y», el código se compila en el núcleo. Las entradas de la lista negra de «modprobe» y «rmmod» parecerán ejecutarse correctamente sin mostrar ningún mensaje, pero no ofrecerán protección alguna.

Solución universal (funciona tanto con módulos como con kernels integrados): desactiva la llamada «initcall» mediante la línea de comandos del kernel:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

sudo reboot

Tras reiniciar, comprueba lo siguiente:

grep -o 'initcall_blacklist=algif_aead_init' /proc/cmdline

Si la salida está vacía, significa que el parámetro no se ha aplicado; vuelve a comprobar grubby y asegúrate de que se ha producido un reinicio real.

Medida de mitigación basada únicamente en módulos cargables (Debian, Ubuntu, Arch y similares): útil cuando es necesario posponer el reinicio:

sudo sh -c 'echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif_aead.conf'

sudo rmmod algif_aead 2>/dev/null || true

Confirmar:

grep -qE '^algif_aead ' /proc/modules && echo "still loaded" || echo "not loaded"

No confíes en este método en equipos de la familia RHEL. Ambos comandos devuelven un resultado positivo independientemente de si el sistema está integrado, lo que genera una falsa sensación de seguridad.

Si se sospecha que se está produciendo un abuso, vacía la caché de páginas para que las páginas ejecutables modificadas se vuelvan a cargar desde el disco:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Esto es una medida de contención, no de corrección. Si un atacante ya ha obtenido acceso de root, es posible que ya existan mecanismos de persistencia en otras partes del sistema.

Técnicamente, SELinux y AppArmor pueden bloquear la creación de sockets AF_ALG, pero solo si se configuran para denegarla a procesos sin restricciones o con permisos amplios. Las políticas predeterminadas de todas las distribuciones principales la permiten. Considera la restricción basada en MAC como una medida de refuerzo para implementaciones en toda la flota, no como una solución de mitigación inmediata.

Para los operadores de Kubernetes, OVHcloud ha publicado una estrategia de mitigación basada en DaemonSet para clústeres gestionados. Este mismo modelo puede aplicarse de forma generalizada en entornos de Kubernetes en los que resulte complicado coordinar los reinicios durante los periodos de respuesta ante emergencias.

Si no es posible desactivar AF_ALG porque las cargas de trabajo dependen de él, las opciones restantes son aislar la ejecución local no confiable o aplicar parches al núcleo sin necesidad de reiniciar el sistema hasta que haya un intervalo de mantenimiento disponible.

Para los usuarios de KernelCare Enterprise, se lanzaron parches que no requieren reinicio para el fallo de copia en los núcleos empresariales compatibles existentes antes de que varias distribuciones derivadas publicaran versiones actualizadas de los paquetes del núcleo.

Como consecuencia, es posible que algunos escáneres sigan indicando temporalmente versiones del núcleo vulnerables, incluso cuando el núcleo en ejecución ya haya sido protegido mediante parches sin necesidad de reiniciar el sistema. Se espera que, en breve, los proveedores publiquen versiones actualizadas del núcleo y se adapten la lógica de detección en consecuencia.

Detección

No existe ninguna firma de detección fiable tras una violación de seguridad para «Copy Fail».

Una explotación exitosa no deja rastros en el disco, el patrón de llamadas al sistema se asemeja a la actividad criptográfica legítima del espacio de usuario, y las modificaciones almacenadas en caché desaparecen una vez que se liberan las páginas.

En la mayoría de los entornos, la confirmación retrospectiva resultará difícil, a menos que ya se hubiera habilitado la telemetría de llamadas al sistema, la instrumentación eBPF o el registro detallado de auditoría antes de que se produjera la explotación.

Entre los indicadores más útiles que conviene vigilar se encuentran:

Carga inesperada del módulo algif_aead en sistemas sin consumidores AF_ALG conocidos
Ejecución inusual de «su» o «sudo» poco después de la actividad de AF_ALG
Operaciones de splice(2) dirigidas a sockets AF_ALG a partir de descriptores respaldados por archivos

Las reglas de detección basadas en patrones de ejecución de Python no detectarán otras implementaciones: las reimplementaciones del exploit en C, Go y arm64 son públicas y no requieren Python en el sistema de destino. Se trata de heurísticas, no de garantías. Cualquier sistema en el que usuarios no autorizados hayan tenido acceso a un shell durante el periodo de vulnerabilidad debe considerarse potencialmente comprometido.

Lista de verificación de medidas correctoras priorizadas

Aplica un parche que no requiera reinicio o implementa un núcleo parcheado de inmediato. Los usuarios de KernelCare Enterprise pueden neutralizar la vulnerabilidad en los núcleos compatibles que estén en ejecución sin necesidad de reiniciar. De lo contrario, instala el paquete del núcleo parcheado por el proveedor y reinicia los sistemas afectados.
Si no es posible aplicar el parche de inmediato, aplique la medida de mitigación «initcall_blacklist=algif_aead_init» en la línea de comandos del núcleo tras evaluar el impacto en la carga de trabajo. La solución alternativa basada en «modprobe» que se menciona en algunos avisos anteriores no funciona en los núcleos de la familia RHEL.
Analice los entornos en los que se puede ejecutar código de confianza parcial: sistemas de integración continua (CI), servidores compartidos, nodos de Kubernetes, infraestructura de desarrollo y flotas de trabajadores SaaS.
Busca cualquier actividad sospechosa relacionada con AF_ALG a partir de la revelación del 29 de abril.
Reinicia los sistemas parcheados para borrar el estado de ejecución vulnerable y las páginas almacenadas en caché.

¿Por qué este tipo de insectos sigue reapareciendo?

«Copy Fail», «Dirty Pipe» y «Dirty Frag» difieren en los detalles de implementación, pero comparten el mismo patrón subyacente: rutas rápidas orientadas al rendimiento que parten de supuestos erróneos sobre la propiedad de la memoria.

En cada caso, una operación de escritura afectó a una página que el núcleo consideró erróneamente que se podía modificar sin riesgo.

La caché de páginas se ve afectada una y otra vez porque se comparte de forma intencionada. Todos los procesos que leen un archivo acceden a la misma página física subyacente. Una sola escritura involuntaria en esa página compartida puede hacerse visible para los binarios con privilegios que cargan código ejecutable desde ella.

La solución no consiste simplemente en «dejar de optimizar». Los sistemas modernos dependen de estas vías de rendimiento. Tampoco es una solución a largo plazo desactivar de forma permanente el módulo que haya resultado afectado por el último ataque.

La solución más profunda pasa por reforzar las garantías de propiedad de las páginas en todas las rutas de gestión de la memoria del núcleo, una tarea que los mantenedores del proyecto original ya han iniciado, pero que avanza lentamente porque afecta a algunos de los subsistemas del núcleo más sensibles al rendimiento.

Es probable que «Copy Fail» no sea la última vulnerabilidad de esta familia.

Y puede que Linux solo sea la punta del iceberg.

Copy Fail permaneció oculto durante casi una década en un código de código abierto sometido a exhaustivas revisiones, hasta que fue detectado en aproximadamente una hora por un escáner asistido por IA con una sola indicación del operador. Linux es la parte de la pila que se analiza porque puede analizarse: de forma abierta, por cualquiera. La superficie mucho mayor del firmware propietario, los kernels de los proveedores, los protocolos heredados y el microcódigo de los chips ha dependido históricamente de la suposición de que el código oculto significaba errores ocultos. Como argumenta Igor Seletskiy en «Open Source is the Tip of the Iceberg», esa suposición está llegando a su fin. Copy Fail es uno de los primeros datos; no será uno de los últimos.