CVE-2026-31431 (Error de copia): qué significa para los dispositivos Linux integrados y qué hacer ahora

El 29 de abril de 2026, Theori reveló la vulnerabilidad CVE-2026-31431 («Copy Fail»), una vulnerabilidad de escalada de privilegios en el núcleo de Linux algif_aead interfaz de cifrado, expuesta a través de sockets AF_ALG. Afecta a las principales distribuciones de Linux que utilizan versiones del núcleo vulnerables introducidas en 2017.

La vulnerabilidad requiere acceso local, pero su comportamiento determinista y su capacidad para eludir los controles de integridad de archivos la convierten en una amenaza relevante para los sistemas integrados, especialmente aquellos que utilizan contenedores o versiones de Linux de uso general.

Este artículo aborda qué lo distingue del resto, dónde reside el riesgo real para los fabricantes de equipos originales (OEM) del sector de la electrónica integrada y qué medidas se pueden tomar al respecto.

Datos clave

• Tipo: Escalada de privilegios locales (LPE)
• CVE: CVE-2026-31431 (CVSS 7,8)
• Afecta a: Los núcleos de Linux a partir de 2017 con CONFIG_CRYPTO_USER_API_AEAD activado
• Vulnerabilidad: determinista, sin condiciones de carrera, prueba de concepto pública disponible (script de Python de 732 bytes; la primitiva del núcleo es independiente del lenguaje)
• Ámbito: Entre contenedores a través de la caché de páginas compartida
• Solución: Parche del núcleo disponible en el árbol estable y en las versiones adaptadas de los fabricantes

¿Qué hace que «Copy Fail» sea diferente?

El núcleo de Linux ya ha tenido anteriormente fallos de escalada de privilegios muy sonados. Dirty Cow (2016) requería una condición de carrera y a menudo provocaba el bloqueo de los sistemas. Dirty Pipe (2022) era específico de determinadas versiones. Copy Fail es un problema de otro tipo.

Es determinista. No hay que ganar ninguna carrera, no hay un margen de tiempo específico, ni compensaciones propias del núcleo. El mismo exploit sin modificar permite obtener privilegios de root en Ubuntu, Amazon Linux, RHEL y SUSE —en todas las distribuciones principales probadas— sin necesidad de condiciones de sincronización ni de carrera. Esto elimina una de las principales defensas naturales en la explotación del núcleo: la imprevisibilidad.

Es invisible para las herramientas de integridad convencionales. El exploit modifica la caché de páginas en memoria de un binario setuid, no el archivo en el disco. La supervisión estándar de la integridad de los archivos, que comprueba las sumas de comprobación a nivel de disco, no detectará nada. El binario en el disco permanece intacto. Pero cuando el núcleo lo carga, se ejecuta la versión corrupta en memoria, con privilegios de root.

Y traspasa los límites de los contenedores. La caché de páginas se comparte entre todos los procesos de un host, incluidos los contenedores. Un contenedor comprometido puede corromper los archivos binarios visibles para otros contenedores y para el núcleo del host. Para las arquitecturas que se basan en el aislamiento mediante contenedores —incluidos los diseños de criticidad mixta utilizados en sistemas médicos e industriales—, esto supone una vía práctica de escape de los contenedores.

La causa técnica

La vulnerabilidad se encuentra en el núcleo del algif_aead módulo criptográfico. El problema se debe a un manejo inseguro de las listas dispersas respaldadas por la caché de páginas durante las operaciones AEAD in situ, lo que permite referencias de escritura a páginas respaldadas por archivos que, en otras circunstancias, serían de solo lectura. Una actualización de optimización de 2017 introdujo este manejo de operaciones in situ, lo que rompió una suposición de seguridad fundamental.

El exploit encadena los AF_ALG interfaz de cifrado (que permite a los usuarios sin privilegios realizar un cifrado acelerado por hardware) con splice() (que pasa las páginas de la caché de páginas por referencia en lugar de copiarlas). El resultado es una escritura controlada de 4 bytes en la caché de páginas de cualquier archivo legible. Elige un binario setuid adecuado, como /usr/bin/su y obtienes acceso de root.

