DirtyClone y el error del marcador «Shared-Frag» que no deja de reaparecer

La versión resumida

Ir a la versión completa ↓

¿Qué: DirtyClone, registrado como 43503, es una vulnerabilidad de escalada de privilegios locales en el núcleo de Linux, concretamente en la pila de red: algunas rutas de transferencia de fragmentos skb descartan el SKBFL_SHARED_FRAG marcador que bloquea las escrituras in situ, lo que permite que los datos de entrada de ESP (IPsec) se descifren directamente en las páginas de la caché de páginas respaldadas por archivos. Se trata de una escritura arbitraria en archivos de solo lectura propiedad del usuario «root», un ataque «Dirty COW» a través de la pila de red en lugar de /proc/self/mem.

Repercusión: Un usuario local sin privilegios convierte la pérdida del marcador en una escritura en la caché de páginas sobre un archivo binario como /usr/bin/su, y luego aprovecha la imagen envenenada para obtener privilegios de root. JFrog publicó un tutorial sobre el exploit el 25 de junio; el PoC público (rafaeldtinoco/security/exploits/dirtyclone, basado en la primitiva DirtyFrag de Hyunwoo Kim) se reproduce en núcleos más antiguos. El archivo del disco nunca cambia, por lo que las herramientas de integridad de archivos no lo detectan.

Estado: DirtyClone pertenece a la familia DirtyFrag/Fragnesia: se pierde un marcador de seguridad cuando la memoria respaldada por archivos se desplaza a través de rutas de red de alta velocidad, y una escritura posterior in situ se produce en el lugar donde debería haberse copiado. JFrog lo notificó el 19 de mayo; la corrección se incluyó en la versión v7.1-rc5 el 24 de mayo. Esto lo convierte en un «N-day» para los entornos RHEL a los que les falte parte de la cadena de correcciones, no en un nuevo «0-day».

Gravedad: Red Hat la califica como «Importante», CVSS 7.0; kernel.org le otorga una puntuación de 8,8, debido a una menor complejidad de ataque y a que el alcance se ha modificado (en lugar de mantenerse sin cambios), pero, en cualquier caso, el resultado es el acceso con privilegios de root. Clase de fallo: un fallo en la propagación de marcadores de fragmentos compartidos que provoca escrituras in situ inseguras en la memoria respaldada por la caché de páginas.

Por qué es importante: Los sistemas expuestos son aquellos en los que el aislamiento es el objetivo: hosts multitenant, ejecutores de CI, contenedores y nodos de Kubernetes, así como entornos de pruebas de desarrollo a los que se puede acceder a través de CAP_NET_ADMIN, que muchas distribuciones conceden por defecto a los usuarios sin privilegios dentro de un espacio de nombres. En este contexto, «local» no significa «bajo riesgo».

Haz esto ahora mismo: La corrección ya está disponible en las versiones EL9 y EL10, así que actualiza y reinicia el sistema. Si aún no puedes aplicar el parche, desactiva los espacios de nombres de usuario sin privilegios o bloquea esp4/esp6 carga automática cuando no se utiliza IPsec. KernelCare Los usuarios ya disponen de un parche que no requiere reinicio para los núcleos EL9/EL10 afectados. A continuación se ofrecen más detalles.

Algunos de los errores más graves del núcleo de Linux no surgen inicialmente como una vulnerabilidad evidente de «escritura en archivos raíz». Comienzan como errores de registro. DirtyClone es uno de ellos. Una operación de red posterior confía en un marcador de propiedad que falta en los fragmentos del búfer de sockets, lo que hace que escriba directamente sobre ellos.

La pila de red de Linux transfiere los paquetes de datos a través de búferes de socket, o skbs. Parte de esos datos se almacena en forma de fragmentos de página, en lugar de copiarse byte a byte en la memoria privada. Esto es beneficioso para el rendimiento, pero no permite ningún margen de error en cuanto a la propiedad, ya que un fragmento puede apuntar a una página compartida, de propiedad externa o respaldada por la caché de páginas. Antes de que cualquier código escriba en una página de este tipo, debe saber que no es seguro modificarla in situ.

