Une nouvelle faille de RefluXFS sous Linux résiste aux redémarrages et échappe aux journaux

En direct cet après-midi : nous analysons la faille RefluXFS avec un expert en correctifs Linux. Au programme : les dernières mesures prises par les éditeurs et comment corriger la faille sans redémarrer. Regardez-le ici →

En bref

Aller directement à la version longue ↓

Description : RefluXFS, référencé sous le numéro CVE-2026-64600, est une condition de concurrence présente dans le chemin de traitement « copy-on-write » du système de fichiers XFS du noyau Linux. Elle permet à un utilisateur local non privilégié de rediriger une opération d’écriture provenant d’une copie liée par un lien symbolique vers le bloc physique du fichier d’origine. Un attaquant peut ainsi modifier un fichier appartenant à l’utilisateur root qu’il est autorisé à lire, mais sur lequel il ne dispose d’aucun droit d’écriture. Accéder à la version complète →

Impact : élévation des privilèges locaux au niveau root. Qualys a démontré cette vulnérabilité sur le fichier /etc/passwd et les binaires setuid-root d’un système Linux d’entreprise par défaut, supprimant en quelques secondes la protection par mot de passe du compte root sur un système RHEL 10.2 standard. L'écriture s'effectue en dessous du chemin d'écriture normal des inodes ; elle permet ainsi de préserver le propriétaire, les permissions, les horodatages et le bit setuid de la cible, survit à un redémarrage et n'a généré aucune sortie dans les journaux du noyau lors des tests de Qualys. Passer à la version longue →

Gravité : aucun score CVSS public n'avait été confirmé au moment de la rédaction de cet article. Considérez-la néanmoins comme hautement prioritaire : l'exploitation est fiable, ne nécessite qu'un compte local standard, contourne les mesures de sécurisation courantes et permet d'obtenir des privilèges root persistants. Red Hat la classe dans la catégorie « Important ». Accéder à la version longue →

Qui est concerné : les noyaux Linux basés sur la version 4.11 ou ultérieure qui contiennent le code XFS vulnérable et ne disposent pas du correctif, sur un système de fichiers XFS créé avec la prise en charge de reflink, où un fichier protégé en lecture et un répertoire accessible en écriture par un attaquant partagent ce système de fichiers. Cela correspond à la configuration par défaut sur RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux et CloudLinux 8, 9 et 10, ainsi que sur Fedora Server 31 et versions ultérieures, Amazon Linux 2023 et les images Amazon Linux 1.2 à partir de décembre 2022. RHEL 7 est antérieur à la prise en charge de reflink par XFS et n’est donc pas concerné par cette vulnérabilité par défaut. Aller à la version longue →

Statut : Divulgué publiquement par Qualys le 22 juillet 2026 et détecté à l’aide de l’IA dans le cadre du projet Glasswing d’Anthropic. Le correctif en amont a été intégré le 16 juillet, et les éditeurs ont publié des noyaux rétroportés. Certains correctifs destinés aux entreprises ont été diffusés avant la divulgation sous la forme de mises à jour habituelles du noyau ; il est donc possible qu’un hôte dispose déjà de la correction, même si la mise à jour ne mentionnait pas le CVE-2026-64600. Aller à la version longue →

À faire dès maintenant : il n'existe aucune solution de contournement sans risque. Red Hat a publié une mesure d'atténuation temporaire via SystemTap, mais la véritable solution réside dans un noyau corrigé : vérifiez si chaque système de fichiers XFS utilise des liens de référence (reflinks), appliquez le noyau corrigé correspondant exactement à votre version et redémarrez, ou appliquez un correctif KernelCare ne nécessitant pas de redémarrage (ces correctifs sont déployés automatiquement en arrière-plan chez les utilisateurs). Passer à la version longue →

xfs_info / | grep reflink=

