En las últimas semanas el mundo Linux se ha visto sacudido por una nueva vulnerabilidad que, para muchos administradores, ha sido la gota que colma el vaso en una racha de fallos críticos en el kernel. Hablamos de Fragnesia, un exploit de escalada local de privilegios que se suma a la familia de fallos conocidos como Copy Fail y Dirty Frag, y que permite a cualquier usuario sin privilegios conseguir root con un único comando en sistemas vulnerables.

Tras Copy Fail y Dirty Frag, Fragnesia llega en un contexto de auténtica “fatiga de parches”: actualizaciones urgentes, reinicios encadenados y mitigaciones de emergencia. Sin embargo, dejarlo pasar no es una opción. El fallo afecta a múltiples distribuciones Linux y versiones de kernel, y ya existe una prueba de concepto pública totalmente funcional. En este artículo vamos a desgranar qué es Fragnesia, cómo funciona el ataque, qué distribuciones están afectadas, qué parches y mitigaciones existen y cómo comprobar si tu sistema está protegido.

Qué es Fragnesia y por qué se relaciona con Dirty Frag y Copy Fail

Fragnesia es un nuevo exploit de escalada local de privilegios (LPE) en el kernel de Linux que se encuadra en la misma familia de vulnerabilidades que Copy Fail (CVE-2026-31431) y Dirty Frag (también conocido como Copy Fail 2, CVE-2026-43284). Comparte con ellas la idea base: abusar de fallos lógicos en la pila de red y el manejo de memoria del kernel para obtener una primitiva de escritura en memoria que permita modificar archivos teóricamente de solo lectura y acabar ejecutando código como root.

El fallo ha sido bautizado como Fragnesia y rastreado como CVE-2026-46300, con una puntuación CVSS de 7,8. La vulnerabilidad fue descubierta por William Bowling, del equipo de seguridad V12. Poco después, Sam James anunció el problema en la lista de correo de OSS Security, aclarando que no se trataba de un simple reanálisis de Dirty Frag, sino de un bug distinto en la misma superficie funcional del kernel.

En términos prácticos, Fragnesia es el tercer fallo crítico de este tipo en apenas dos semanas: Copy Fail, Dirty Frag y ahora Fragnesia. Los tres se aprovechan de problemas en el manejo de datos en el kernel para corromper la caché de páginas (page cache) de archivos críticos como /usr/bin/su, pero Fragnesia lo logra a través de otra ruta: el subsistema ESP-in-TCP de XFRM.

Detalles técnicos: el subsistema XFRM ESP-in-TCP y el fallo de lógica

El núcleo de Fragnesia reside en un fallo de lógica en el subsistema Linux XFRM ESP-in-TCP, concretamente en la ruta del ULP (Upper Layer Protocol) denominada espintcp. XFRM es el marco del kernel encargado, entre otras cosas, de procesar tráfico IPsec, y ESP (Encapsulating Security Payload) es el protocolo que proporciona confidencialidad y autenticidad mediante cifrado (por ejemplo, AES-GCM), como ocurrió con una vulnerabilidad en el protocolo de red CAN BCM.

El ataque se basa en una situación muy concreta del kernel: cuando un socket TCP pasa a modo ESP-in-TCP después de que se hayan introducido en su cola de recepción páginas de fichero mediante llamadas como splice(2) o sendfile(2). En lugar de tratar esos datos como simples páginas provenientes de un archivo, el kernel los interpreta como si fueran texto cifrado ESP y aplica la “desencriptación” sobre ellas, modificando así las páginas de la caché de forma in situ.

Como consecuencia de este error, el kernel inyecta el flujo de claves de AES-GCM sobre páginas de la caché correspondientes a archivos de solo lectura, lo que se traduce en escrituras de bytes arbitrarias en la page cache. Controlando el IV (nonce) y otros parámetros, un usuario sin privilegios puede dirigir estas escrituras con mucha precisión. El resultado es una primitiva de escritura determinista que permite alterar una cantidad controlada de bytes de cualquier archivo legible, pese a que el sistema de ficheros lo marque como inmutable o de solo lectura.