Esa es precisamente la función de SKBFL_SHARED_FRAG. El marcador indica al código posterior de procesamiento de paquetes que un skb contiene fragmentos compartidos y que no se permite la modificación in situ a menos que el núcleo copie primero los datos a la memoria privada. El «DirtyClone» se produce cuando ese marcador se pierde mientras los fragmentos se trasladan de un skb a otro. Nombres de NVD __pskb_copy_fclone() y skb_shift() entre los ayudantes que pueden mover descriptores de fragmentos sin trasladar el marcador, dejando que el SKB de destino conserve referencias respaldadas por la caché de páginas, mientras que skb_has_shared_frag() devuelve «false».

Esa respuesta errónea es la vulnerabilidad. Un escritor in situ posterior examina el skb, comprueba si los fragmentos son compartidos, obtiene una respuesta negativa y escribe directamente en la página subyacente. Entrada ESP en esp4.c Es precisamente ese tipo de escritor, y es ahí donde desemboca la explotación del público.

DirtyClone completa un conjunto de estos errores que han ido apareciendo a lo largo de la primavera, todos ellos con el mismo modo de fallo. La memoria de la caché de páginas respaldada por archivos se trata como datos de paquetes normales, y luego una operación de red in situ escribe donde debería haber copiado. «Copy Fail» fue el primero, a finales de abril. «DirtyFrag» le siguió el 7 de mayo. «Fragnesia» eludió el parche de «DirtyFrag» el 13 de mayo. «DirtyClone» es el cuarto, al que se accede a través de otra ruta de clonación de paquetes que omite el mismo marcador de un bit.

Esta es la parte que debería determinar cómo evaluar la gravedad del problema. DirtyClone no es una vulnerabilidad «0-day» recién descubierta que afecte a entornos totalmente actualizados. Lo que JFrog publicó el 25 de junio es una demostración de que las rutas de código residuales que quedan abiertas tras un parche parcial siguen siendo accesibles. La palabra clave es «completo». Un núcleo solo está protegido cuando incorpora toda la cadena de DirtyFrag y Fragnesia. Uno que haya aplicado la corrección original de DirtyFrag pero se haya saltado las actualizaciones posteriores sigue teniendo una ruta accesible al mismo sumidero ESP. Los núcleos actuales EL9 y EL10 de Red Hat ya incorporan la retrocompatibilidad completa, por lo que el peligro recae en los núcleos que llevan algunas actualizaciones de retraso, más que en los actuales.

Cómo funciona DirtyClone

La cadena pública va desde una configuración de socket sin privilegios hasta una escritura arbitraria en la caché de páginas con privilegios.

