Dirty Frag en Linux: guía técnica sobre page cache, skb y escalada local

mayo 7, 2026

Diagrama editorial de Dirty Frag con fragmentos skb, page cache, rutas de cifrado y límites de copia

Dirty Frag es una vulnerabilidad de escalada local de privilegios en Linux divulgada el 7 de mayo de 2026. Su interés técnico no está solo en el resultado, sino en la clase de fallo: páginas del page cache pueden terminar expuestas a rutas de red y cifrado que operan sobre fragmentos no lineales, y una escritura in-place donde debía existir una copia puede modificar memoria respaldada por archivos. En términos prácticos, el atacante busca que el kernel trate una página compartida como buffer mutable.

Este artículo está escrito para personas que administran kernels, revisan seguridad de infraestructura, mantienen plataformas multi-tenant o trabajan con rutas de datos de Linux. No reproduce payloads ni pasos de explotación. Sí resume el modelo mental necesario para evaluar riesgo, instrumentar inventario y conversar con proveedores: page cache, splice, sendfile, skb fragments, rutas ESP4/ESP6, RxRPC, copy-on-write y backports.

Modelo de amenaza

Dirty Frag requiere ejecución local. Eso no lo convierte en bajo impacto. En cadenas reales, la ejecución local limitada aparece después de una vulnerabilidad web, credenciales robadas, ejecución de jobs CI, workloads de clientes, notebooks compartidos, contenedores o extensiones de plataformas. Si el kernel del host permite convertir esa ejecución en root, el límite de seguridad entre usuario, contenedor y host se debilita drásticamente.

La prioridad sube cuando el atacante puede elegir archivos fuente para page cache y rutas de red/cifrado que procesen páginas referenciadas. También sube cuando el host ejecuta cargas no confiables o parcialmente confiables. El caso menos urgente es una estación de trabajo monousuario sin exposición a código externo, aunque incluso ahí malware local podría beneficiarse.

Page cache como superficie de seguridad

El page cache no es solo una optimización de performance; es parte de la semántica efectiva de acceso a archivos. Cuando un archivo se lee, sus páginas pueden vivir en memoria y ser compartidas por múltiples consumidores. El kernel debe preservar invariantes: un proceso sin permisos de escritura no debe poder modificar contenido visible de un archivo protegido mediante una ruta alternativa.

Dirty Pipe mostró una versión muy conocida de esta clase: una ruta de pipes permitía escribir sobre page cache en condiciones indebidas. Dirty Frag comparte el principio de riesgo, aunque no necesariamente la misma causa exacta. La lección defensiva es que las rutas zero-copy y no-copy son superficies críticas. Cuando una optimización evita copiar, debe existir certeza fuerte de que el buffer es mutable, privado y apropiado para escritura.

Fragmentos no lineales y `skb`

En la pila de red de Linux, un paquete no siempre es un bloque contiguo. sk_buff puede contener una zona lineal y referencias a fragmentos. Esos fragmentos pueden apuntar a páginas, y esas páginas pueden tener origen en operaciones de archivo o mecanismos zero-copy. Esto es eficiente: evita copias costosas al mover datos entre disco, memoria y red.

La eficiencia introduce una obligación: las capas posteriores no pueden asumir que todo fragmento es un scratch buffer propio. Si una transformación criptográfica, una rutina de autenticación o una operación de encapsulación escribe sobre el fragmento, debe garantizar que esa memoria puede modificarse. Si no, debe copiar antes.

El write-up de Dirty Frag explica que rutas como ESP4/ESP6 y RxRPC pueden alcanzar condiciones donde datos no lineales son procesados in-place. En una lectura defensiva, el punto no es memorizar una función única, sino auditar patrones: ¿la ruta puede recibir fragmentos respaldados por page cache?, ¿hay escritura directa sobre páginas compartidas?, ¿se llama a helpers que materializan una copia privada?, ¿existen diferencias por versión de kernel, configuración o backport?

`splice`, `sendfile` y el atractivo de zero-copy

splice y sendfile existen para mover datos eficientemente entre descriptores, pipes, archivos y sockets. Son piezas importantes para servidores de alto rendimiento, proxies, almacenamiento y software que evita copias usuario-kernel innecesarias. También son históricamente interesantes para seguridad porque crean trayectorias donde buffers del kernel atraviesan subsistemas distintos.