La prueba de concepto pública se centra en modificar el binario /usr/bin/su en la caché de páginas. Inyecta un stub ELF de 192 bytes (posicionalmente independiente) en la copia en memoria de ese binario. A partir de ese momento, la siguiente vez que se ejecute su, se ejecutará el stub con privilegios de root, proporcionando una escalada instantánea sin necesidad de carreras de condiciones ni de otros trucos adicionales.

Mitigaciones temporales: cómo protegerte si no puedes reiniciar

Aunque lo recomendable es instalar un kernel parcheado y reiniciar lo antes posible, se han descrito mitigaciones temporales efectivas para quienes no puedan permitirse un reinicio inmediato. La buena noticia es que, dado que Fragnesia explota los mismos módulos base (esp4, esp6 y opcionalmente rxrpc) que Dirty Frag, la mitigación propuesta para este último sirve igualmente para Fragnesia.

La técnica consiste en bloquear la carga de los módulos vulnerables mediante la configuración de modprobe y, si estuvieran ya cargados, descargarlos de memoria. Se hace escribiendo una regla en /etc/modprobe.d/ que sustituye la carga de esos módulos por comandos inofensivos (como /bin/false). Después se invoca a rmmod sobre ellos, ignorando silenciosamente los errores si no están presentes.

En distribuciones como CloudLinux, el comando propuesto para Dirty Frag (que vale igual para Fragnesia) genera un archivo dirtyfrag.conf con reglas para esp4, esp6 y rxrpc, y a la vez intenta descargar los módulos activos. Si ya aplicaste esta mitigación por Dirty Frag, no tienes que hacer nada más para Fragnesia hasta que instales el kernel corregido, porque la superficie de ataque queda igualmente neutralizada.

Es importante tener en cuenta la compatibilidad: esp4 y esp6 son los transform del kernel para IPsec. Deshabilitarlos rompe los túneles IPsec que dependan de la ruta de datos del kernel (por ejemplo, strongSwan o Libreswan). La recomendación es no usar esta mitigación en hosts que terminen o enruten tráfico IPsec crítico. El módulo rxrpc es el transporte AF_RXRPC, usado casi exclusivamente por clientes AFS, y rara vez está presente en servidores web u otros escenarios generalistas.

Restaurar la caché de páginas tras aplicar la mitigación

Otro punto a menudo pasado por alto es que el exploit, al funcionar, puede dejar en memoria copias modificadas de binarios legítimos en la page cache. El ejemplo más típico es /usr/bin/su, pero podrían verse afectados otros binarios privilegiados si el atacante decide cambiar de objetivo.

Por ello, algunos avisos recomiendan que, tras aplicar la mitigación de blacklist de módulos, se proceda a vaciar la caché de páginas del sistema para forzar una recarga limpia desde disco. Esto se puede lograr escribiendo en /proc/sys/vm/drop_caches un valor que indique al kernel que libere cache page y dentries/inodes. Esta operación solo elimina páginas limpias, por lo que es segura en sistemas en producción, aunque puede generar un aumento puntual de E/S al disco cuando los binarios y datos se vuelvan a leer.

La idea es sencilla: si una instancia de Fragnesia ya hubiera sido ejecutada antes de mitigar, las páginas corrompidas se descartan y se volverá a usar la versión en disco sin alterar. Combinado con la blacklist de módulos, este paso reduce el riesgo de que una posible modificación residual en la cache siga siendo explotable o provoque comportamientos erráticos en el sistema.

Estado de los parches y recomendaciones de los proveedores

