RefluXFS, nuevo Fallo del kernel de Linux La vulnerabilidad, revelada el 22 de julio y rastreada como CVE-2026-64600, permite a usuarios locales sin privilegios sobrescribir archivos de propiedad raíz en sistemas de archivos XFS y obtener acceso raíz persistente.
Qualys declaró que las instalaciones predeterminadas de Red Hat Enterprise Linux y sus derivados, Fedora Server y Amazon Linux podrían calificar para explotación.
La empresa demostró conflictos con los binarios /etc/passwd y setuid-root. Las anulaciones llegan a la capa de bloque. Sobrevive a los reinicios y la propiedad, los permisos, la marca de tiempo y los bits setuid del objetivo no cambian, por lo que un binario setuid-root modificado continuará ejecutándose como root.
Esta solución se fusionó el 16 de julio y los proveedores de Linux comenzaron a enviar kernels respaldados. Este parche rastrea errores hasta Linux 4.11 en 2017. Corregido: etiqueta denominada commit 3c68d44a2b49 y solicitud de backport estable marcada como # v4.11.
¿Quién quedará 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 se creó con reflink=1. El destino legible y el directorio grabable por el atacante están en el mismo sistema de archivos XFS.
Qualys dice que primero parcheará los sistemas multiinquilino disponibles públicamente. Esto significa un host XFS habilitado para reflink donde se puede ejecutar código que no es de confianza localmente a través de un shell, un trabajo de CI o un servicio comprometido.
Este aviso enumera las instalaciones predeterminadas que pueden cumplir con estas condiciones: Red Hat Enterprise Linux, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux y CloudLinux 8, 9, 10, Fedora Server 31 o posterior, Amazon Linux 2023 y Amazon Linux 2 imágenes de diciembre de 2022. Los sistemas de archivos RHEL 7 son anteriores al soporte de reflink de XFS y no se ven afectados.
Debian, Ubuntu, SLES y openSUSE normalmente no utilizan XFS para sus sistemas de archivos raíz de forma predeterminada. Estos solo están expuestos si el administrador habilita los enlaces de referencia y selecciona XFS durante la instalación.
Verifique el sistema de archivos raíz.
xfs_info / | enlace de referencia grep =
reflink=1 significa que se cumple la condición 2. Realice la misma comprobación en otros volúmenes XFS montados que comparten un sistema de archivos con archivos protegidos y directorios en los que el atacante puede escribir.
mapeo antiguo
Un atacante clona un archivo de propiedad raíz en un archivo temporal usando FICLONE, que solo requiere acceso de lectura al código fuente, y compite por escrituras O_DIRECT simultáneas en 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 un bloqueo de inodo, lo pasa a xfs_reflink_fill_cow_hole() y gira el bloqueo para reservar espacio de transacción.
El segundo escritor puede completar la operación de copia en escritura durante ese intervalo y reasignar el archivo clonado a nuevos bloques. Cuando el primer escritor vuelve a adquirir el bloqueo, la bifurcación de copia en escritura se actualiza, pero se sigue utilizando la antigua asignación de bifurcación de datos.
El parche ascendente describe claramente el defecto: «Las asignaciones quedan obsoletas tan pronto como se vuelve a adquirir ILOCK».
Esa antigua dirección ahora apunta a un bloque que pertenece únicamente al archivo protegido original. XFS supone que el bloque no se comparte y permite escrituras directas, por lo que los datos destinados al clon del atacante llegan al objetivo.
Este es un error que debe verificarse y usarse durante los ciclos de bloqueo. La consulta de estado compartido en sí es correcta. Lo que está consultando es la dirección del bloque que se capturó antes de que se liberara el bloqueo.
Hacker News descubrió que este 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, pero no se menciona en el aviso de Qualys. En ambos casos, la solución crea una instantánea de ip->i_df.if_seq antes de eliminar el bloqueo y vuelve a leer la bifurcación de datos con xfs_bmapi_read() si el contador se mueve.
La E/S directa omite el caché de la página y no hay un enlace de revalidación, por lo que la escritura llega al disco. Debido a que omite completamente el inodo de destino, los metadatos nunca se modifican y los investigadores dicen que sus pruebas no generaron ninguna advertencia del kernel ni entradas de registro.
En nuestras máquinas de prueba, las carreras normalmente se ganaban en 10 segundos. La demostración publicada elimina la contraseña raíz predeterminada del cuadro RHEL 10.2.
Qualis dijo que el modelo de IA descubrió la falla. La compañía señaló a Kernel Claude Mythos Preview, el modelo de frontera de restricción de acceso de Anthropic, y «le pidió que encontrara vulnerabilidades similares a Dirty COW» luego de un aviso técnico.
El modelo identificó conflictos, creó un exploit de raíz funcional y redactó recomendaciones. Luego, los investigadores lo reprodujeron en una instalación estándar de Fedora Server 44 para confirmar las inferencias del modelo y ajustar las revelaciones anteriores.
Este no es el primer error de kernel antiguo que sufre el equipo este año. Qualys ha descubierto muchos de estos. El día anterior, la compañía reveló CVE-2026-8933, una falla de restricción instantánea en Ubuntu Desktop. Esta falla permite dos carreras para permitir a los usuarios locales obtener privilegios de root en una instalación predeterminada. En mayo, se descubrió un error de nueve años en la verificación de ptrace del kernel.
Aplicar el parche y reiniciar
Red Hat ha emitido un aviso de kernel clasificado como Importante para todas las corrientes de RHEL 8, 9 y 10 afectadas. Las erratas comenzaron a distribuirse 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 transmisiones de SAP hasta el 17 de julio.
La cobertura es específica de cada transmisión, así que asegúrese de que exista el aviso para su versión exacta. Cualquiera que aplicara estas erratas a tiempo antes de que se nombrara a RefluXFS fue el objetivo. Verifique la fecha del parche antes de asumir que está en riesgo.
El rastreador de errores del proveedor informa esta falla bajo el título «Kernel: corrupción de datos XFS usando reflink». Esta entrada se importó automáticamente el 10 de julio y originalmente describía el problema como una posible corrupción de datos debido a la vinculación de archivos.
A partir del 23 de julio, el rastreador de Debian tiene la solución listada como kernel 6.12.96-1 en trixie-security y como 7.1.4-1 en inestable. El kernel base 6.12.94-1 de Trixie y el 7.1.3-1 de forky todavía estaban marcados como vulnerables, al igual que Bookworm y Bullseye, que incluían la rama de seguridad.
Qualys señala que no existe una opción de montaje o sysctl para deshabilitar los enlaces de referencia XFS después de crear el sistema de archivos, y no hay mitigaciones prácticas ni cambios de configuración temporales disponibles. En las pruebas de la compañía, SELinux en modo de cumplimiento, seccomp, bloqueo del kernel y límites de contenedores no lograron detenerse. No se aplican protecciones de memoria como KASLR y SMEP. Esta es una escritura en la capa de bloque, no una corrupción de la memoria.
No existe una única limitación obvia. La carrera solo ocurre si el bloque de destino comienza sin compartir, por lo que no puede afectar a archivos que el administrador ya haya copiado con un enlace de referencia. El aviso establece que un usuario sin privilegios puede restablecer ese estado ejecutando chsh y que es poco probable que los binarios setuid-root se hayan vuelto a vincular en primer lugar.
Qualys no publica código de explotación independiente. El rastreador de Red Hat registró una prueba pública de concepto el 22 de julio y señaló un aviso publicado en la lista de seguridad de OSS que describe completamente el conflicto y los pasos de explotación. Los proveedores que rastrean esta falla no han informado de ninguna explotación en estado salvaje al momento de escribir este artículo.
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 sus hallazgos y actualizará este artículo si recibimos una respuesta.
La instalación de un paquete no reemplaza el kernel que ya se está ejecutando en la memoria. Aplique la actualización del proveedor y reinicie el sistema para asegurarse de que esté ejecutando el kernel reparado.
Source link