Dirty Frag aprovecha esa filosofía de movimiento eficiente. Cuando contenido de un archivo entra en una ruta de red sin convertirse en una copia privada, cualquier subsistema posterior que modifique en sitio puede romper el aislamiento. El bug no es que zero-copy exista; zero-copy es una herramienta legítima. El bug aparece cuando la propiedad y mutabilidad de la memoria no quedan correctamente respetadas.

Esta distinción importa para equipos técnicos. La mitigación no es “desactivar todo zero-copy” como reflejo. La mitigación es aplicar parches que restauren límites de copia donde corresponde, evaluar rutas expuestas en tu configuración y reducir ejecución local no confiable hasta que el kernel esté corregido.

ESP, IPsec y RxRPC

ESP es parte de IPsec y se usa para proteger paquetes mediante cifrado y autenticación. RxRPC es un protocolo usado por subsistemas como AFS. El material de Dirty Frag identifica ambas familias de rutas como relevantes, con estado de corrección diferente al momento de la publicación. La ruta ESP aparece vinculada a un parche upstream aceptado en netdev; para RxRPC, el write-up discute una corrección propuesta o pendiente según el momento de lectura.

Esto tiene una consecuencia operativa: la versión exacta importa. Dos sistemas pueden decir “Linux 6.x” y no estar en el mismo estado si uno tiene backport de la distribución y otro usa kernel vanilla, si uno integra parches de proveedor cloud y otro no, o si uno corre una rama LTS con fixes seleccionados. Para vulnerabilidades de kernel, uname -a rara vez basta como evidencia completa. Hay que cruzar versión, changelog del paquete, advisory de distribución y configuración.

Indicadores de exposición

No hay un único indicador simple que responda “vulnerable o no” para todos los despliegues. Una evaluación útil combina varios datos: versión y proveedor del kernel, parches aplicados, configuración de red, uso de IPsec o RxRPC, presencia de usuarios no confiables, uso de CI/CD que ejecuta contribuciones externas, nodos Kubernetes multi-tenant y políticas de aislamiento.

También hay que considerar qué significa explotación exitosa. Si el abuso modifica page cache de un binario setuid, biblioteca cargada o archivo consumido por un proceso privilegiado, el resultado puede ser ejecución con más permisos. Pero las rutas concretas cambian por hardening, montajes, LSM, namespaces, opciones de distribución y disponibilidad de objetivos. No conviene convertir una prueba de concepto pública en una conclusión universal.

Mitigación y hardening

La mitigación principal es actualizar el kernel desde fuentes oficiales. En empresas, eso significa revisar advisories de distribución y proveedor cloud, no solo el repo upstream. Si administras appliances o kernels administrados, pide confirmación explícita de backport. Si mantienes imágenes AMI, plantillas de nodos o golden images, programa rebuilds y rotación de nodos.

Mientras tanto, reduce superficie local. Aísla runners que ejecutan código de terceros. Usa máquinas efímeras para CI no confiable. Evita mezclar cargas de distinta confianza en el mismo kernel. Revisa privilegios de contenedores, uso de hostPath, capacidades Linux, seccomp, AppArmor/SELinux y acceso a dispositivos. Estas medidas no sustituyen el parche, pero reducen la probabilidad de que una escalada local sea alcanzable.

En producción, define una ventana de actualización basada en criticidad. Un nodo Kubernetes que ejecuta workloads de muchos equipos o clientes merece prioridad alta. Un bastion con usuarios SSH también. Una VM aislada con una aplicación interna y sin usuarios no confiables puede esperar una ventana normal si el riesgo de acceso local es bajo. Esa priorización debe documentarse.

Qué revisar en CI/CD

CI/CD es uno de los lugares donde las escaladas locales se vuelven más peligrosas. Un runner puede ejecutar código de forks, dependencias, scripts de build, pruebas nativas y herramientas de terceros. Si se reutiliza entre proyectos o no se reprovisiona, una escalada local puede robar tokens, modificar caches, alterar artefactos o persistir entre jobs.