AF_ALG está habilitado en prácticamente todas las configuraciones habituales del núcleo. No se requieren privilegios especiales ni módulos adicionales.

Dónde el riesgo es real y dónde no lo es

«Copy Fail» es una escalada de privilegios locales. El atacante debe disponer ya de acceso local como usuario sin privilegios.

En la mayoría de los dispositivos integrados —instrumentos médicos de uso específico, controladores industriales, sistemas con acceso restringido— no hay cuentas de usuario sin privilegios, ni shell interactivo, ni forma de ejecutar un script de Python sin traspasar primero un perímetro de seguridad independiente. En esas implementaciones, la vulnerabilidad directa es baja.

Los sistemas que ejecutan políticas estrictas de SELinux o AppArmor también pueden tener una exposición reducida. En los dispositivos Android/AOSP con SELinux correctamente aplicado, la interfaz de socket AF_ALG no suele ser accesible para procesos sin privilegios; la divulgación de Theori confirmó que los dispositivos con una integración profunda de SELinux no se ven afectados por esta vía. Esto es relevante para cualquier sistema integrado —ya sea basado en Android o de otro tipo— en el que las políticas de control de acceso obligatorio restrinjan el acceso a las interfaces criptográficas del núcleo.

Eso no significa que puedas ignorarlo. Hay tres situaciones que hay que tener en cuenta:

Arquitecturas basadas en contenedores. Si tu dispositivo ejecuta varias cargas de trabajo en contenedores sobre un núcleo compartido —algo cada vez más habitual en los dispositivos médicos que integran funciones heredadas en modernos circuitos integrados (SoC)—, Copy Fail rompe el modelo de aislamiento. Un contenedor de aplicación comprometido puede escapar al host.

Enlazado a una vulnerabilidad de red. El fallo de copia se convierte en un problema grave cuando se combina con una falla que permite la ejecución remota de código. Un atacante que consiga acceso inicial a través de un fallo en una interfaz web, una API expuesta o un canal de actualizaciones comprometido puede entonces escalar privilegios hasta el nivel de root al instante. Lo importante es la cadena de vulnerabilidades.

Cumplimiento normativo. Aunque la vulnerabilidad no sea explotable en la práctica en su configuración, un CVE público con una prueba de concepto operativa genera obligaciones de documentación y evaluación según las directrices poscomercialización de la FDA, el Reglamento sobre productos sanitarios (MDR) de la UE y la norma IEC 62443. Sus equipos de calidad y normativos deben evaluar y documentar su exposición. Esa parte no es opcional.

No se trata de la distribución. Se trata de la configuración del núcleo.

Existe la idea errónea de que se trata de un «problema de distribución», y que cambiar de Ubuntu a Yocto lo evitaría. No es así. CVE-2026-31431 es un fallo del núcleo. Cualquier compilación que utilice versiones vulnerables del núcleo (introducidas en 2017) contiene el código afectado, independientemente de si ha sido compilada por Canonical, Red Hat o tu propio proceso de Yocto.

Pero la vulnerabilidad solo es relevante si CONFIG_CRYPTO_USER_API_AEAD está habilitado. Ese es el módulo que expone AF_ALG al espacio de usuario y hace que el exploit sea accesible.

Las distribuciones de uso general —Ubuntu, RHEL, Debian, SUSE— lo habilitan de forma predeterminada. No les queda otra opción. Abarcan una amplia gama de casos de uso y no pueden predecir las necesidades del usuario final. Incluyen todo, incluida la superficie de ataque.

Yocto y Buildroot, tanto con configuraciones predeterminadas como amplias del kernel, se encuentran en la misma situación. Una compilación de Yocto no es automáticamente más segura que Ubuntu. Depende de las decisiones que se tomen durante la configuración.