[Unprivileged user + network namespace]
│  attacker obtains CAP_NET_ADMIN inside the namespace
▼
[netfilter TEE rule clones ESP-in-UDP packets]
│  clone routed through __pskb_copy_fclone(), marker dropped
▼
[Mislabelled skb: references page-cache pages,
reports skb_has_shared_frag() == false]
▼
[XFRM ESP transport SA decrypts in place]
│  esp_input() AES-CBC writes over the target file's page cache
▼
[Arbitrary content in root-owned page cache]
│  overwrite /usr/bin/su (or /etc/sudoers.d/* via an NSS load)
▼
[uid=0 root shell]

El marcador. El núcleo marca cualquier SKB que contenga referencias a páginas que no le pertenezcan con SKBFL_SHARED_FRAG, y skb_has_shared_frag() lee esa etiqueta para decidir si una carga útil puede modificarse in situ. Cuando un ayudante de transferencia de fragmentos traslada fragmentos paginados entre SKB sin transferir el marcador, el SKB de destino conserva las referencias a páginas de propiedad externa o respaldadas por la caché de páginas, al tiempo que indica que no se comparte nada.

El fregadero. Un escritor posterior que se ejecuta in situ se basa en ese informe. En el caso de DirtyClone, el escritor es esp_input() Descifrado AES-CBC, que descifra directamente esas páginas, incluida la caché de páginas de los archivos de solo lectura propiedad del usuario root. Al controlar la clave ESP y la asociación de seguridad, además de las páginas de origen modificadas, el atacante aprovecha esto para escribir contenido arbitrario en la caché de páginas con privilegios.

La ruta. Red Hat atribuye la exposición de EL9 y EL10 a skb_try_coalesce() la pérdida del marcador (Bugzilla 2480902), y señala que esa misma pérdida puede producirse en toda una familia de ayudantes, entre los que se incluyen __pskb_copy_fclone(), skb_shift(), skb_gro_receive(), y skb_segment(). El PoC público llega al mismo receptor ESP por una puerta diferente. Se ejecuta dentro de un espacio de nombres de usuario y de red sin privilegios, e instala una regla TEE de netfilter que clona los paquetes ESP-in-UDP a través de __pskb_copy_fclone(), lo que elimina el marcador y, a continuación, instala las SA de transporte XFRM ESP para que el paquete clonado y mal etiquetado se descifre in situ sobre la caché de páginas del archivo de destino.

Lo importante es que esto no es una edición /usr/bin/su en el disco, en el sentido habitual. Corrompe la copia de la caché de páginas en memoria que el núcleo proporciona posteriormente a una ruta de ejecución privilegiada. Eso es lo que hace que la supervisión convencional de la integridad de los archivos resulte un control ineficaz en este caso. El archivo en el disco permanece intacto, la modificación se produce en la copia en memoria del núcleo, y al reiniciar el sistema se restaura el binario original, normalmente mucho después de que el atacante ya haya obtenido privilegios de root.

Hay un detalle importante en cuanto al alcance. El archivo README del PoC especifica un intervalo reducido de la rama principal, desde la versión v7.1-rc1 hasta la rc4, pero las pruebas internas han demostrado que el problema se reproduce sin modificaciones en los núcleos adaptados a EL9 y EL10. Ese intervalo de la rama principal no limita el impacto en las distribuciones de la familia RHEL. No te limites a leer el rango de versiones del README y concluyas que tu sistema EL queda fuera del alcance.

Qué cambia con la corrección de Upstream

La corrección es mínima, y precisamente por eso la familia sigue generando variantes. Hace que los ayudantes de transferencia de fragmentos propaguen el marcador de fragmentos compartidos, de modo que un skb de destino que siga haciendo referencia a páginas respaldadas por la caché de páginas o de propiedad externa informe de skb_has_shared_frag() como verdadera. El escritor in situ posterior se niega entonces a modificar esas páginas y recurre a una copia segura. La corrección se incorporó al código fuente original el 21 de mayo y se incluyó en Linux v7.1-rc5 el 24 de mayo, como parte de la misma serie que solucionó los errores anteriores relacionados con DirtyFrag. Los ID de las confirmaciones en la versión estable y en las versiones anteriores varían según la rama, por lo que es mejor consultar el aviso de tu distribución en lugar de basarte en un único hash del código fuente original.

¿A quién afecta?

Para los usuarios generales de Linux, existe riesgo si el núcleo en ejecución carece de la cadena completa de correcciones de DirtyFrag, Fragnesia y DirtyClone, y el sistema permite que código local no fiable acceda a las capacidades de red que necesita el exploit. Los informes públicos señalan a Debian, Fedora y Ubuntu entre las distribuciones en las que los espacios de nombres de usuario sin privilegios facilitan la explotación en configuraciones habituales. Ubuntu 24.04 y versiones posteriores incorporan restricciones de AppArmor que pueden bloquear la ruta de explotación predeterminada, pero eso supone un refuerzo en una sola vía, no una garantía de que el núcleo subyacente esté corregido.

En el caso de los sistemas de la familia RHEL, el panorama es más limitado y todo se reduce a dos preguntas: ¿El núcleo es el responsable de las errata «DirtyFrag» y «Fragnesia»? ¿Y el servidor ejecuta un parche que no requiere reinicio?

Vulnerabilidad explotable, reproducida internamente en núcleos que carecen de la cadena completa:

• EL9 activado 5.14.0-611.49.2.el9_7, sobrescribe /usr/bin/su y rendimientos uid=0.
• EL10 activado 6.12.0-55.27.1.el10_0, mismo resultado.

No es vulnerable:

• Kernels de serie actuales que ya incluyen la corrección completa de DirtyFrag y Fragnesia, por ejemplo, EL10 6.12.0-211.16.1.el10_2, donde el PoC no se reproduce.
• Cualquier servidor protegido por el parche «rebootless» en el esp4 módulo.

No se ve afectado por CVE-2026-43503:

• RHEL 6, 7 y 8. Red Hat indica que estas versiones no se ven afectadas por este CVE concreto. Hay que interpretar esto de forma restrictiva. Las listas de flujos afectados varían según la familia DirtyFrag, por lo que un flujo que no se vea afectado por el CVE-2026-43503 no tiene por qué estar libre de todos los CVE relacionados.

Red Hat indica que RHEL 9 y RHEL 10, además de OpenShift RHCOS, son las versiones afectadas por el CVE-2026-43503. Esto se refiere a la versión del código afectada, no a un host totalmente actualizado. Hay que interpretar «afectado» en el sentido de «este código se incluyó aquí», y no como «todos los equipos actuales con RHEL 9 o 10 son vulnerables en este momento».

El momento de la actualización también varía según la distribución y la versión del núcleo. CloudLinux (CL8 y CL9), en particular, puede ir con retraso respecto a las actualizaciones de EL para esta familia, por lo que los usuarios de CL deberían confirmar su versión exacta en lugar de dar por hecho que es la misma.

Una advertencia que se aplica a toda la familia. Un host que simplemente no cumple los supuestos del PoC no es lo mismo que un host que se ha corregido. Comprueba que el núcleo incorpore todas las correcciones, en lugar de dar por sentado que el hecho de que un exploit no se haya ejecutado con éxito significa que estás a salvo.

Actúa ya

La solución definitiva consiste en un kernel parcheado o un parche que no requiera reiniciar el sistema. Hasta que eso se generalice, las medidas más útiles son aquellas que eliminan los requisitos previos para el exploit.

1. Instala primero el parche o aplica un parche que no requiera reiniciar el sistema

Instala el kernel corregido de tu distribución y reinicia el sistema para que se aplique, o aplica un parche que no requiera reinicio si este no es posible. La corrección ya está disponible en los repositorios de EL9 y EL10, por lo que en la mayoría de los equipos se trata de una simple actualización y no hay que esperar.

2. Restringir los espacios de nombres de los usuarios sin privilegios

La cadena necesita CAP_NET_ADMIN Los usuarios sin privilegios pueden instalar la regla TEE y el SA XFRM. Si se elimina eso, la ruta pública deja de funcionar.

# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-dirtyclone.conf

# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-dirtyclone.conf

Radio de impacto. Esto hace que Podman sin privilegios de root y Docker sin privilegios de root dejen de funcionar, unshare(1), el entorno aislado de Chromium, algunos entornos aislados de CI y los Flatpaks de bwrap. Aceptable en la mayoría de las flotas de servidores con restricciones de seguridad, pero puede causar problemas en los contenedores y en los servidores de los desarrolladores. Prueba antes de un despliegue generalizado.

3. Desactivar la carga automática del módulo ESP cuando no se utilice IPsec

No esp4 o esp6, no hay un destino de descifrado in situ para la ruta DirtyClone.

echo -e 'install esp4 /bin/false\ninstall esp6 /bin/false' | sudo tee /etc/modprobe.d/dirtyclone-esp.conf

No apliques esto en servidores que utilicen IPsec o XFRM, ya que desactiva el transporte ESP y provocará fallos en tus túneles. Una nota para toda la comunidad: el trabajo anterior sobre DirtyFrag también implicaba rxrpc como destino de escritura in situ, por lo que reforzar la seguridad frente a toda la familia puede suponer bloquear rxrpc también. Esa medida afecta al funcionamiento de AFS y otras cargas de trabajo que dependen de RxRPC, por lo que debes aplicarla con cuidado y solo en aquellos casos en los que no se utilicen esas funciones. Para revertir cualquier medida correctiva, elimina los archivos de sustitución y vuelve a cargar el sistema.

sudo rm -f /etc/modprobe.d/dirtyclone-esp.conf /etc/sysctl.d/99-dirtyclone.conf
sudo sysctl --system

Momento decisivo. Si el servidor no ejecuta IPsec ni contenedores sin privilegios de root, cualquiera de las dos opciones es válida y el bloque del módulo ESP supone el cambio menos invasivo. Si necesita IPsec pero no contenedores sin privilegios de root, desactiva los usuarios sin privilegios. Si necesita tanto IPsec como contenedores sin privilegios de root, un parche que no requiera reinicio o un kernel corregido es la única solución que no interrumpe la carga de trabajo, y debes aislar la ejecución local no fiable hasta que se implemente una de estas soluciones.

Parcheo sin reinicio

Este es precisamente el tipo de fallo para el que existen soluciones de aplicación de parches sin necesidad de reiniciar, como KernelCare. Reiniciar toda una flota con un kernel corregido es fácil de decir, pero difícil de programar, y la aplicación de parches sin interrupciones cubre esa misma necesidad sin afectar al tiempo de actividad.

En los núcleos EL9 y EL10 afectados, se instala en el esp4 módulo y desactiva el receptor de descifrado de la entrada ESP justo en el momento en que se produciría la escritura no segura. Cuando falta el marcador de fragmento compartido debido al error de propagación, se rechaza el descifrado in situ de los fragmentos respaldados por la caché de páginas, en lugar de llevarlo a cabo. Ofrece la misma garantía que la corrección del marcador del proyecto original, pero se aplica sin que nadie tenga que intervenir en una ventana de mantenimiento.

Dado que DirtyClone y CVE-2026-46300 comparten un mismo fallo de origen y una misma corrección, un único parche que no requiere reinicio cubre ambos. Es importante tenerlo en cuenta a la hora de verificar la cobertura: en algunas herramientas, la protección aparece bajo el CVE-2026-46300, en lugar de bajo el CVE-2026-43503, ya que la asignación del CVE puede ir con retraso respecto a la propia corrección.

El beneficio en este caso es limitado, pero real, y es precisamente en lo que destaca la aplicación de parches sin necesidad de reinicio. Los servidores que corren mayor riesgo son aquellos que van retrasados en las actualizaciones del núcleo, y esos son precisamente los servidores en los que, para empezar, resulta más difícil programar un reinicio de emergencia. Poder cerrar DirtyClone en ellos sin necesidad de ese reinicio marca la diferencia entre solucionarlo hoy y hacerlo en la próxima ventana de mantenimiento, y para muchas flotas ese intervalo es donde reside el verdadero riesgo.

Detección

No existe ninguna firma fiable en el disco para DirtyClone, y eso constituye una parte fundamental del riesgo. La corrupción se produce en la caché de páginas; el binario del disco permanece intacto, y la expulsión de la caché o un reinicio restauran los bytes originales. Esto no anula la persistencia, los cambios en las cuentas ni las actividades posteriores a que el atacante haya obtenido privilegios de root. El hash de archivos es un control débil en este caso.

Puede que no deje rastros evidentes que indiquen una alteración de la integridad de los archivos, pero no es invisible. Es más probable que su detección se base en la telemetría de comportamiento, y cada uno de los siguientes elementos constituye una pista, más que una prueba:

• Inesperado esp4 o esp6 El módulo se carga en los servidores que no ejecutan IPsec.
• Creación de un espacio de nombres de usuario sin privilegios, seguida poco después de la instalación de XFRM SA o de la inserción de una regla de netfilter en el TEE.
• Insólito nft, iptables, XFRM o actividad TEE procedente de contextos de usuario locales.
• Ejecución de un binario con setuid, como por ejemplo su o sudo inmediatamente después de esa configuración de red, por parte de un usuario que tampoco tenía motivo alguno para intervenir en ninguna de las dos.
• Una ausencia repentina de los eventos de auditoría de seguridad esperados en un servidor que debería generarlos.

Si durante ese periodo se ejecutó código local no fiable o semiconfiable en un host EL9 o EL10 expuesto, hay que dar prioridad a la aplicación de parches y considerar que dicho host requiere un análisis más detallado, en lugar de interpretar la ausencia de pruebas en el disco como ausencia de compromiso.

Por qué es importante este tema

DirtyClone no supone una ejecución remota de código, y tampoco significa que un usuario de Internet sin autenticar pueda obtener privilegios de root en cualquier servidor Linux. Sin embargo, en los entornos en los que este fallo realmente se produce, esa distinción es un consuelo insignificante. Los ejecutores de CI ejecutan código de terceros. Las plataformas de alojamiento compartido ejecutan el código de los clientes. Los nodos de Kubernetes ejecutan contenedores con distintos niveles de confianza. Los entornos de pruebas para desarrolladores y los servidores de compilación suelen permitir precisamente el comportamiento de los espacios de nombres que hace que esta clase sea accesible. En cada uno de estos casos, la escalada de privilegios locales es el evento que traspasa los límites. Convierte el código que se ejecutaba donde estaba permitido en código que adquiere privilegios de root donde nunca debería haberlo hecho.

La razón por la que DirtyClone tiene una urgencia menor de lo que sugieren los titulares es también la razón por la que es fácil equivocarse. Un núcleo que contenga la cadena completa de DirtyFrag y Fragnesia está protegido. Pero «completa» es la palabra clave. Un núcleo que haya aplicado el parche original de DirtyFrag y luego se haya quedado estancado sigue teniendo una ruta accesible, al igual que cualquier host que se haya quedado rezagado en las actualizaciones retroactivas de la distribución. El riesgo se concentra en los equipos que se saltaron la última ventana de mantenimiento, en los ejecutores de CI de larga duración que nadie reinicia y en los servidores reservados para el próximo trimestre. Esos son precisamente los hosts en los que un «N-day» como este se convierte silenciosamente en un problema del mismo día. Un flujo de trabajo basado únicamente en un escáner que se centre en la línea de kernels afectados sin comprobar la cadena completa de correcciones puede dar falsas alarmas en los hosts parcheados o pasar por alto aquellos que siguen expuestos.

Lista de verificación de medidas correctoras priorizadas

1. Aplica primero el parche o un parche que no requiera reinicio a los sistemas EL9 y EL10 que tengan las actualizaciones del kernel desactualizadas, especialmente los servidores de contenedores, los ejecutores de CI, los sistemas compartidos y los entornos multitenant.
2. Comprueba que el núcleo en ejecución incorpore la cadena completa de correcciones para DirtyFrag, Fragnesia y DirtyClone, en lugar de dar por sentada la seguridad basándote en el fracaso de un intento de explotación.
3. Considera que una corrección parcial de DirtyFrag sigue siendo vulnerable. Solo la cadena completa cierra la vía de acceso.
4. Al comprobar la cobertura del parche «rebootless-patch», es posible que la protección aparezca bajo el CVE-2026-46300 en algunas herramientas hasta que se propague la asignación al CVE-2026-43503.
5. CloudLinux CL8 y CL9 pueden presentar retrasos en las fuentes EL de esta familia, así que comprueba cuál es tu versión exacta.
6. Desactiva los espacios de nombres de usuario sin privilegios siempre que la carga de trabajo lo permita.
7. Bloque esp4 y esp6 carga automática cuando no se utiliza IPsec, y rxrpc también si estás aplicando medidas de seguridad frente a la familia ampliada y no utilizas AFS ni RxRPC.
8. Búsqueda de espacios de nombres inusuales: XFRM, ESP, TEE, nft, su, y sudo la actividad durante el periodo de exposición, y considerar que los hash de archivos limpios no constituyen pruebas suficientes.

Aplica parches a cualquier kernel sin necesidad de reiniciar. Si aún no eres usuario de KernelCare, ahora es un buen momento para descubrir cómo la aplicación de parches sin reinicio protege los sistemas Linux críticos sin necesidad de ventanas de mantenimiento de emergencia ni tiempos de inactividad.

Consigue KernelCare hoy mismo →

Referencias

• Red Hat CVE-2026-43503, Importante, CVSS 7.0, Afecta a RHEL 9 y 10, no afecta a RHEL 6/7/8; Bugzilla 2480902
• Datos de seguridad de Red Hat en formato JSON, CVE-2026-43503
• NVD CVE-2026-43503 (puntuación CNA de kernel.org: 8,8; cambio en el alcance)
• Sistema de seguimiento de seguridad de Debian, CVE-2026-43503
• Incidente relacionado: CVE-2026-46300 (Bugzilla 2477015), el mismo fallo de origen a través de skb_try_coalesce, comparte la solución
• Investigación de seguridad de JFrog: «Análisis y explotación de una variante de LPE en Linux: DirtyClone (CVE-2026-43503)»
• SecurityWeek: la vulnerabilidad «DirtyClone» del núcleo de Linux permite obtener acceso de root
• The Hacker News: Una nueva vulnerabilidad en el núcleo de Linux denominada «DirtyClone» permite a los usuarios locales obtener privilegios de root mediante paquetes clonados
• Demostración pública de concepto, rafaeldtinoco/security/exploits/dirtyclone (JFrog; primitiva ESP «DirtyFrag» de Hyunwoo Kim)
• Corrección en la rama principal de Linux v7.1-rc5