La mayoría de los grandes actores del ecosistema Linux han respondido de forma rápida al descubrimiento de Fragnesia. Distribuciones como AlmaLinux y CloudLinux han publicado o están finalizando kernels parcheados, mientras que Red Hat ha indicado que está evaluando hasta qué punto las mitigaciones existentes para vulnerabilidades previas cubren también CVE-2026-46300.

Varios proveedores de seguridad, como empresas asociadas a Google y Microsoft, han publicado análisis explicando que la vulnerabilidad permite a atacantes locales sin privilegios modificar contenidos de archivos de solo lectura en la caché de páginas y escalar a root mediante corrupción determinista de memoria. Wiz, por ejemplo, destaca que AppArmor y las restricciones sobre user namespaces sin privilegios pueden mitigar parcialmente el impacto al requerir técnicas adicionales para explotar con éxito el bug en algunos entornos.

Microsoft, por su parte, señala que no se ha observado explotación activa en la naturaleza en el momento de su comunicado, pero aun así insta a aplicar el parche tan pronto como esté disponible, utilizando las herramientas de actualización habituales. Cuando no sea posible parchear de inmediato, recomiendan aplicar las mismas mitigaciones propuestas para Dirty Frag: desactivar esp4, esp6 y funcionalidad relacionada con IPsec/XFRM no imprescindible, endurecer el acceso local interactivo y reforzar el monitoreo de actividades inusuales de escalada de privilegios.

Contexto de amenazas: mercado de exploits y fatiga de parches

El descubrimiento de Fragnesia se produce en un contexto en el que la explotación de fallos de escalada local en Linux gana valor en el mercado negro. Informes recientes describen a un actor, bajo el alias “berz0k”, ofreciendo un zero-day de escalada local en Linux por 170.000 dólares, supuestamente funcional en múltiples distribuciones. Según ThreatMon, el vendedor afirma que la vulnerabilidad es de tipo TOCTOU (Time-of-Check Time-of-Use), permite una escalada estable sin provocar cuelgues y utiliza un payload en forma de biblioteca compartida (.so) desplegada en /tmp.

Todo esto alimenta la sensación de saturación y cansancio que muchos administradores expresan: “otra vulnerabilidad de la misma categoría que Dirty Frag”, “ocho más como esta y ya desconecto”, comentan algunos de forma medio en broma, medio en serio. La realidad es que la sucesión de Copy Fail, Dirty Frag y Fragnesia está obligando a los equipos de sistemas a replantearse su estrategia de actualización del kernel, especialmente en entornos donde los reinicios frecuentes son muy costosos.

En este paisaje, soluciones de livepatching como KernelCare o mecanismos similares cobran protagonismo como alternativa para aplicar correcciones críticas sin interrumpir servicios, mientras que las distribuciones se ven presionadas para acortar al máximo los tiempos entre el descubrimiento, la publicación del fix upstream y la disponibilidad del paquete parcheado en repositorios estables.

En última instancia, Fragnesia se ha convertido en un caso de estudio de cómo una pequeña pieza de lógica en un subsistema especializado como XFRM ESP-in-TCP puede tener consecuencias devastadoras cuando se combina con mecanismos de caché de páginas y binarios privilegiados. Mantenerse al tanto de avisos de seguridad, listas de correo, blogs de distribuciones y canales de comunicación como Mattermost o X (antes Twitter) es clave para reaccionar con rapidez y minimizar la ventana de exposición.

La amenaza que representa Fragnesia no radica solo en su capacidad de dar root con un comando, sino en que demuestra hasta qué punto los entornos Linux modernos dependen de una cadena de confianza compleja que va desde el código del kernel hasta las herramientas de actualización y las políticas de endurecimiento. Estar protegido pasa por combinar parches oficiales, mitigaciones bien entendidas, soluciones de livepatch donde tenga sentido y una política clara de control de acceso local y monitorización, de forma que un fallo de este tipo no se convierta en el punto único de fallo para toda la infraestructura.

from Linux Adictos https://ift.tt/bkU2aul
via IFTTT