Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas
La seguridad de Linux se ha visto sumamente afectada en los ultimos dias y enfrenta una crisis operativa sin precedentes con el descubrimiento de Fragnesia (CVE-2026-46300), la cuarta vulnerabilidad crítica reportada.
Bautizada también como Copy Fail 3.0 por el equipo de investigación V12 responsable de su hallazgo, esta falla de escalada de privilegios locales expone un vector de ataque universal y sumamente preciso. Al igual que sus predecesoras, Fragnesia permite a un usuario sin privilegios obtener acceso absoluto de administrador sobrescribiendo datos directamente en la caché de páginas de la memoria RAM, sin alterar los archivos físicos en el disco duro. Aunque comparte el mismo vector de ataque que Dirty Frag dentro del subsistema xfrm-ESP, su naturaleza responde a un error lógico completamente distinto que ha exigido el diseño de un parche de mitigación independiente y urgente.
Lo que hace a Fragnesia excepcionalmente peligrosa es su capacidad para lograr escrituras arbitrarias de bytes en archivos de solo lectura sin depender de complejas condiciones de carrera. El fallo se activa a través del mecanismo de encapsulación del protocolo ESP sobre TCP (ESP-in-TCP), revelando que los parches emitidos previamente fueron insuficientes o, paradójicamente, generaron las condiciones para activar accidentalmente esta nueva brecha en núcleos publicados hasta el 13 de mayo de 2026. Con un código de explotación público y totalmente funcional ya disponible, los administradores de sistemas se enfrentan a una carrera contra el reloj para aplicar bloqueos temporales mientras las principales distribuciones despliegan las correcciones definitivas en sus repositorios.
El olvido de fragmentos y la inyección criptográfica AES-GCM
El origen de Fragnesia radica en una falla de lógica dentro del manejo de los búferes de red del kernel. El error central se produce porque el búfer (skb) literalmente «olvida» que un fragmento de memoria está siendo compartido durante el proceso de coalescencia de datos. Cuando un socket TCP hace la transición al modo de nivel de usuario (ULP) espintcp después de que los datos ya han sido transferidos desde un archivo a la cola de recepción, el núcleo comete el error fatal de procesar las páginas del archivo en cola como si fueran texto cifrado ESP legítimo. En un intento por optimizar el rendimiento y evitar almacenamientos innecesarios, el sistema aplica el algoritmo criptográfico AES-GCM directamente sobre la caché de páginas mediante una operación lógica XOR in situ. Al manipular cuidadosamente el vector de inicialización (IV) o nonce, un atacante puede forzar al sistema a producir un byte específico del flujo de claves, logrando sobrescribir cualquier byte objetivo en el archivo con el valor exacto deseado.
Tablas de búsqueda y la alteración de binarios protegidos
El ataque comienza aislando el proceso en un nuevo espacio de nombres de usuario y de red, donde el atacante instala una asociación de seguridad ESP de modo de transporte con una clave conocida. A continuación, el programa construye una tabla de búsqueda de 256 entradas que mapea cada posible byte resultante del flujo de claves criptográficas con su respectivo nonce. Utilizando la transferencia directa de memoria (splice), el atacante carga en la caché de páginas un archivo ejecutable crítico del sistema con el bit suid activo, típicamente la utilidad /usr/bin/su. Iterando meticulosamente byte por byte y disparando la falla repetidamente, el software sobrescribe los primeros 192 bytes de la utilidad original con un pequeño código ejecutable (stub) independiente de la posición. Cuando finalmente se invoca el comando alterado, el sistema operativo ignora el archivo seguro del disco duro y ejecuta la versión contaminada desde la memoria caché, otorgando instantáneamente una sesión de superusuario o shell root.
Restricciones de entorno y protocolos de limpieza crítica
A pesar de ser un exploit, su ejecución exitosa depende de una condición de entorno específica: la capacidad de crear espacios de nombres de usuario sin privilegios. En sistemas con configuraciones restrictivas por defecto, como Ubuntu con sus perfiles de AppArmor activos, el ataque es bloqueado en su fase inicial a menos que el administrador haya modificado los parámetros del kernel para permitir esta función.
Un aspecto crítico tras la ejecución de este ataque es la persistencia temporal de la infección, dado que el binario alterado permanece vivo en la caché de páginas, cualquier ejecución legítima posterior del comando infectado seguirá abriendo sesiones de root no deseadas. Por ello, es importante que los equipos de seguridad purguen inmediatamente la memoria caché del sistema utilizando las herramientas de la memoria virtual tras cualquier prueba de concepto.
Para mitigar la amenaza en servidores de producción hasta la llegada de parches oficiales, la recomendación técnica es desactivar radicalmente la carga de los módulos esp4, esp6 y rxrpc en la configuración global del núcleo.
Finalmente si estas interesado en poder conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.
Continúar leyendo...