Un résultat de `reflink=1` confirme que les conditions préalables relatives au système de fichiers sont remplies. Répétez l'opération pour les autres volumes XFS montés qui contiennent à la fois des fichiers protégés et des répertoires dans lesquels un attaquant peut écrire.

RefluXFS rompt l'une des promesses les plus fondamentales du système de fichiers : le fait d'être autorisé à lire un fichier protégé ne vous permet pas de le réécrire.

L'attaquant n'ouvre jamais le fichier /etc/passwd ni un binaire setuid-root en mode écriture. Linux le refuserait catégoriquement. À la place, il demande à XFS de créer une copie liée par un lien symbolique du fichier à un emplacement qu'il contrôle, puis effectue deux écritures simultanées sur cette copie. En raison d'un mappage de blocs obsolète au sein du noyau, l'une de ces écritures peut se retrouver dans le fichier d'origine protégé au lieu de la copie. L'attaquant écrit dans un fichier qu'il contrôle, mais c'est le fichier d'origine, appartenant à root, qui est modifié.

Cette seule faille suffit à effacer le mot de passe root, à réécrire les données d'authentification ou à injecter du code malveillant dans un binaire setuid-root afin qu'il s'exécute en tant que root. Sur une installation par défaut de RHEL 10.2, Qualys y est parvenu en quelques secondes.

Un détail mérite qu’on s’y attarde, en particulier dans le cadre de la discussion en direct. RefluXFS a été découvert dans le cadre du projet Glasswing d’Anthropic : Qualys a orienté Claude Mythos Preview vers le noyau et lui a demandé de rechercher une faille de type « Dirty COW », puis ses propres chercheurs ont reproduit la découverte, vérifié chaque affirmation et procédé à la divulgation coordonnée. L’IA a accéléré la recherche ; les humains ont confirmé et divulgué la faille. Il faut y voir un aperçu de l’avenir de la recherche de failles dans le noyau, et non une exploitation « sur simple pression d’un bouton ».

Deux éléments pourraient toutefois vous inciter à classer ce problème à un niveau aussi bas. La première est la formulation utilisée dans la mise à jour initiale du fournisseur, qui a été livrée comme un simple correctif de « corruption des données XFS » et qui donne l’impression d’un simple problème d’intégrité des données. Il s’agit pourtant d’une primitive racine locale fiable. La seconde est reflink lui-même, qui semble être une option exotique que personne n’active. C’est pourtant la valeur par défaut de mkfs sur le système de fichiers racine de la famille RHEL depuis des années ; sur une machine standard, vous remplissez donc déjà cette condition sans même vous en rendre compte.

Les liens symboliques XFS permettent à deux fichiers de pointer vers les mêmes blocs physiques du disque sans dupliquer les données. Lorsqu’un fichier est modifié, XFS applique le principe de « copie à l’écriture » : il alloue un nouveau bloc pour le fichier modifié, copie les données, remappe ce fichier et diminue le compteur de références du bloc d’origine. Le fichier d’origine est censé rester inchangé.

Le RefluXFS, c'est ce qui se produit lorsque deux opérations d'écriture se chevauchent dans cette séquence.

[Attacker reflink-clones a readable root-owned file]
                     |
                     v
[Both files temporarily reference the same disk blocks]
                     |
                     v
[Two concurrent O_DIRECT writes race against the clone]
                     |
                     v
[XFS drops the inode lock to reserve transaction space]
                     |
                     v
[One path keeps using a stale physical block mapping]
                     |
                     v
