La falla de RefluXFS Linux de nueve años de antigüedad brinda a los usuarios locales acceso root en las instalaciones predeterminadas de RHEL
RefluXFSun nuevo Fallo del kernel de Linux divulgado el 22 de julio y rastreado como CVE-2026-64600permite a un usuario local sin privilegios sobrescribir archivos propiedad de root en un sistema de archivos XFS y obtener acceso de root persistente.
Qualys dijo que las instalaciones predeterminadas de Red Hat Enterprise Linux y sus derivados, Fedora Server y Amazon Linux pueden cumplir las condiciones de explotación.
La empresa demostró la carrera contra /etc/passwd y binarios de raíz setuid. La sobrescritura llega a la capa del bloque. Sobrevive a un reinicio y deja intactos la propiedad, los permisos, las marcas de tiempo y el bit setuid del objetivo, por lo que un binario setuid-root modificado aún se ejecuta como root.
La solución se fusionó el 16 de julio y los proveedores de Linux comenzaron a enviar kernels respaldados. El parche rastrea el error hasta Linux 4.11 en 2017: a Fixes: compromiso de nomenclatura de etiquetas 3c68d44a2b49 y una solicitud de backport estable marcada # v4.11.
quien esta expuesto
La explotación requiere tres condiciones:
- El sistema ejecuta Linux 4.11 o posterior sin la solución RefluXFS.
- El sistema de archivos XFS fue creado con
reflink=1. - El objetivo legible y un directorio en el que el atacante puede escribir están en el mismo sistema de archivos XFS.
qualys dicho parchear primero los sistemas expuestos y multiinquilino, lo que significa cualquier host XFS habilitado para reflink donde el código que no es de confianza pueda ejecutarse localmente, ya sea a través de un shell, un trabajo de CI o un servicio comprometido.
El aviso enumera las instalaciones predeterminadas que pueden cumplir esas condiciones: Red Hat Enterprise Linux, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux y CloudLinux 8, 9 y 10, Fedora Server 31 y posteriores, Amazon Linux 2023 e imágenes de Amazon Linux 2 desde diciembre de 2022 en adelante. Los sistemas de archivos RHEL 7 no se ven afectados porque son anteriores al soporte de reflink XFS.
Debian, Ubuntu, SLES y openSUSE generalmente no usan XFS para el sistema de archivos raíz de forma predeterminada. Están expuestos sólo si un administrador elige XFS con reflink habilitado en el momento de la instalación.
Verifique el sistema de archivos raíz:
xfs_info / | grep reflink=
reflink=1 significa que se cumple la condición dos. Ejecute la misma comprobación en cualquier otro volumen XFS montado donde un archivo protegido y un directorio grabable por el atacante compartan el sistema de archivos.
El mapeo obsoleto
Un atacante clona un archivo de propiedad raíz en un archivo borrador con FICLONEque solo necesita acceso de lectura en la fuente, luego corre simultáneamente O_DIRECT escribe contra el clon. Los enlaces de referencia XFS utilizan copia en escritura, por lo que ambos archivos inicialmente hacen referencia a los mismos bloques de disco físico.
El kernel lee el mapeo de bifurcación de datos bajo el bloqueo de inodo y se lo entrega a xfs_reflink_fill_cow_hole()que realiza un ciclo de ese bloqueo para reservar espacio de transacción.
Un segundo escritor puede completar la operación de copia en escritura durante ese intervalo y reasignar el archivo clonado a un nuevo bloque. Cuando el primer escritor vuelve a adquirir el bloqueo, actualiza la bifurcación de copia en escritura pero continúa usando la antigua asignación de bifurcación de datos.
El parche ascendente describe la falla claramente: «las asignaciones quedan obsoletas tan pronto como volvemos a adquirir ILOCK».
Esa dirección obsoleta ahora apunta a un bloque que pertenece únicamente al archivo protegido original. XFS ve el bloque como no compartido y permite la escritura directa, por lo que los datos destinados al clon del atacante llegan al objetivo.
Es un error de verificación y uso durante un ciclo de bloqueo. La consulta de estado compartido en sí es correcta; lo que consulta es una dirección de bloque capturada antes de que se liberara el bloqueo.
The Hacker News descubrió que el parche afecta a dos ayudantes, xfs_reflink_fill_cow_hole() y xfs_reflink_fill_delalloc(). El segundo tiene el mismo patrón de ciclo de bloqueo y no aparece en el aviso de Qualys. En ambos, las instantáneas de corrección. ip->i_df.if_seq antes de que se caiga el bloqueo y vuelve a leer la bifurcación de datos con xfs_bmapi_read() si el contador se movía.
La E/S directa omite el caché de la página y no tiene enlace de revalidación, por lo que la escritura llega al disco. Debido a que omite por completo el inodo objetivo, los metadatos nunca cambian y los investigadores dijeron que sus pruebas no produjeron ninguna advertencia del núcleo ni entrada de registro.
En la máquina de pruebas, la carrera se ganaba normalmente en menos de diez segundos. La demostración publicada elimina la contraseña de root en un cuadro RHEL 10.2 predeterminado.
Qualys dijo que un modelo de IA encontró la falla. La compañía señaló Claude Mythos Preview, el modelo de frontera de acceso restringido de Anthropic, al núcleo y, según su asesoramiento técnico«le pidió que encontrara una vulnerabilidad similar a Dirty COW».
El modelo localizó la carrera, escribió un exploit de raíz funcional y redactó el aviso. Luego, los investigadores lo reprodujeron en una instalación estándar de Fedora Server 44, verificaron el razonamiento del modelo y coordinaron la divulgación en sentido ascendente.
No es el primer error de kernel antiguo que sufre el equipo este año. Qualys ha estado encontrando muchos de estos. Un día antes, reveló una falla de confinamiento instantáneo en Ubuntu Desktop, CVE-2026-8933donde dos razas permiten que un usuario local obtenga root en instalaciones predeterminadas. En mayo encontró un error de nueve años de antigüedad en las comprobaciones de seguimiento del núcleo.
Parchear, luego reiniciar
sombrero rojo ha emitido avisos de kernel con clasificación importante en las transmisiones RHEL 8, 9 y 10 afectadas. La errata comenzó a llegar el 14 de julio, ocho días antes de la divulgación coordinada: RHSA-2026:39179 y RHSA-2026:39180 para RHEL 8 y RHSA-2026:39494 para RHEL 10, con soporte extendido y flujos de SAP hasta el 17 de julio.
La cobertura es específica de cada transmisión, así que confirme que exista un aviso para su versión exacta. Cualquiera que aplicara esas erratas a tiempo estaba cubierto antes de que RefluXFS tuviera un nombre. Verifique las fechas de sus parches antes de asumir la exposición.
el vendedor rastreador de errores presenta la falla bajo el título «kernel: corrupción de datos XFS usando reflink». La entrada se importó automáticamente el 10 de julio e inicialmente describía el problema como una posible corrupción de datos al volver a vincular un archivo.
A partir del 23 de julio, rastreador de Debian enumeró la solución en trixie-security como kernel 6.12.96-1 y en inestable como 7.1.4-1. El núcleo base de Trixie 6.12.94-1 y forky 7.1.3-1 todavía estaban marcados como vulnerables, al igual que los ratones de biblioteca y los diana, incluidas sus ramas de seguridad.
No existe una opción de montaje o sysctl que deshabilite los enlaces de referencia XFS después de que se haya creado un sistema de archivos, y Qualys dijo que no hay ninguna mitigación práctica o cambio de configuración temporal disponible. SELinux en modo Enforcing, seccomp, bloqueo del kernel y límites de contenedores no lograron detenerlo en las pruebas de la compañía. Las protecciones de memoria como KASLR y SMEP nunca se aplicaron: se trata de una escritura en la capa de bloque, no de una corrupción de la memoria.
Un límite aparente no lo es. La carrera solo se activa si el bloque del objetivo comienza sin compartir, por lo que no se puede acceder a un archivo que un administrador ya haya copiado mediante reflink. El aviso dice que un usuario sin privilegios puede restablecer esa condición ejecutando chshy que es poco probable que los binarios setuid-root hayan sido vinculados nuevamente en primer lugar.
Qualys no publicó ningún código de explotación independiente. El rastreador de Red Hat registró una prueba de concepto pública el 22 de julio, señalando el aviso publicado en la lista de seguridad de oss, que establece la carrera y los pasos de explotación en su totalidad. Ninguno de los proveedores que rastrearon la falla había informado de explotación en estado salvaje al momento de escribir este artículo.
The Hacker News se comunicó con Red Hat para comentar sobre su evaluación del impacto de la falla y con Qualys para obtener más detalles sobre el hallazgo, y actualizará esta historia con cualquier respuesta.
La instalación del paquete no reemplaza el kernel que ya se está ejecutando en la memoria. Aplique la actualización del proveedor, reinicie el sistema y verifique que esté ejecutando el kernel reparado.
