El 22 de julio se divulgó la vulnerabilidad CVE-2026-64600 (RefluXFS) en el kernel de Linux: una condición de carrera en la subestructura XFS reflink permite a un usuario local sin privilegios sobrescribir archivos propiedad de root y obtener acceso privilegiado persistente. El fallo está presente en kernels a partir de la versión 4.11 (año 2017). Según los investigadores de Qualys, las condiciones de explotación se cumplen en instalaciones estándar de Red Hat Enterprise Linux y distribuciones derivadas, Fedora Server y Amazon Linux. La corrección se integró en la rama principal del kernel el 16 de julio, y los proveedores han empezado a publicar kernels actualizados. Existe un PoC-exploit público, pero en el momento de la divulgación no se había observado explotación en entornos reales. La única medida eficaz es actualizar el kernel y reiniciar posteriormente.
Mecanismo de la vulnerabilidad
La vulnerabilidad pertenece a la clase TOCTOU (time-of-check-to-time-of-use), es decir, un fallo de comprobación-antes-de-uso a través de un ciclo de bloqueo. El atacante clona un archivo propiedad de root a su propio archivo de trabajo mediante la llamada al sistema FICLONE, para la cual basta con contar con permiso de lectura sobre el archivo original. El mecanismo XFS reflink utiliza copia en escritura (copy-on-write): ambos archivos apuntan inicialmente a los mismos bloques físicos de disco.
El kernel lee el mapeo de datos (data-fork mapping) bajo el bloqueo del inodo y lo pasa a la función xfs_reflink_fill_cow_hole(), que libera dicho bloqueo para reservar espacio de transacción. En ese intervalo, un segundo escritor en paralelo puede completar la operación de copy-on-write y reasignar el archivo clonado a un nuevo bloque. Cuando el primer escritor vuelve a adquirir el bloqueo, actualiza el COW-fork, pero continúa utilizando la dirección de bloque obsoleta procedente del data-fork.
Tal como se describe en el parche: «los mapeos quedan obsoletos en cuanto volvemos a adquirir ILOCK». La dirección obsoleta ahora apunta a un bloque que pertenece exclusivamente al archivo original protegido. XFS considera el bloque como no compartido y permite la escritura directa: los datos destinados al clon del atacante terminan en el archivo objetivo de root.
Un aspecto crítico: la escritura mediante Direct I/O elude por completo la caché de páginas y el inodo de destino, por lo que los metadatos del archivo —propietario, permisos, marcas de tiempo, bit setuid— permanecen intactos. Según los investigadores, un binario setuid-root modificado sigue ejecutándose con privilegios de root. Las pruebas no detectaron ni advertencias del kernel ni entradas en los registros. En la máquina de pruebas, la carrera, según se informa, se ganaba en menos de diez segundos.
El parche afecta a dos funciones: xfs_reflink_fill_cow_hole() y xfs_reflink_fill_delalloc(). La corrección conserva el valor del contador ip->i_df.if_seq antes de liberar el bloqueo y vuelve a leer el data-fork mediante xfs_bmapi_read() si el contador ha cambiado.
Quién está en riesgo
La explotación requiere que se cumplan simultáneamente tres condiciones:
- El sistema ejecuta un kernel de Linux 4.11 o posterior sin el parche de RefluXFS.
- El sistema de archivos XFS se creó con el parámetro
reflink=1. - El archivo objetivo (accesible en lectura) y el directorio con permisos de escritura para el atacante residen en el mismo sistema de archivos XFS.
Según Qualys, las instalaciones por defecto de los siguientes sistemas pueden cumplir estas condiciones:
- RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux, CloudLinux versiones 8, 9 y 10
- Fedora Server 31 y posteriores
- Amazon Linux 2023 e imágenes de Amazon Linux 2 a partir de diciembre de 2022
RHEL 7 no se ve afectado: sus sistemas de archivos son anteriores a la compatibilidad con XFS reflink. Las distribuciones Debian, Ubuntu, SLES y openSUSE no utilizan XFS por defecto para el sistema de archivos raíz y solo están expuestas si se elige explícitamente XFS con reflink habilitado durante la instalación.
Para comprobarlo, ejecute:
xfs_info / | grep reflink=
Un resultado reflink=1 significa que se cumple la segunda condición de explotación. Debe realizarse la misma comprobación para todos los volúmenes XFS montados donde puedan coexistir archivos protegidos y directorios con permisos de escritura.
Ausencia de soluciones alternativas
Qualys indica que no existen medidas temporales prácticas. No hay ninguna opción de montaje ni parámetro sysctl que desactive reflink en un sistema de archivos ya creado. Durante las pruebas de los investigadores, SELinux en modo Enforcing, seccomp, kernel lockdown y los límites de aislamiento de contenedores no impidieron la explotación. Los mecanismos de protección de memoria (KASLR, SMEP) no son aplicables: se trata de una escritura a nivel de dispositivo de bloques, no de una corrupción de memoria.
La única limitación es que la carrera solo se desencadena si el bloque de destino del archivo no es compartido (unshared). Sin embargo, como se indica en el advisory, un usuario sin privilegios puede forzar que esta condición deje de cumplirse, por ejemplo ejecutando chsh, y en las configuraciones típicas los binarios setuid-root ya de por sí no son copias reflink.
Papel de la IA en el descubrimiento
Qualys afirma que la vulnerabilidad fue descubierta con ayuda de un modelo de IA —Claude Mythos Preview de Anthropic— al que se le pidió encontrar una vulnerabilidad similar a Dirty COW. Según la compañía, el modelo localizó la carrera, escribió un exploit funcional para obtener root y preparó un borrador del advisory. Los investigadores reprodujeron posteriormente el fallo en una instalación estándar de Fedora Server 44, verificaron la lógica del modelo y coordinaron la divulgación con los desarrolladores del kernel. Esta afirmación procede exclusivamente de Qualys y no ha sido verificada de forma independiente.
Estado de los parches
Red Hat ha publicado recomendaciones con nivel de importancia Important para las ramas afectadas de RHEL 8, 9 y 10. Las erratas comenzaron a publicarse el 14 de julio —ocho días antes de la divulgación coordinada—: RHSA-2026:39179 y RHSA-2026:39180 para RHEL 8, RHSA-2026:39494 para RHEL 10, con actualizaciones adicionales para las ramas de soporte extendido y SAP hasta el 17 de julio. La cobertura depende de la rama concreta: es necesario verificar la existencia de la errata para su versión exacta.
La entrada en el bug tracker de Red Hat se importó automáticamente el 10 de julio bajo el título «kernel: XFS data corruption using reflink» y describía inicialmente el problema como una posible corrupción de datos. El PoC público se registró en el tracker el 22 de julio.
Según el tracker de Debian a fecha de 23 de julio, la corrección está disponible en trixie-security (kernel 6.12.96-1) y en unstable (7.1.4-1). El kernel base de trixie (6.12.94-1), forky (7.1.3-1), así como bookworm y bullseye, incluidas sus ramas de seguridad, siguen marcados como vulnerables.
Recomendaciones
- Priorice los sistemas multiusuario y los hosts donde pueda ejecutarse código no confiable de forma local (CI/CD, servidores compartidos, servicios comprometidos).
- Instale un kernel actualizado proporcionado por su proveedor. Las organizaciones que aplicaron las erratas de Red Hat antes del 22 de julio ya están protegidas.
- Reinicie el sistema tras instalar el paquete: la actualización no sustituye el kernel que ya está cargado en memoria.
- Verifique que el sistema ha arrancado con el kernel corregido:
uname -r. - Compruebe todos los volúmenes XFS en busca de
reflink=1, no solo el sistema de archivos raíz.
RefluXFS es una vulnerabilidad sin soluciones alternativas: ni SELinux, ni la contenedorización, ni seccomp bloquean su explotación. Con un PoC público disponible y una descripción detallada de los pasos de ataque en la lista de correo oss-security, la ventana para permanecer inactivo con seguridad es mínima. La única acción fiable es instalar un kernel actualizado y reiniciar cada host con XFS reflink, verificando con uname -r que el sistema se ejecuta sobre una versión corregida.
