Se ha revelado una nueva vulnerabilidad de elevación de privilegios locales en el núcleo de Linux, denominada Fragnesia y con el identificador CVE-2026-46300. El problema pertenece a la misma clase de ataques al caché de página que los recientes Copy Fail y Dirty Frag, pero no es una re-publicación de un error antiguo: se trata de un defecto separado en el código XFRM ESP-in-TCP.
La vulnerabilidad fue descubierta por el investigador William Bowling del equipo V12 Security. Según la descripción publicada, Fragnesia permite a un usuario local no privilegiado modificar el contenido de archivos de solo lectura en la memoria del caché de página y, gracias a esto, ejecutar código con privilegios de root. A diferencia de muchos exploits de LPE antiguos, el ataque no requiere condiciones de carrera y es descrito por los investigadores como determinista.
Técnicamente, el problema está relacionado con que al fusionar búferes de red, el núcleo podría haber perdido la señal de que un fragmento de datos es 'compartido' y está relacionado con una página de memoria externa, incluido el caché de página. En el parche propuesto, esto se describe como un error en skb_try_coalesce(): al mover fragmentos paginados de un sk_buff a otro, no se mantenía la bandera SKBFL_SHARED_FRAG. Como resultado, el código posterior de ESP podría erróneamente considerar que el búfer es seguro para modificar.
El efecto práctico es que los datos que previamente fueron colocados en la cola TCP desde un archivo, después de cambiar el socket al modo espintcp, podrían ser procesados por el núcleo como texto cifrado ESP. Al descifrar AES-GCM, los bytes se modificaban directamente en la página del caché de página relacionada con el archivo. Esto no cambia el archivo en disco, pero modifica su representación en la memoria hasta que la página sea desalojada del caché.
En la demostración publicada del ataque, se utilizó /usr/bin/su como objetivo: el exploit modificó los primeros bytes del archivo binario en el caché de página y luego ejecutó la copia modificada en memoria, obteniendo un shell con privilegios de root. El archivo original en disco permaneció inalterado, lo que hace que el problema sea especialmente difícil de diagnosticar: las huellas de explotación pueden desaparecer tras la limpieza del caché de página o un reinicio.
Fragnesia apareció menos de una semana después de Dirty Frag. En V12 subrayan que se trata de un error separado en la misma superficie de ataque — ESP/XFRM — y no un simple renombrado de una vulnerabilidad ya corregida. Phoronix también señala que, en el momento de la publicación, había un proof-of-concept disponible, y la corrección consistía en un pequeño parche para net/core/skbuff.c, que aún no había llegado a las ramas principales del kernel.
Canonical ha asignado CVE-2026-46300 alta prioridad para Ubuntu, indicando la razón como «escalada de privilegios local trivial». En la página de Seguridad de Ubuntu para los núcleos afectados, en el momento de la actualización del 13 de mayo, se mostraba el estado «Needs evaluation», y en la nota se especifica que el problema también está presente en el módulo ESP del kernel y puede ser temporalmente mitigado de la misma manera que Dirty Frag.
Debian Security Tracker en el momento de la verificación marcaba los núcleos en las ramas bullseye, bookworm, trixie, forky y sid como vulnerables; para el paquete linux en unstable aún no se había especificado una versión corregida.
La medida de protección temporal sigue siendo la misma que para Dirty Frag: desactivar la carga de los módulos esp4, esp6 y rxrpc, si no son necesarios para el sistema. Esto puede interrumpir el funcionamiento de los túneles IPsec en nodos donde se utilizan configuraciones de kernel ESP, strongSwan, Libreswan o similares, por lo que en las puertas de enlace VPN esta medida debe aplicarse solo después de evaluar las consecuencias.
Ejemplo de mitigación temporal para administradores:
sudo sh -c "printf ‘install esp4 /bin/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen’ > /etc/modprobe.d/dirtyfrag.conf" sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true
Si hay sospechas de que el sistema ya pudo haber sido atacado, con solo bloquear los módulos no es suficiente: dado que la demostración pública modifica el archivo ejecutable precisamente en el page cache, los administradores recomiendan limpiar la caché de páginas o reiniciar el sistema después de aplicar las medidas de protección. CloudLinux señala explícitamente que, tras la explotación, /usr/bin/su podría permanecer modificado en la memoria hasta que se desalojen las páginas correspondientes.
Para eliminar la regla temporal después de instalar el núcleo corregido, se puede borrar el archivo creado:
sudo rm /etc/modprobe.d/dirtyfrag.conf
La recomendación principal sigue siendo la estándar: instalar el núcleo corregido de su distribución y reiniciar el sistema. Hasta la actualización, el mayor riesgo lo representan los servidores multiusuario, los CI runners, el hosting compartido, las granjas de builds en contenedores y cualquier máquina donde usuarios no privilegiados o parcialmente confiables puedan ejecutar código local.
Fuente: linux.org.ru