Para Dirty Frag, la recomendación es clasificar runners por confianza. Jobs de repos internos confiables pueden compartir pools con menos riesgo que pull requests externos. Runners que procesan código externo deberían ser efímeros, con secretos mínimos, red restringida y kernel actualizado. Después de aplicar parches, igual conviene mantener esa arquitectura; Dirty Frag no será la última vulnerabilidad local de kernel.

Observabilidad

Detectar explotación de page cache no es trivial. Un hash del archivo en disco puede seguir igual si la modificación vive en memoria. En vez de depender de una señal única, observa comportamiento: ejecución anómala de binarios privilegiados, cambios inesperados en procesos root, lectura de secretos, creación de usuarios, modificaciones de configuraciones, conexiones salientes y uso irregular de subsistemas de red.

Si tienes EDR o eBPF telemetry, usa reglas de alto nivel y revisa eventos alrededor de usuarios no confiables. Evita basar la detección en firmas copiadas de PoC públicas; tienden a envejecer mal. Para incident response, la pregunta clave es si hubo ejecución local no confiable en hosts vulnerables antes del parche. Si la respuesta es sí, considera rotación de secretos y reprovisionamiento cuando el host protegía credenciales sensibles.

Preguntas para proveedores y equipos de plataforma

En organizaciones grandes, el equipo que consume Linux no siempre es el mismo que administra el kernel. Por eso conviene transformar Dirty Frag en preguntas verificables. Para un proveedor cloud: ¿qué kernels estuvieron expuestos?, ¿qué regiones o familias de instancia recibieron corrección?, ¿el parche quedó cargado después de reiniciar o reemplazar nodos?, ¿qué evidencia se puede entregar a clientes regulados? Para una plataforma Kubernetes interna: ¿qué node pools ejecutaban workloads no confiables?, ¿qué nodos se drenaron?, ¿qué workloads privilegiados existían durante la ventana vulnerable?, ¿qué secretos estaban montados en esos pods?

Para un proveedor de CI/CD: ¿los runners son efímeros o se reutilizan?, ¿los jobs de forks reciben tokens?, ¿se mezclan proyectos de distinta sensibilidad?, ¿hay aislamiento por organización o repositorio?, ¿se destruye la VM completa después de ejecutar código externo? Estas preguntas no dependen de conocer cada detalle de skb; dependen de entender que una vulnerabilidad local de kernel convierte la arquitectura de aislamiento en el control principal hasta que el parche está desplegado.

Conclusión

Dirty Frag es relevante porque muestra otra vez que la frontera entre performance y seguridad en el kernel es delicada. skb fragments, page cache y rutas de cifrado son componentes legítimos; el fallo aparece cuando una ruta escribe sobre memoria que debía tratarse como compartida o inmutable. Para defensores, la respuesta no es pánico técnico, sino control de versiones, backports, reducción de ejecución local no confiable y parcheo ordenado.

Si operas Linux en entornos multi-tenant, CI/CD o contenedores, trata Dirty Frag como prioridad. Si mantienes software que usa intensivamente zero-copy, usa el caso como recordatorio para revisar propiedad de buffers y límites de mutabilidad. Si dependes de proveedores, pide evidencia de parche y no te quedes solo con nombres de versiones.

FAQ

¿Dirty Frag es igual a Dirty Pipe?

No. Comparte el riesgo conceptual de page cache modificable en condiciones indebidas, pero los detalles técnicos y rutas del kernel son distintos.

¿La explotación requiere root?

No; el punto de una escalada local es partir desde un usuario sin privilegios y alcanzar permisos superiores. Sí requiere ejecución local previa.

¿Debo desactivar IPsec?

No como regla general. La mitigación correcta es aplicar parches y evaluar exposición. Cambios de red defensivos deben hacerse según tu configuración y riesgo.

¿Cómo sé si mi distribución está corregida?

Consulta el advisory de tu distribución o proveedor cloud, revisa el changelog del paquete de kernel y valida que los nodos hayan reiniciado con el kernel corregido.

¿Por qué los contenedores importan?

Porque comparten el kernel del host. Una vulnerabilidad local del kernel se corrige en el host o nodo, no solo dentro de la imagen del contenedor.