Un núcleo integrado debidamente optimizado —en el que cada módulo se ajusta a las necesidades reales del dispositivo— probablemente no permita CONFIG_CRYPTO_USER_API_AEAD. No hay motivo para que una pantalla quirúrgica o un controlador industrial necesiten acceso desde el espacio de usuario a los sockets de cifrado del núcleo. La misma lógica se aplica a los binarios setuid y a las cuentas de usuario sin privilegios: en una configuración mínima, ninguno de ellos debería existir. (Nota: la prueba de concepto publicada utiliza Python, pero la primitiva subyacente del núcleo puede activarse desde cualquier binario compilado. La mera ausencia de Python no constituye una medida de mitigación suficiente.)

La vulnerabilidad se encuentra en el núcleo. La posibilidad de explotarla depende de las decisiones tomadas a nivel de configuración del sistema operativo. Los fabricantes de equipos originales que hayan optado deliberadamente por una configuración del núcleo basada en criterios de seguridad pueden haber reducido su exposición, dependiendo de su configuración específica. Aquellos que hayan distribuido una versión de uso general —o una compilación de Yocto con los valores predeterminados— deberían comprobarlo.

¿Por qué sigue pasando esto?

Copy Fail no es la primera vulnerabilidad crítica del núcleo (CVE) y no será la última. Dirty Cow fue en 2016. Dirty Pipe fue en 2022. El patrón se repite cada pocos años, y el reto a la hora de responder es siempre el mismo: evaluar el impacto, crear una imagen parcheada, validarla, implementarla en los dispositivos sobre el terreno y documentarlo todo para el regulador. Las herramientas que detectaron Copy Fail —el análisis de código asistido por IA— encontrarán más. La tasa de detección está a punto de acelerarse.

Hay dos cosas que conviene dejar claras:

El parche no es lo difícil. Lo difícil es la implementación. Ubuntu y RHEL corrigieron este problema en cuestión de días. Sin embargo, en el caso de los dispositivos integrados que se encuentran en hospitales, fábricas y vehículos, la aplicación de ese parche requiere una infraestructura OTA, visibilidad de la flota, un control de cambios normativo y una revalidación. Muchos fabricantes de equipos originales (OEM) que utilizan distribuciones de uso general no cuentan con ese proceso. Y ejecutar apt-get update La implementación de un paquete en un dispositivo regulado conlleva una serie de modificaciones incontroladas, sin trazabilidad, sin pruebas de compatibilidad con su aplicación y sin posibilidad de revertir los cambios. En un entorno regulado, eso no es una corrección, sino un incumplimiento normativo.

Atención: son solo herramientas. No toman decisiones. Los escáneres de CVE y las herramientas SBOM detectarán «Copy Fail» en cuestión de horas. Pero no evalúan si CONFIG_CRYPTO_USER_API_AEAD ni siquiera está habilitada en su compilación. No evalúan si la vulnerabilidad es accesible en un dispositivo que no cuente con usuarios sin privilegios. No proporcionan la evaluación del impacto específica para cada dispositivo, la decisión sobre la corrección ni las pruebas de control de cambios que exige su expediente técnico. La brecha entre una alerta del panel de control y una corrección validada y documentada es donde la mayoría de los fabricantes de equipos originales pierden tiempo.

Ambos problemas tienen su origen en la misma causa: considerar el sistema operativo como una decisión de integración puntual, en lugar de como una dependencia gestionada con un ciclo de vida de varios años. Un núcleo mínimo que solo habilitara lo que el dispositivo necesita no habría expuesto algif_aead en primer lugar. Una ruta de actualización bien definida y un compromiso de mantenimiento a largo plazo permitirían subsanar las deficiencias de implementación cuando se publique el próximo CVE.

Medidas recomendadas para los fabricantes de equipos originales

Si estás desarrollando o manteniendo productos integrados basados en Linux, esto es lo que te recomendamos.

1. Comprueba primero la configuración del núcleo. Antes de dar por hecho que eres vulnerable, comprueba si CONFIG_CRYPTO_USER_API_AEAD está activada:

zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API_AEAD