[The write reaches the original protected file's disk block]
                     |
                     v
[Protected file changes with no normal write to its inode]

Le code vulnérable lit la branche de données du fichier sous le verrou de l’inode, puis libère ce verrou afin de réserver de l’espace pour le journal des transactions. Pendant cet intervalle, un deuxième écrivain peut terminer son propre cycle de « copie à l’écriture », remapper le clone vers un bloc vierge et réduire le compteur de références du bloc d’origine à un. Lorsque le premier utilisateur en écriture récupère le verrou, il vérifie à nouveau si le bloc est toujours partagé, mais il effectue cette vérification par rapport à l’adresse physique qu’il avait capturée avant que le verrou ne soit relâché. Cette adresse correspond à un mappage obsolète de la branche de données. Le système de fichiers XFS constate un compte de un, en conclut que le bloc est privé et y écrit, même si ce bloc n’appartient désormais qu’au fichier source protégé.

Comme O_DIRECT contourne le cache de pages, il n'y a pas de revalidation et l'écriture est effectuée sur le disque. Il s'agit d'une situation de concurrence entre le moment de la vérification et celui de l'utilisation, au cours d'un cycle de verrouillage d'inode. La vérification des droits d'accès n'a jamais été erronée. Le noyau a simplement agi sur une adresse de bloc qui n'était plus à jour.

Ce correctif oblige XFS à relire le mappage de la branche de données dès qu'il détecte que ce mappage a pu être modifié pendant que le verrou était libéré :

Before:
read mapping -> release lock -> mapping changes -> reuse stale mapping -> wrong file overwritten

After:
read mapping -> release lock -> mapping changes -> reread mapping -> write follows current mapping

L'analyse de Qualys identifie la perte de verrouillage dans la fonction xfs_reflink_allocate_cow(). Le commit de la branche principale, intitulé « xfs : rééchantillonner le mappage de la branche de données après le cycle ILOCK », fusionné le 16 juillet, rééchantillonne le mappage dans les fonctions d'aide CoW concernées. Il ne modifie ni le format sur disque ni la structure des données du noyau, ce qui s'avérera important par la suite pour l'application de correctifs sans redémarrage.

Le remplacement s'effectue au niveau des blocs et contourne le chemin d'écriture normal au niveau de l'inode du fichier protégé. Cela rend inopérants plusieurs signaux couramment utilisés pour la détection des modifications apportées aux fichiers :

• La cible conserve son propriétaire d'origine et son mode d'accès.
• Son bit setuid reste activé ; ainsi, un binaire setuid-root altéré continue de s'exécuter en tant que root.
• Il n'est pas nécessaire que ses horodatages reflètent cette modification.
• La surveillance des activités sur les fichiers basée sur les chemins d'accès peut ne pas enregistrer une opération d'écriture effectuée directement sur la cible protégée.
• Les données modifiées sont conservées sur le disque après un redémarrage.
• Qualys n'a détecté aucun avertissement ni aucune entrée de journal correspondante au niveau du noyau.

C'est pourquoi RefluXFS est plus grave qu'un simple bug temporaire de corruption de mémoire. Il s'agit d'une primitive de modification persistante sur le disque qui ne déclenche pas la plupart des signaux auxquels s'attendent les défenseurs. Un outil de vérification de l'intégrité des fichiers qui calcule un hachage du contenu des fichiers peut tout de même le détecter. Ce ne sera pas le cas des outils qui s'appuient sur les métadonnées, les enregistrements d'audit basés sur les chemins d'accès ou les avertissements du noyau.

Les trois conditions suivantes doivent toutes être remplies :

1. Le système utilise un noyau Linux vulnérable basé sur la version 4.11 ou une version ultérieure, sans le correctif.
2. Le système de fichiers XFS concerné a été créé avec la prise en charge de reflink.
3. Une cible accessible en lecture et un répertoire dans lequel l'attaquant peut écrire se trouvent sur ce même système de fichiers.

Vérifiez le système de fichiers racine, ainsi que chaque volume XFS monté sur lequel du code local non fiable peut s'exécuter, car un volume de données distinct peut être exposé même si le volume racine ne l'est pas :

xfs_info / | grep reflink=

Une sortie contenant « reflink=1 » indique que le prérequis du système de fichiers est présent.

Qualys répertorie RHEL, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux et CloudLinux 8, 9 et 10 parmi les distributions d'entreprise couramment concernées, ainsi que Fedora Server 31 et versions ultérieures, Amazon Linux 2023 et les AMI Amazon Linux 2 publiées à partir de décembre 2022.

Debian, Ubuntu, SLES, openSUSE et Fedora Workstation n'utilisent pas XFS pour le répertoire racine par défaut, et ne sont exposés que si un administrateur a choisi XFS avec la fonctionnalité reflink activée. Les systèmes de fichiers RHEL 7 sont antérieurs à la prise en charge de reflink par XFS et ne sont pas concernés par l'exposition par défaut décrite ici.

N’essayez pas de vous croire « en sécurité » en vous basant sur un raisonnement. La course ne se déclenche que lorsque le bloc cible est initialement non partagé, ce qui peut laisser croire qu’un fichier que vous avez déjà copié via reflink est à l’abri ; cependant, un utilisateur sans privilèges peut réinitialiser cet état, et il est peu probable que les binaires setuid-root aient été copiés via reflink au départ. Cette restriction apparente ne constitue pas une barrière de sécurité fiable.

Notre équipe chargée du noyau a reproduit la vulnérabilité sur les versions suivantes et a vérifié que les versions fournies par les éditeurs concernées contiennent le correctif :

Il s'agit de mises à jour ponctuelles spécifiques. La couverture dépend de la version de Stream ; veillez donc à consulter l'avis correspondant à votre version exacte plutôt que de vous baser sur une version proche.

Les configurations par défaut d'Enterprise Linux facilitent l'exploitation des failles

L'exigence d'un même système de fichiers peut sembler restrictive. Dans le cadre d'une installation d'entreprise classique, ce n'est pas le cas, car la configuration par défaut « single-root-XFS » regroupe tous ces éléments sur un seul volume :

• Fichiers exécutables appartenant à l'utilisateur root dans le répertoire /usr/bin
• Données d'authentification dans le répertoire /etc
• Le répertoire /tmp accessible en écriture par tous
• Répertoires personnels des utilisateurs sous /home

Cela confère à un utilisateur sans privilèges à la fois des cibles de grande valeur accessibles en lecture et un espace de travail accessible en écriture sur le même système de fichiers compatible avec reflink. Imaginez les environnements dans lesquels cela peut se produire : un hôte de compilation partagé, un moteur d’intégration continue (CI) exécutant la dernière demande de fusion poussée, un nœud multi-locataires où des charges de travail conteneurisées ou restreintes peuvent accéder à des chemins appropriés sur le même système de fichiers XFS de l’hôte, une machine de développeur exécutant des dépendances non fiables. Dans chacun de ces cas, un compte ordinaire suffit à l’exploit.

Il s'agit d'une élévation de privilèges au niveau de l'hôte local, et non d'une exécution de code à distance ni d'une évasion de l'espace invité vers l'hyperviseur. Un attaquant doit d'abord obtenir l'exécution de code local. Une fois qu'il y est parvenu, RefluXFS transforme ce point d'ancrage en accès root sur l'hôte.

Pourquoi les mesures courantes de renforcement de la sécurité sous Linux ne suffisent pas à l'empêcher

RefluXFS n'est pas une faille classique exploitant une corruption de la mémoire du noyau. Il détourne les opérations normales du système de fichiers pour diriger une écriture vers un bloc physique erroné, ce qui explique pourquoi de nombreux mécanismes de défense courants ne le détectent pas :

• SELinux : Qualys a réussi à reproduire l'exploitation avec SELinux en mode « Enforcing ».
• KASLR, SMEP et SMAP : ces mécanismes protègent contre les corruptions de mémoire, et non contre l'allocation de blocs du système de fichiers ; ils ne s'activent donc jamais.
• Verrouillage du noyau : il n'impose aucune restriction aux opérations RefLink ou d'E/S directes courantes pour les utilisateurs non privilégiés.
• Conteneurs et espaces de noms : ils ne bloquent pas automatiquement l'accès au chemin du système de fichiers vulnérable.
• Seccomp : les profils types autorisent les opérations courantes sur les fichiers auxquelles recourt l'attaque.
• Redémarrage sans mise à jour : le fichier corrompu subsiste, et le démarrage avec le même noyau vulnérable laisse la faille active.

Aucune fonctionnalité particulière n'est requise. Pas besoin de CAP_SYS_ADMIN, ni d'espace de noms privilégié, ni de matériel particulier, ni de configuration personnalisée du noyau. Les prérequis liés à XFS, reflink et au même système de fichiers restent valables, mais ils sont présents par défaut sur de nombreuses installations Linux d'entreprise concernées.

Il n'existe pas de solution de contournement sans risque au niveau de la configuration, mais Red Hat a publié une mesure d'atténuation temporaire à appliquer lors de l'exécution.

L'option `reflink` est sélectionnée lors de la création du système de fichiers XFS. Il n'existe aucune option de montage ni aucun paramètre sysctl permettant de convertir un système de fichiers existant configuré avec `reflink=1` en un système sans `reflink`, et la recréation du système de fichiers ne constitue pas une solution d'urgence pour un environnement de production. La suppression des bits setuid de `su`, `sudo` ou `pkexec` perturbe le fonctionnement normal et ne constitue pas une solution ciblée.

L'équipe de sécurité des produits Red Hat a publié une mesure de protection provisoire pour SystemTap qui intercepte le point d'entrée XFS de reflink et force les opérations reflink à renvoyer une erreur d'opération non prise en charge. Une approche similaire est possible avec les kprobes. Cela bloque le chemin reflink vulnérable, mais modifie le comportement du système de fichiers et peut affecter les applications qui s'appuient sur le clonage reflink ; il convient donc de le valider au préalable dans un environnement de test. Considérez cette mesure comme une protection temporaire pour les systèmes qui ne peuvent pas être corrigés immédiatement, et non comme un substitut à un noyau corrigé.

La véritable solution consiste à utiliser un noyau corrigé, que l'on redémarre le système ou non.

L'installation d'un paquet du noyau ne modifie pas le noyau déjà en cours d'exécution en mémoire. Pour une mise à jour classique proposée par le fournisseur : installez la mise à jour du noyau correspondant exactement à votre version, redémarrez, puis vérifiez que le système a bien démarré avec ce noyau.

uname -r

Pour les branches spécifiques mentionnées ci-dessus, les versions stables testées sont les suivantes : 4.18.0-553.144.1.el8_10, 5.14.0-687.26.1.el9_8 et 6.12.0-211.34.1.el10_2. Vérifiez que le noyau que vous utilisez correspond bien à celui indiqué dans l'avis de sécurité correspondant à votre distribution, votre branche et votre architecture.

Il y a deux pièges à éviter. Ne vous fiez pas au paquet le plus récent présent sur le disque ; fiez-vous plutôt au noyau en cours d’exécution. Et ne partez pas du principe que tous les noyaux compilés après le 16 juillet intègrent le correctif, car les numéros de version des distributions ne correspondent pas aux versions en amont et certaines branches l’ont rétroporté plus tôt. Vérifiez auprès de l’avis de sécurité du fournisseur pour la branche concernée. Étant donné que certains fournisseurs ont fourni le correctif avant la publication du CVE, les scanners basés sur les identifiants CVE peuvent ne pas refléter entièrement l’historique des correctifs.

Patching sans redémarrage

RefluXFS se prête bien à l'application de correctifs sans redémarrage. Ce correctif consiste en une modification ciblée de la manière dont le code XFS actualise le mappage des blocs après avoir libéré le verrou de l'inode, sans modification du format sur le disque ni remplacement des structures de données du noyau à l'échelle du système.

L'avis public de Qualys recommande d'installer un noyau corrigé et de redémarrer le système, et souligne à juste titre que la fonctionnalité « reflink » ne peut pas être désactivée sur un système de fichiers actif existant.

KernelCare adopte une approche différente pour remédier au problème : il applique la correction du code XFS sous-jacent directement au noyau en cours d'exécution, plutôt que de tenter de désactiver reflink ou de modifier la configuration du système de fichiers.

Le chemin CoW vulnérable rééchantillonne ensuite le mappage de la bifurcation de données après le cycle de verrouillage, sans fenêtre de maintenance ni redémarrage de la charge de travail. Il s'agit d'un bogue affectant uniquement le noyau, sans composant de bibliothèque de l'espace utilisateur à rechercher.

Les utilisateurs de KernelCare ont généralement configuré les correctifs de manière à ce que toutes les nouvelles corrections soient déployées automatiquement, en arrière-plan, à des intervalles précis – toutes les 4 heures, par exemple. Cependant, les utilisateurs peuvent également appliquer n'importe quel correctif issu du flux de production dès qu'il est mis à disposition :

kcarectl --update

Vérifiez la correspondance CVE plutôt que de vous fier à la date de compilation, car un noyau compilé après la mi-juillet ne intègre pas automatiquement ce correctif :

kcarectl --patch-info | grep 'CVE-2026-64600'

Lorsqu'un correctif est encore en cours de promotion via le flux de test de votre famille de noyaux, vérifiez qu'il est bien disponible avant de compter sur une couverture sans redémarrage, et redémarrez entre-temps avec le noyau du fournisseur corrigé.

Procurez-vous KernelCare dès aujourd’hui →

Détection et analyse des incidents

Il n'existe pas d'indicateur RefluXFS fiable en soi ; considérez donc chacun des éléments suivants comme un indice et non comme une preuve.

La vérification sur disque la plus efficace exploite justement le point faible du bogue : le contenu a changé, mais pas les métadonnées. La vérification des paquets calcule un hachage du contenu des fichiers ; elle se déclenche donc même lorsque les champs « mtime » et « mode » semblent corrects. Commencez par vérifier les paquets sensibles en matière de sécurité :

rpm -V shadow-utils sudo util-linux polkit

Un « 5 » dans la chaîne de résultat de vérification indique une non-concordance de l'hachage. Sur un binaire setuid-root ou un fichier de configuration principal, en l’absence d’horodatage T ou de changement de mode M correspondant, cela correspond au type de modification que RefluXFS peut laisser. Sur les systèmes de la famille Debian, la commande `debsums -c` remplit le même rôle. La vérification des paquets ne couvre pas tous les fichiers de configuration modifiables importants ; il convient donc de la compléter par des sauvegardes fiables, des enregistrements de gestion de la configuration et des hachages de fichiers dont la validité est confirmée.

Concentrez-vous sur les cibles à forte valeur ajoutée :

/etc/passwd   /etc/shadow   /etc/sudoers
/usr/bin/su   /usr/bin/sudo   /usr/bin/passwd   /usr/bin/pkexec

Recherchez ensuite les indices comportementaux : comptes privilégiés inattendus ou sans mot de passe, modification des champs du compte root, programmes setuid dont le contenu ne correspond plus au paquet installé, clés SSH inexpliquées, acquisitions de privilèges sans événement sudo, connexion ou authentification correspondant, pics d'E/S directes simultanées provenant d'un processus non privilégié, et clonage via reflink de fichiers protégés vers des emplacements accessibles en écriture par l'utilisateur.

Un horodatage normal ou un mode d'autorisation inchangé ne signifie pas qu'un fichier a été effacé. Si un code non fiable s'est exécuté sur un hôte vulnérable pendant la fenêtre d'exposition, considérez cela comme une atteinte potentielle à l'intégrité et examinez de plus près les comptes, la configuration d'authentification et les services, plutôt que de considérer un journal du noyau inerte comme une preuve de sécurité.

Pourquoi RefluXFS est-il si important ?

On a tendance à sous-estimer RefluXFS, car trois de ses caractéristiques peuvent sembler restrictives. Il s'agit d'un système local, et non distant. Il nécessite XFS. Il nécessite des reflinks.

Sous Linux d'entreprise, ces trois éléments décrivent l'environnement par défaut, et les machines qui correspondent sont précisément celles qui exécutent le code d'autres utilisateurs : locataires, pipelines de compilation, conteneurs, plugins, services compromis.

Cette faille franchit également la barrière de sécurité d'une manière inhabituelle. Pas d'écriture directe dans le fichier protégé, pas de SELinux à contourner, pas de charge utile dans la mémoire du noyau. Le noyau se contente d'écrire des données valides, contrôlées par l'attaquant, dans le mauvais bloc de disque, et le résultat est persistant, dispose des privilèges root et passe inaperçu.

Il y a là aussi une leçon à tirer en matière de processus, et c’est celle qu’il faut appliquer à votre file d’attente de triage. Pour de nombreux administrateurs, le premier signal publiquement exploitable a peut-être été une simple mise à jour du noyau fournie par un fournisseur avant la divulgation du CVE et décrite comme un correctif de corruption de données XFS. C’est le schéma classique « correction d’abord, CVE ensuite », et une file d’attente basée uniquement sur les errata de sécurité aurait classé une LPE locale avec privilèges root comme une opération de maintenance de routine. Surveillez les avis de correction de bogues du noyau, et pas seulement ceux signalés comme liés à la sécurité.

Pour les systèmes mis à jour de manière classique, installez la mise à jour du fournisseur et vérifiez que la machine démarre bien avec celle-ci. Pour les parcs informatiques où les redémarrages d’urgence constituent un risque opérationnel, un correctif sans redémarrage de KernelCare corrige la vulnérabilité du système de fichiers XFS dans le noyau en cours d’exécution, sans mettre les nœuds hors service ni interrompre les charges de travail.

Procurez-vous KernelCare dès aujourd’hui →

Chronologie

Références

• Qualys, « RefluXFS : une faille de sécurité dans le noyau Linux permettant l'élévation des privilèges à root sous XFS (CVE-2026-64600) », 22 juillet 2026 : https://blog.qualys.com/vulnerabilities-threat-research/2026/07/22/refluxfs-a-linux-kernel-local-privilege-escalation-to-root-in-xfs-cve-2026-64600
• Avis technique de Qualys, « RefluXFS : élévation de privilèges locaux via une condition de concurrence dans les E/S directes reflink de XFS », oss-security 2026/q3, 22 juillet 2026
• Mesure d'atténuation provisoire de Red Hat Product Security concernant SystemTap, liste de diffusion oss-security (fil de discussion sur CVE-2026-64600)
• Page CVE de Red Hat, CVE-2026-64600 : https://access.redhat.com/security/cve/cve-2026-64600
• Errata de sécurité Red Hat RHSA-2026:39179 et RHSA-2026:39180 (RHEL 8), RHSA-2026:39494 (RHEL 10)
• Correction en amont, « xfs : rééchantillonner le mappage de la branche de données après un cycle ILOCK » (commit 2f4acd0), intégrée le 16 juillet 2026
• Commit 3c68d44a2b49 à l'origine d'un bug, « xfs : allocation de blocs COW d'E/S directe dans iomap_begin » (Linux 4.11)
• The Hacker News, « Une faille RefluXFS sur Linux, vieille de neuf ans, permet aux utilisateurs locaux d'obtenir les droits root sur les installations RHEL par défaut » : https://thehackernews.com/2026/07/nine-year-old-refluxfs-linux-flaw-gives.html
• Avis de sécurité concernant les distributions AlmaLinux, Rocky Linux, Oracle Linux, Fedora et Amazon Linux