{"id":1354,"date":"2026-05-20T22:30:32","date_gmt":"2026-05-20T20:30:32","guid":{"rendered":"https:\/\/www.glub.biz\/?p=1354"},"modified":"2026-05-11T16:57:18","modified_gmt":"2026-05-11T14:57:18","slug":"dirty-frag-la-nueva-vulnerabilidad-de-linux-que-da-acceso-root-instantaneo-sin-parche-disponible","status":"publish","type":"post","link":"https:\/\/www.glub.biz\/?p=1354","title":{"rendered":"Dirty Frag: la nueva vulnerabilidad de Linux que da acceso root instant\u00e1neo sin parche disponible"},"content":{"rendered":"<p><strong>Dirty Frag encadena dos fallos del kernel para lograr elevaci\u00f3n local de privilegios a root en la mayor\u00eda de distribuciones Linux desde 2017. No hay parches oficiales ni CVE asignados todav\u00eda; la divulgaci\u00f3n se adelant\u00f3 por la rotura de un embargo de seguridad. El fallo afecta a esp4, esp6 y rxrpc en las rutas r\u00e1pidas de descifrado, y se explota con un solo comando y sin condiciones de carrera. La mitigaci\u00f3n recomendada es bloquear los m\u00f3dulos vulnerables (esp4, esp6, rxrpc), especialmente en servidores Linux.<\/strong><img decoding=\"async\" src=\"https:\/\/www.glub.biz\/media\/images\/2026\/dirty-frag.jpg\" alt=\"Dirty Frag\" class=\"alignnone size-medium\" width=\"480\"><\/p>\n<p>La comunidad Linux se enfrenta a una nueva vulnerabilidad cr\u00edtica de elevaci\u00f3n local de privilegios bautizada como Dirty Frag, descubierta apenas una semana despu\u00e9s del fallo Copy Fail. Este nuevo problema de seguridad, explicado ampliamente en GitHub, permite que cualquier usuario local sin privilegios consiga acceso de administrador (root) en la mayor\u00eda de distribuciones Linux actuales, y lo m\u00e1s preocupante es que, por ahora, no existe parche oficial ni identificador CVE asignado.<\/p>\n<p>Dirty Frag se ha dado a conocer antes de lo previsto tras la rotura de un embargo de seguridad. Un tercero no relacionado con la investigaci\u00f3n hizo p\u00fablica parte de la informaci\u00f3n, lo que llev\u00f3 al investigador a publicar detalles t\u00e9cnicos y prueba de concepto antes de que los mantenedores del kernel y las distribuciones tuvieran listas las correcciones. Esto deja a administradores de sistemas con una situaci\u00f3n delicada: una vulnerabilidad explotable de forma fiable y sin soluci\u00f3n definitiva disponible todav\u00eda.<\/p>\n<p><!--more--><\/p>\n<p><strong>Qu\u00e9 es Dirty Frag y por qu\u00e9 preocupa tanto<\/strong><\/p>\n<p>Dirty Frag ha sido presentada como la sucesora directa de Copy Fail y forma parte de la misma familia de fallos que Dirty Pipe. Todas estas vulnerabilidades comparten una idea de fondo: aprovechar errores en la gesti\u00f3n de la page cache del kernel, es decir, en la copia en memoria que Linux mantiene de los archivos para mejorar el rendimiento.<\/p>\n<p>En t\u00e9rminos pr\u00e1cticos, el ataque consigue que el propio kernel sobrescriba contenido en la page cache de un archivo sin que el atacante tenga permisos de escritura sobre dicho archivo. Esa sobrescritura controlada se convierte en una primitiva de escritura arbitraria que, bien explotada, permite escalar privilegios hasta root con una \u00fanica ejecuci\u00f3n del exploit.<\/p>\n<p>Seg\u00fan el investigador surcoreano Hyunwoo Kim (conocido como @v4bel), Dirty Frag no es un simple bug puntual, sino una clase de vulnerabilidad l\u00f3gica que ampl\u00eda la misma familia a la que pertenecen Dirty Pipe y Copy Fail. No depende de condiciones temporales ni de carreras (race conditions), lo que implica que el exploit es determinista, no provoca cuelgues del kernel en caso de fallo y tiene una tasa de \u00e9xito muy alta en sistemas vulnerables.<\/p>\n<p><strong>Dos vulnerabilidades encadenadas para lograr root<\/strong><\/p>\n<p>Una de las caracter\u00edsticas clave de Dirty Frag es que no se basa en un solo fallo, sino que encadena dos vulnerabilidades diferentes del kernel de Linux para lograr un ataque casi universal sobre los sistemas modernos:<\/p>\n<ul>\n<li>xfrm-ESP Page-Cache Write \u2013 Vulnerabilidad en la pila de red IPsec\/ESP (funci\u00f3n esp_input()), introducida en un commit de enero de 2017 (cac2661c53f3). Permite un almacenamiento de 4 bytes directamente en la page cache, en una posici\u00f3n y con un valor controlados por el atacante.<\/li>\n<li>RxRPC Page-Cache Write \u2013 Fallo en el subsistema RxRPC\/rxkad (funci\u00f3n rxkad_verify_packet_1()), presente desde junio de 2023. Realiza una escritura de 8 bytes en la page cache aprovechando el descifrado, sin requerir privilegios para crear namespaces, y la clave se puede fuerza bruta completamente desde espacio de usuario.<\/li>\n<\/ul>\n<p>El primer fallo se encuentra en el subsistema IPsec (xfrm) y se aprovecha cuando un socket buffer no lineal con p\u00e1ginas \u00abspliced\u00bb (p\u00e1ginas de la page cache asociadas mediante operaciones como splice(2) o sendfile(2)) esquiva la verificaci\u00f3n de copia por escritura (skb_cow_data()). En ese escenario, el camino r\u00e1pido de descifrado ESP escribe directamente sobre esas p\u00e1ginas, lo que abre la puerta a modificar datos sobre los que un proceso sin privilegios mantiene referencia.<\/p>\n<p>En el caso de RxRPC, la ruta de descifrado aplica un decrypt in-place sobre p\u00e1ginas de la page cache igualmente \u00abancladas\u00bb por el usuario, pero sin necesidad de permisos especiales como la creaci\u00f3n de namespaces. El atacante prepara en espacio de usuario un bloque cifrado tal que, al ser descifrado por el kernel, el resultado sea exactamente la escritura deseada en memoria.<\/p>\n<p><strong>Por qu\u00e9 Dirty Frag afecta a casi todas las distribuciones<\/strong><\/p>\n<p>EPor separado, ninguno de los dos fallos cubre todos los escenarios. El exploit xfrm-ESP requiere que un usuario sin privilegios pueda crear namespaces de usuario, algo que en algunas configuraciones de Ubuntu se bloquea con AppArmor. En cambio, el exploit de RxRPC no necesita namespaces, pero el m\u00f3dulo rxrpc.ko no se incluye por defecto en la mayor\u00eda de distribuciones corporativas como ciertas versiones de RHEL.<\/p>\n<p>La clave de Dirty Frag est\u00e1 en usar ambos caminos de explotaci\u00f3n de forma complementaria. En sistemas donde se permiten namespaces de usuario, se dispara primero la variante ESP; en entornos como muchas instalaciones de Ubuntu, donde la creaci\u00f3n de namespaces est\u00e1 limitada pero el m\u00f3dulo rxrpc se carga por defecto, entra en juego la variante RxRPC. De este modo, las \u00abzonas ciegas\u00bb de una v\u00eda de ataque quedan cubiertas por la otra, logrando un exploit pr\u00e1cticamente universal.<\/p>\n<p>Entre las distribuciones confirmadas como afectadas se encuentran Ubuntu 24.04.4, distintas versiones de RHEL 10.1, CentOS Stream 10, AlmaLinux 10, Fedora 44 y openSUSE Tumbleweed, adem\u00e1s de otras plataformas populares como Arch Linux o entornos WSL2 en Windows. En la pr\u00e1ctica, esto significa que una gran parte de los servidores y equipos de escritorio Linux en uso pueden ser vulnerables si re\u00fanen los m\u00f3dulos y configuraciones implicadas.<\/p>\n<p><strong>Relaci\u00f3n con Copy Fail y otros fallos recientes<\/strong><\/p>\n<p>Dirty Frag llega justo despu\u00e9s de Copy Fail (CVE-2026-31431), que ya forz\u00f3 a acelerar parches en m\u00faltiples distribuciones Linux ante un fallo de elevaci\u00f3n de privilegios que se est\u00e1 explotando activamente. Ambos comparten la idea de abusar de la page cache y de rutas r\u00e1pidas de E\/S, pero Dirty Frag tiene una ventaja preocupante: funciona incluso en sistemas donde se han aplicado las mitigaciones de Copy Fail, como el bloqueo del m\u00f3dulo algif_aead o pol\u00edticas de Lockdown del kernel.<\/p>\n<p>El investigador remarca que Dirty Frag puede dispararse independientemente de que el m\u00f3dulo algif_aead est\u00e9 habilitado o se haya bloqueado. Es decir, incluso si un servidor en producci\u00f3n ya implement\u00f3 las recomendaciones para Copy Fail, sigue siendo vulnerable a este nuevo exploit mientras no se actualice el kernel con los parches espec\u00edficos o se apliquen las medidas temporales de mitigaci\u00f3n.<\/p>\n<p><strong>Impacto en entornos empresariales<\/strong><\/p>\n<p>En el contexto donde Linux es ampliamente utilizado en centros de datos, proveedores cloud y administraci\u00f3n p\u00fablica, Dirty Frag supone un riesgo elevado de escalada lateral dentro de redes internas. Un atacante que logre acceso de usuario normal (por ejemplo, a trav\u00e9s de credenciales robadas, una aplicaci\u00f3n web vulnerable o un servicio mal configurado) podr\u00eda conseguir root local de forma inmediata y sin necesidad de explotar condiciones complejas.<\/p>\n<p>Para organizaciones que operan servicios cr\u00edticos sobre distribuciones como Ubuntu, RHEL, CentOS Stream, Fedora o AlmaLinux, el problema no se limita a un \u00fanico proveedor: la vulnerabilidad reside en el propio kernel de Linux. Algunos proyectos, como AlmaLinux, ya han comenzado a trabajar en parches tempranos para pruebas, pero a fecha de divulgaci\u00f3n no existe todav\u00eda una soluci\u00f3n oficial ampliamente desplegada.<\/p>\n<p>Este escenario obliga a muchos equipos de seguridad y de sistemas a implementar medidas provisionales, revisar sus inventarios de servidores y estaciones de trabajo, y priorizar aquellos entornos donde haya usuarios con shell interactiva o capacidades para ejecutar binarios en el sistema, y asegurar credenciales (por ejemplo, cambiar la contrase\u00f1a de root), ya que es justo el vector que Dirty Frag explota.<\/p>\n<p><strong>D\u00f3nde se encuentra el fallo en el kernel<\/strong><\/p>\n<p>A nivel t\u00e9cnico, Dirty Frag reside en las rutas r\u00e1pidas de descifrado in-place de los m\u00f3dulos de red esp4, esp6 y rxrpc del kernel. Cuando un paquete de red llega envuelto en ESP o a trav\u00e9s de RxRPC, el camino de recepci\u00f3n intenta descifrarlo sin copias adicionales de datos para ganar rendimiento.<\/p>\n<p>El problema aparece cuando esos paquetes llevan fragmentos de memoria paginada que no son de propiedad exclusiva del kernel, como p\u00e1ginas de la page cache asociadas por operaciones de splice o MSG_SPLICE_PAGES. En lugar de trabajar sobre un buffer privado, el kernel escribe directamente sobre esas p\u00e1ginas compartidas, que siguen referenciadas por un proceso de usuario sin privilegios. Esto deja expuesto el texto en claro de los datos o, peor a\u00fan, permite su corrupci\u00f3n deliberada.<\/p>\n<p>De acuerdo con an\u00e1lisis publicados en listas de correo de seguridad como oss-security y netdev, el commit de enero de 2017 que introdujo la vulnerabilidad xfrm-ESP ya fue tambi\u00e9n la ra\u00edz de un desbordamiento de b\u00fafer anterior (CVE-2022-27666), lo que apunta a que el mismo cambio en el c\u00f3digo ha generado varios problemas de seguridad en estos a\u00f1os.<\/p>\n<p><strong>Ausencia de parches y rotura del embargo<\/strong><\/p>\n<p>Dirty Frag fue reportado de forma privada a los mantenedores del kernel de Linux el 30 de abril de 2026. El plan original era mantener la informaci\u00f3n bajo embargo hasta mediados de mayo para dar margen a preparar parches, coordinar su liberaci\u00f3n con las distribuciones y minimizar la ventana de exposici\u00f3n.<\/p>\n<p>Sin embargo, un tercero ajeno al proceso de coordinaci\u00f3n public\u00f3 detalles del exploit ESP el 7 de mayo, rompiendo el embargo. Ante esta situaci\u00f3n, el investigador decidi\u00f3 hacer p\u00fablica la informaci\u00f3n completa, incluida una prueba de concepto funcional capaz de obtener root con un solo comando. El resultado es que la mayor\u00eda de distribuciones y en el resto del mundo se han visto obligadas a reaccionar sobre la marcha, sin tener soluciones listas.<\/p>\n<p>En el momento de la divulgaci\u00f3n, no exist\u00edan parches oficiales en el \u00e1rbol principal del kernel ni versiones actualizadas distribuidas por los principales fabricantes. Algunos proveedores, como AlmaLinux, han lanzado parches preliminares para pruebas internas, pero los administradores siguen dependiendo sobre todo de medidas de mitigaci\u00f3n a nivel de configuraci\u00f3n.<\/p>\n<p><strong>C\u00f3mo mitigar Dirty Frag mientras llegan los parches<\/strong><\/p>\n<p>Ante la ausencia de actualizaciones inmediatas, la recomendaci\u00f3n generalizada de la comunidad de seguridad es bloquear o deshabilitar los m\u00f3dulos del kernel implicados en el fallo: esp4, esp6 y rxrpc. Esto evita que las rutas vulnerables puedan cargarse o utilizarse, reduciendo dr\u00e1sticamente la superficie de ataque.<\/p>\n<p>Para la mayor\u00eda de sistemas de escritorio y servidores generales, estos m\u00f3dulos no son imprescindibles, ya que se relacionan principalmente con la funcionalidad IPsec (cifrado de tr\u00e1fico de red) y con RxRPC, un mecanismo de llamada a procedimiento remoto menos habitual en despliegues est\u00e1ndar. No obstante, en entornos que utilizan VPN IPsec basadas en ESP u otros servicios espec\u00edficos, deshabilitarlos puede afectar a la conectividad y conviene valorar los riesgos.<\/p>\n<p>Una forma r\u00e1pida y automatizada de aplicar esta mitigaci\u00f3n consiste en crear una configuraci\u00f3n de modprobe que fuerce la sustituci\u00f3n de los m\u00f3dulos vulnerables por un binario inocuo, y descargarlos si ya estaban activos. Diversas fuentes de seguridad han difundido una l\u00ednea de comandos similar a la siguiente:<\/p>\n<table>\n<tr style=\"background-color: #ccffcc;\">\n<td>\n&nbsp;&nbsp;sudo sh -c \u00abprintf &#8216;install esp4 \/bin\/false;<br \/>\n&nbsp;&nbsp;install esp6 \/bin\/false;<br \/>\n&nbsp;&nbsp;install rxrpc&#8217; > \/etc\/modprobe.d\/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>\/dev\/null;<br \/>\n&nbsp;&nbsp;true\u00bb\/bin\/false;\n<\/td>\n<\/tr>\n<\/table>\n<p>Este comando crea el archivo \/etc\/modprobe.d\/dirtyfrag.conf con reglas que impiden que los m\u00f3dulos esp4, esp6 y rxrpc vuelvan a cargarse, y a continuaci\u00f3n intenta descargarlos si estaban ya en memoria. Para la inmensa mayor\u00eda de servidores web, bases de datos o aplicaciones de negocio habituales en infraestructuras, no deber\u00eda causar interrupciones, aunque siempre se recomienda probar primero en entornos de preproducci\u00f3n.<\/p>\n<p><strong>Pruebas de concepto y riesgo de explotaci\u00f3n real<\/strong><\/p>\n<p>Junto a la divulgaci\u00f3n p\u00fablica de Dirty Frag, el investigador ha publicado en GitHub un repositorio con el c\u00f3digo de la prueba de concepto, que permite compilar y ejecutar el exploit con un par de comandos. El binario resultante encadena las dos v\u00edas de ataque (ESP y RxRPC) y, en sistemas vulnerables, eleva el usuario actual a root de forma inmediata.<\/p>\n<p>Algunos medios t\u00e9cnicos que han analizado el fallo indican que han podido reproducir la vulnerabilidad en distintas distribuciones, incluidas instalaciones actualizadas de Arch Linux y sistemas con kernel principal reciente. Incluso se ha constatado que entornos como WSL2, usados cada vez m\u00e1s por desarrolladores, presentan el mismo comportamiento si el kernel subyacente re\u00fane las condiciones necesarias.<\/p>\n<p>La combinaci\u00f3n de un exploit p\u00fablico sencillo de usar y una ventana sin parches disponibles eleva la probabilidad de que grupos maliciosos intenten integrar Dirty Frag en sus cadenas de ataque. Para muchas organizaciones, esto significa revisar con urgencia sus controles de acceso, endurecer la segmentaci\u00f3n de redes internas y reforzar la supervisi\u00f3n de actividades sospechosas en servidores Linux.<\/p>\n<p><strong>Respuesta de las distribuciones y pr\u00f3ximos pasos<\/strong><\/p>\n<p>Aunque el anuncio pill\u00f3 por sorpresa a buena parte del ecosistema, varios proveedores de sistemas Linux han empezado a trabajar en parches espec\u00edficos para las rutas de descifrado afectadas. El propio investigador remiti\u00f3 el arreglo para la parte de RxRPC a la lista de correo netdev a finales de abril, y se espera que en los pr\u00f3ximos d\u00edas o semanas se integren soluciones en las ramas estables del kernel.<\/p>\n<p>En el caso de distribuciones con fuerte presencia, como Ubuntu, Debian, RHEL, SUSE, openSUSE, Fedora o AlmaLinux, la atenci\u00f3n se centra en enviar actualizaciones de kernel debidamente testeadas a trav\u00e9s de sus canales de seguridad habituales. Mientras tanto, se insta a administradores y responsables de TI a seguir de cerca los avisos de seguridad y a aplicar las actualizaciones tan pronto como est\u00e9n disponibles en los repositorios oficiales.<\/p>\n<p>La experiencia reciente con Dirty Pipe, Copy Fail y ahora Dirty Frag pone de manifiesto la necesidad de mejorar las revisiones de seguridad en partes cr\u00edticas del kernel, especialmente en zonas de alto rendimiento como las rutas r\u00e1pidas de red y de E\/S, donde las optimizaciones agresivas pueden introducir errores sutiles pero muy peligrosos.<\/p>\n<p>La aparici\u00f3n de Dirty Frag, sumada a otros fallos recientes, vuelve a poner el foco en la importancia de mantener una pol\u00edtica de actualizaci\u00f3n \u00e1gil y controles de defensa en profundidad en cualquier infraestructura Linux. Aunque todav\u00eda no haya parches definitivos para esta vulnerabilidad, deshabilitar los m\u00f3dulos implicados, supervisar los sistemas y prepararse para desplegar r\u00e1pidamente las futuras actualizaciones del kernel se ha convertido, por ahora, en el mejor plan de contingencia para minimizar el impacto de este nuevo vector de ataque.<\/p>\n<p>Fuente: <a href=\"https:\/\/www.linuxadictos.com\/dirty-frag-la-nueva-vulnerabilidad-de-linux-que-da-acceso-root-instantaneo-sin-parche-disponible.html\" target=\"_blank\" rel=\"noopener noreferrer\">LinuxAdictos<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Dirty Frag encadena dos fallos del kernel para lograr elevaci\u00f3n local de privilegios a root en la mayor\u00eda de distribuciones Linux desde 2017. No hay parches oficiales ni CVE asignados todav\u00eda; la divulgaci\u00f3n se adelant\u00f3 por la rotura de un &hellip; <a href=\"https:\/\/www.glub.biz\/?p=1354\">Sigue leyendo <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-1354","post","type-post","status-publish","format-standard","hentry","category-noticias"],"_links":{"self":[{"href":"https:\/\/www.glub.biz\/index.php?rest_route=\/wp\/v2\/posts\/1354","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.glub.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.glub.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.glub.biz\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.glub.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1354"}],"version-history":[{"count":13,"href":"https:\/\/www.glub.biz\/index.php?rest_route=\/wp\/v2\/posts\/1354\/revisions"}],"predecessor-version":[{"id":1367,"href":"https:\/\/www.glub.biz\/index.php?rest_route=\/wp\/v2\/posts\/1354\/revisions\/1367"}],"wp:attachment":[{"href":"https:\/\/www.glub.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1354"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.glub.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1354"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.glub.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1354"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}