En las últimas semanas han aparecido varias vulnerabilidades de escalada local de privilegios en el kernel de Linux: Dirty Frag, Copy Fail y Fragnesia. Parecen parte de una misma familia porque el resultado final es parecido: un usuario local con pocos privilegios podría convertirse en root.
Pero desde el punto de vista operativo no conviene tratarlas como una sola vulnerabilidad. Sus módulos de entrada, rutas de activación, mitigaciones y ritmos de parcheo son distintos. Una lectura más precisa es que exponen un riesgo común en la frontera compleja entre la caché de páginas de Linux, splice, socket buffers y rutas criptográficas.
Este artículo solo analiza riesgos y respuesta. No incluye pasos reproducibles de explotación.
Qué Es Cada Vulnerabilidad
Dirty Frag: CVE-2026-43284
Dirty Frag apunta principalmente a un problema de escritura en la caché de páginas dentro de la ruta de red del kernel de Linux. En los análisis públicos suele aparecer junto con dos problemas: el lado xfrm-ESP, CVE-2026-43284, y el lado rxrpc, CVE-2026-43500.
CVE-2026-43284 está relacionado con el descifrado in-place cuando ESP maneja fragmentos skb compartidos. La clave no es que el atacante modifique directamente un archivo en disco, sino que el kernel escribe en páginas compartidas que no debería modificar y termina afectando el contenido del archivo en la caché de páginas.
Desde operaciones, lo importante es recordar que Dirty Frag toca esp4, esp6 y rxrpc, un conjunto de módulos del kernel y rutas del subsistema de red. Está ligado a IPsec, ESP y RxRPC, por lo que la mitigación temporal también gira alrededor de esos módulos.
Copy Fail: CVE-2026-31431
Copy Fail es una vulnerabilidad de escalada local de privilegios en el kernel de Linux divulgada por Theori / Xint Code. Su entrada no está en la ruta de red de IPsec, sino en la API criptográfica de espacio de usuario del kernel alrededor de algif_aead / AF_ALG.
Las explicaciones públicas la atribuyen a una optimización in-place introducida en 2017. En algunos casos, el kernel no copiaba datos como se esperaba y colocaba páginas de la caché en una ruta de destino escribible. Un atacante puede combinar AF_ALG con splice() para realizar una pequeña escritura controlada sobre páginas respaldadas por la caché.
Su riesgo está en la alta explotabilidad y en el impacto sobre varias distribuciones principales. A diferencia de Dirty Frag, la mitigación temporal de Copy Fail se centra en restringir o desactivar algif_aead, y en limitar la creación de sockets AF_ALG en entornos de contenedores y CI.
Fragnesia: CVE-2026-46300
Fragnesia es otra vulnerabilidad de escalada local de privilegios en el kernel de Linux divulgada por V12 Security, dentro de una superficie de ataque parecida a Dirty Frag. No es el mismo bug que Dirty Frag, pero sigue girando alrededor de módulos relacionados con IPsec ESP / rxrpc y efectos de escritura en la caché de páginas.
AlmaLinux la describe como el tercer problema de local-root en la misma zona amplia del código. El punto clave es que skb_try_coalesce() no conservaba correctamente el marcador de fragment compartido al combinar fragmentos de socket buffer, lo que podía permitir que la ruta de recepción XFRM ESP-in-TCP descifrara in-place sobre páginas externas de la caché.
En resumen, Fragnesia está más cerca de Dirty Frag. Ambas giran alrededor de esp4, esp6, rxrpc, fragmentos skb y rutas de descifrado ESP. Sus mitigaciones temporales también se solapan bastante.
Similitudes: Por Qué Son Peligrosas
El punto común no es que el código exacto esté en el mismo lugar, sino que el resultado del ataque y el modelo de riesgo son muy parecidos.
Primero, las tres son escaladas locales de privilegios. Normalmente el atacante necesita primero ejecutar código local como usuario normal y luego intentar convertirse en root. En un escritorio de un solo usuario no es una intrusión remota de un clic; en servidores multiusuario, CI runners, hosts de contenedores, máquinas de desarrollo compartidas y VPS con SSH expuesto, las entradas de bajo privilegio no son raras.
Segundo, las tres se relacionan con escrituras en la caché de páginas. El atacante no siempre modifica de forma permanente el archivo en disco; puede afectar la copia en memoria. Esto reduce la fiabilidad de las revisiones tradicionales de integridad: el hash del disco puede parecer normal mientras la ruta de ejecución lee contenido contaminado desde la caché.
Tercero, se parecen más a bugs lógicos deterministas que a condiciones de carrera sensibles al tiempo. Los materiales públicos insisten en que no requieren ganar una race condition. Los defensores no deberían subestimar la fiabilidad de explotación por experiencia con fallos más antiguos.
Cuarto, amplifican el riesgo en entornos de contenedores y automatización. Código de bajo privilegio dentro de contenedores, jobs de CI, scripts de compilación o plugins de terceros puede convertir un “problema local” en un problema de plataforma si alcanza las interfaces relevantes del kernel del host.
Diferencias: Una Mitigación No Cubre Todo
La mayor diferencia está en el módulo de entrada.
La entrada crítica de Copy Fail es algif_aead / AF_ALG, parte de la API criptográfica de espacio de usuario del kernel. Su defensa temporal se centra en desactivar o restringir algif_aead, y usar seccomp para impedir que los contenedores creen sockets AF_ALG.
La entrada crítica de Dirty Frag está en xfrm-ESP y rxrpc. Está más cerca de las rutas de protocolo y manejo de socket buffers. La defensa temporal suele considerar desactivar esp4, esp6 y rxrpc, pero eso puede afectar IPsec, VPN, túneles o capacidades de red relacionadas.
Fragnesia también está en una zona cercana a Dirty Frag, pero el problema concreto es que skb_try_coalesce() no conservaba el marcador de fragment compartido. Es más bien otra rama de la superficie de riesgo de Dirty Frag, no un problema de la API criptográfica de Copy Fail.
Por eso, haber tratado Copy Fail no significa que Dirty Frag y Fragnesia estén cubiertas. Del mismo modo, desactivar esp4 / esp6 no elimina automáticamente Copy Fail. Hay que confirmar por separado el estado de parches y la estrategia de mitigación.
Cómo Evaluar la Exposición
Para estas vulnerabilidades no basta con mirar el nombre de la distribución ni la versión mayor del kernel. Las distribuciones hacen backport de correcciones, los proveedores cloud mantienen ramas propias del kernel y las distribuciones empresariales pueden llevar parches adicionales.
Un orden más seguro es:
- Revisar el aviso de seguridad de la distribución y el changelog del paquete del kernel.
- Confirmar si el paquete de kernel actual corrige el CVE correspondiente.
- En servidores cloud, hosts de contenedores y nodos de CI, revisar también avisos del proveedor o de la plataforma.
- Para mitigaciones temporales, confirmar si el negocio depende del módulo afectado.
- Después de actualizar el kernel, programar reinicio y comprobar que el kernel en ejecución cambió.
La trampa más común es “el paquete está actualizado, pero la máquina no se reinició”. Las vulnerabilidades del kernel no son como actualizaciones de servicios de espacio de usuario. Hasta arrancar con el nuevo kernel, el kernel viejo puede seguir ejecutándose.
Prioridad Operativa
Los sistemas más urgentes no son todas las máquinas Linux por igual. Hay que empezar donde es más probable que exista ejecución de código con pocos privilegios.
Entornos de prioridad alta:
- Servidores de login multiusuario
- CI / CD runners
- Máquinas de compilación y empaquetado de artefactos
- Hosts de contenedores y nodos Kubernetes
- Máquinas de desarrollo compartidas
- Servidores cloud y VPS con SSH expuesto
- Plataformas que ejecutan scripts, plugins o colas de tareas de terceros
- Máquinas con vulnerabilidades web, contraseñas débiles o señales históricas de compromiso
Las máquinas cerradas, de un solo usuario y sin entrada externa de ejecución de código siguen teniendo riesgo si son vulnerables, pero normalmente pueden ir después.
Cómo Entender la Mitigación Temporal
La mitigación temporal no reemplaza al parche. Su valor es reducir la exposición cuando no se puede reiniciar de inmediato o mientras se esperan paquetes de la distribución.
Para Copy Fail, el foco está en algif_aead y AF_ALG. Si el negocio no usa la interfaz criptográfica AF_ALG del kernel, se puede evaluar desactivar el módulo relacionado. En contenedores, conviene revisar primero las políticas seccomp para que cargas no confiables no puedan crear libremente el socket correspondiente.
Para Dirty Frag y Fragnesia, el foco está en esp4, esp6 y rxrpc. Si el sistema no depende de IPsec ESP, VPN relacionadas, túneles o RxRPC, se puede evaluar una desactivación temporal. No debe hacerse a ciegas en producción porque esos módulos pueden sostener cargas de red reales.
El camino final sigue siendo actualizar el kernel. La mitigación temporal reduce superficie de ataque, pero no demuestra que el sistema sea completamente seguro.
Qué Nos Dicen Estos Tres Fallos
La advertencia importante no es solo el número de CVE. Estos fallos se concentran en rutas del kernel muy complejas: zero-copy, splice, socket buffers, caché de páginas, interfaces criptográficas y optimizaciones de pila de protocolos.
Estas rutas dan grandes beneficios de rendimiento, pero también vuelven más difícil mantener los límites de propiedad. Si un fragment está compartido, si una página puede escribirse in-place o si una optimización realmente solo reduce copias se convierte en parte del límite de seguridad.
Para equipos de seguridad y operaciones, las conclusiones son prácticas:
- Tratar la escalada local de privilegios como un amplificador de entradas ya existentes de bajo privilegio.
- Los contenedores no son una frontera natural de aislamiento frente a vulnerabilidades del kernel.
- Las revisiones de integridad no pueden mirar solo el contenido del disco.
- CI, máquinas de compilación y plataformas de plugins deben ser activos de alta prioridad.
- En parches de kernel hay que verificar tanto “instalado” como “en ejecución”.
Resumen
Dirty Frag, Copy Fail y Fragnesia son eventos recientes de alta prioridad en la escalada local de privilegios de Linux, pero no son tres nombres del mismo fallo.
Copy Fail pasa por la ruta criptográfica algif_aead / AF_ALG. Dirty Frag pasa por xfrm-ESP y rxrpc. Fragnesia, en una superficie cercana a Dirty Frag, vuelve a disparar riesgo de escritura en la caché de páginas por el manejo de marcadores de fragmentos skb.
La respuesta más sólida es actualizar el kernel según los avisos de la distribución y reiniciar. En sistemas que no puedan actualizarse de inmediato, evaluar la desactivación temporal de módulos o reglas seccomp más estrictas según la entrada real de cada vulnerabilidad. Priorizar entornos multi-tenant, CI, hosts de contenedores y desarrollo compartido.
Referencias:
- Notas de Theori sobre Copy Fail: https://github.com/theori-io/copy-fail-CVE-2026-31431
- Aviso de CERT-EU sobre Copy Fail: https://cert.europa.eu/publications/security-advisories/2026-005/
- Notas de AlmaLinux sobre Dirty Frag: https://almalinux.org/blog/2026-05-07-dirty-frag/
- Notas de AlmaLinux sobre Fragnesia: https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
- Notas del PoC de V12 Security sobre Fragnesia: https://github.com/v12-security/pocs/tree/main/fragnesia