Si /proc/config.gz si no está disponible en tu entorno de destino (algo habitual en compilaciones integradas mínimas), comprueba tu sistema de compilación: fíjate en el .config o defconfig en el árbol de fuentes del kernel, ejecuta grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r) en las distribuciones que lo almacenan allí, o en Yocto, comprueba directamente el archivo `defconfig` de la receta del kernel.

Si devuelve not set o no está presente, la ruta de explotación conocida no es accesible en tu dispositivo. Este es un paso inicial fundamental para la clasificación de riesgos.

2. Haz un inventario de las versiones del núcleo. Averigua qué núcleos se están ejecutando en tus líneas de productos y en tu parque de dispositivos. Se ven afectadas las versiones del núcleo a partir de 2017 que incluyen la ruta de código vulnerable y tienen el módulo habilitado.

3. Aplica el parche del desarrollador. Actualiza a versiones del núcleo que incluyan la corrección. Las versiones parcheadas están disponibles en el árbol estable de Linux y a través de adaptaciones específicas de cada proveedor.

4. Aplica medidas de mitigación antes de instalar el parche. Si no puedes actualizar el núcleo de inmediato, desactiva el algif_aead módulo, restringir el acceso al socket AF_ALG mediante seccomp y aplicar políticas de SELinux o AppArmor para limitar qué procesos pueden acceder a la interfaz del socket criptográfico.

5. Revise los supuestos sobre el aislamiento de los contenedores. Si su arquitectura utiliza contenedores para aislar las cargas de trabajo en un núcleo compartido, esta vulnerabilidad demuestra claramente que no se debe confiar únicamente en los contenedores como límite de seguridad. Evalúe si su modelo de amenazas requiere una capa de aislamiento de hardware o de hipervisor.

6. Actualice su SBOM y sus registros de vulnerabilidades. Incluya el CVE-2026-31431 en su lista de componentes de software y en sus evaluaciones de riesgos de ciberseguridad. En el caso de los dispositivos regulados por la FDA, esto se incorporará a su plan de gestión de la ciberseguridad poscomercialización. En el caso del Reglamento sobre productos sanitarios (MDR) de la UE, puede dar lugar a una evaluación de vigilancia.

7. Planifica la actualización sobre el terreno. En el caso de los dispositivos ya instalados, define la estrategia de actualización. Si dispones de OTA, dale prioridad. Si no es así, este es el momento de pensar en cómo gestionarás la próxima vulnerabilidad crítica del núcleo (CVE), porque sin duda habrá alguna.

8. Comunícate con tus clientes. Informa a tus clientes finales y a los usuarios clínicos sobre la vulnerabilidad, tu evaluación y tu calendario. La transparencia genera confianza.

La señal más amplia

Una última cosa que vale la pena destacar. El fallo «Copy Fail» se detectó mediante una revisión del código asistida por IA. Un investigador aplicó una herramienta de análisis automatizado al subsistema criptográfico del núcleo, y esta identificó el fallo en aproximadamente una hora. Un error lógico que había pasado desapercibido durante nueve años.

La situación está cambiando para los fabricantes de equipos originales (OEM) de sistemas embebidos. El ritmo al que se descubren vulnerabilidades graves en el núcleo va a aumentar. La cuestión no es si su sistema operativo tiene vulnerabilidades —las tiene—. La cuestión es si su proceso de ingeniería, su infraestructura de actualizaciones y su documentación normativa pueden seguir el ritmo.

Descargo de responsabilidad: Este artículo se ofrece únicamente con fines informativos y no constituye asesoramiento jurídico, normativo ni en materia de ciberseguridad. La información refleja observaciones generales sobre una vulnerabilidad dada a conocer públicamente y puede que no sea aplicable a configuraciones de dispositivos o entornos de implementación específicos. Los clientes y los fabricantes de equipos originales (OEM) son responsables de evaluar la aplicabilidad, el impacto y las medidas correctivas en sus propios sistemas, incluido el cumplimiento de los requisitos normativos aplicables. L4B Software no garantiza que la información proporcionada sea completa o suficiente para ningún uso concreto.