Vulnerabilidad RefluXFS en Linux otorga acceso root en instalaciones de RHEL

¿Qué es RefluXFS?

RefluXFS, una nueva falla del kernel de Linux revelada el 22 de julio y registrada como CVE-2026-64600, permite a un usuario local sin privilegios sobrescribir archivos propiedad de root en un sistema de archivos XFS y obtener acceso root persistente. Qualys afirmó que las instalaciones predeterminadas de Red Hat Enterprise Linux y sus derivados, Fedora Server y Amazon Linux pueden cumplir las condiciones para la explotación.

La compañía demostró la carrera contra /etc/passwd y binarios setuid-root. La sobrescritura ocurre a nivel de bloque. Sobrevive a un reinicio y no altera la propiedad, permisos, marcas de tiempo ni el bit setuid del objetivo, por lo que un binario setuid-root modificado sigue ejecutándose como root. La corrección se fusionó el 16 de julio y los proveedores de Linux han comenzado a distribuir kernels con el parche retroportado. El parche rastrea el error hasta Linux 4.11 en 2017: una etiqueta Fixes que nombra el commit 3c68d44a2b49 y una solicitud de retroportación estable marcada como # v4.11.

¿Quién está expuesto?

El sistema ejecuta Linux 4.11 o posterior sin la corrección de RefluXFS.
El sistema de archivos XFS fue creado con reflink=1.
El objetivo legible y un directorio escribible por el atacante están en el mismo sistema de archivos XFS.

Qualys recomendó parchear primero los sistemas expuestos y multiinquilino, lo que significa cualquier host XFS con reflink habilitado donde se pueda ejecutar código no confiable 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 a partir de diciembre de 2022. Los sistemas de archivos de RHEL 7 no se ven afectados porque son anteriores al soporte de reflink en XFS. Debian, Ubuntu, SLES y openSUSE no suelen usar XFS para el sistema de archivos raíz de forma predeterminada. Solo están expuestos si un administrador eligió XFS con reflink habilitado durante la instalación. Para verificar el sistema de archivos raíz: ejecute 'xfs_info / | grep reflink='. Si aparece reflink=1, se cumple la segunda condición. Realice la misma verificación en cualquier otro volumen XFS montado donde un archivo protegido y un directorio escribible por el atacante compartan el sistema de archivos.

El mapeo obsoleto

Un atacante clona un archivo propiedad de root en un archivo temporal con FICLONE, que solo necesita acceso de lectura en el origen, luego compite con escrituras O_DIRECT concurrentes contra el clon. Los reflinks de XFS usan copia en escritura, por lo que ambos archivos inicialmente hacen referencia a los mismos bloques físicos del disco. El kernel lee el mapeo del data-fork bajo el bloqueo del inodo y lo pasa a xfs_reflink_fill_cow_hole(), que cicla 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 readquiere el bloqueo, actualiza el fork de copia en escritura pero continúa usando el mapeo anterior del data-fork. El parche ascendente describe la falla claramente: "los mapeos están obsoletos tan pronto como readquirimos el ILOCK". Esa dirección obsoleta ahora apunta a un bloque propiedad solo del 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 terminan en el objetivo en su lugar. Es un error de verificar y luego usar a través de 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 liberar el bloqueo.

The Hacker News encontró que el parche toca dos ayudantes, xfs_reflink_fill_cow_hole() y xfs_reflink_fill_delalloc(). El segundo lleva el mismo patrón de ciclo de bloqueo y no aparece en el aviso de Qualys. En ambos, la corrección captura ip->i_df.if_seq antes de soltar el bloqueo y relee el data-fork con xfs_bmapi_read() si el contador se movió. La E/S directa omite la caché de páginas y no tiene un gancho de revalidación, por lo que la escritura llega al disco. Debido a que evita por completo el inodo objetivo, los metadatos nunca cambian, y los investigadores dijeron que sus pruebas no produjeron ninguna advertencia del kernel o entrada de registro. En la máquina de prueba, la carrera generalmente ganaba en menos de diez segundos. La demostración publicada elimina la contraseña de root en una máquina RHEL 10.2 predeterminada. Qualys dijo que un modelo de IA encontró la falla. La compañía dirigió Claude Mythos Preview, el modelo de acceso restringido de Anthropic, al kernel y, según su aviso técnico, "le pidió que encontrara una vulnerabilidad similar a Dirty COW". El modelo localizó la carrera, escribió un exploit de root 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 con los desarrolladores. No es el primer error antiguo del kernel que encuentra el equipo este año. Qualys ha estado encontrando muchos de estos. Un día antes, reveló una falla de snap-confine en Ubuntu Desktop, CVE-2026-8933, donde dos carreras permiten a un usuario local obtener root en instalaciones predeterminadas. En mayo encontró un error de nueve años en las comprobaciones de ptrace del kernel.

Parche y luego reinicie

Red Hat ha emitido avisos de kernel con calificación Importante en las ramas afectadas de RHEL 8, 9 y 10. Las erratas comenzaron 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 ramas de soporte extendido y SAP a partir del 17 de julio. La cobertura es específica de cada rama, por lo que debe confirmar que existe un aviso para su versión exacta. Quienes aplicaron esas erratas según lo programado estaban protegidos antes de que RefluXFS tuviera un nombre. Verifique las fechas de sus parches antes de asumir exposición. El rastreador de errores del proveedor archiva la falla bajo el título "kernel: corrupción de datos de XFS usando reflink". La entrada se importó automáticamente el 10 de julio y describió inicialmente el problema como posible corrupción de datos al usar reflink en un archivo. Al 23 de julio, el rastreador de Debian listaba la corrección en trixie-security como kernel 6.12.96-1 y en inestable como 7.1.4-1. El kernel base de Trixie 6.12.94-1 y el de forky 7.1.3-1 aún estaban marcados como vulnerables, al igual que bookworm y bullseye, incluidas sus ramas de seguridad.

No hay ninguna opción de montaje o sysctl que deshabilite los reflinks de XFS después de crear un sistema de archivos, y Qualys dijo que no hay mitigación práctica ni cambio de configuración temporal disponible. SELinux en modo Enforcing, seccomp, bloqueo del kernel y contenedores no lograron detenerlo en las pruebas de la compañía. Protecciones de memoria como KASLR y SMEP nunca se aplican: se trata de una escritura a nivel de bloque, no de corrupción de memoria. Un límite aparente no es tal: la carrera solo se activa si el bloque del objetivo comienza como no compartido, por lo que un archivo que un administrador ya copió con reflink no puede ser atacado. El aviso dice que un usuario sin privilegios puede restablecer esa condición ejecutando chsh, y que es poco probable que los binarios setuid-root hayan sido reflinkeados en primer lugar. Qualys no publicó código de exploit independiente. El rastreador de Red Hat registró una prueba de concepto pública el 22 de julio, apuntando al aviso publicado en la lista de correo oss-security, que detalla la carrera y los pasos de explotación completos. Ninguno de los proveedores que rastrean la falla había reportado explotación activa al momento de escribir este artículo. The Hacker News se ha comunicado con Red Hat para obtener comentarios 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. Instalar el paquete no reemplaza el kernel que ya se está ejecutando en memoria. Aplique la actualización del proveedor, reinicie el sistema y verifique que esté ejecutando el kernel corregido.