oss-security - RefluXFS: LPE in the Linux kernel via XFS reflink race<br>(CVE-2026-64600)
Products
Openwall GNU/*/Linux server OS<br>Linux Kernel Runtime Guard<br>John the Ripper password cracker
Free & Open Source for any platform<br>in the cloud<br>Pro for Linux<br>Pro for macOS
Wordlists for password cracking<br>passwdqc policy enforcement
Free & Open Source for Unix<br>Pro for Windows (Active Directory)
yescrypt KDF & password hashing<br>yespower Proof-of-Work (PoW)<br>crypt_blowfish password hashing<br>phpass ditto in PHP<br>tcb better password shadowing<br>Pluggable Authentication Modules<br>scanlogd port scan detector<br>popa3d tiny POP3 daemon<br>blists web interface to mailing lists<br>msulogin single user mode login<br>php_mt_seed mt_rand() cracker
Services<br>Publications
Articles<br>Presentations
Resources
Mailing lists<br>Community wiki<br>Source code repositories (GitHub)<br>File archive & mirrors<br>How to verify digital signatures<br>OVE IDs
What's new
Follow @Openwall on Twitter for new release announcements and other news
[ [day] [month] [year] [list]
Message-ID:<br>Date: Wed, 22 Jul 2026 16:27:40 +0000<br>From: Qualys Security Advisory<br>To: "oss-security@...ts.openwall.com"<br>CC: "Darrick J. Wong"<br>Subject: RefluXFS: LPE in the Linux kernel via XFS reflink race<br>(CVE-2026-64600)
Qualys Security Advisory
RefluXFS: Local Privilege Escalation via XFS reflink direct-I/O race<br>(CVE-2026-64600)
Contents
Foreword<br>Summary<br>Am I affected?<br>Background: XFS, reflink, and copy-on-write<br>Analysis<br>Exploitation<br>Acknowledgments<br>Timeline
Foreword
A few weeks ago, Anthropic gave us access to Claude Mythos Preview. As<br>an experiment, we pointed it at the Linux kernel and asked it to find a<br>vulnerability similar to Dirty COW. The initial passes came up empty, so<br>we refined our prompts: we first narrowed the scope to race conditions,<br>next to the core mm/ and fs/ directories, and last to the filesystems in<br>the fs/*/ directories. After several iterations, the model discovered a<br>race condition in the XFS filesystem, wrote a proof of concept (an LPE<br>to full root), which we then reviewed and successfully tested on the<br>default installation of a Fedora Server 44. Finally, we asked the model<br>to draft a "Qualys Security Advisory" for this vulnerability, validated<br>it ourselves, and what follows is the result of this entire experiment.
Summary
We discovered a race condition in the Linux kernel's XFS filesystem<br>that allows an unprivileged local user to overwrite the on-disk<br>contents of any file they can read, on any XFS filesystem created<br>with reflink support (which has been the mkfs.xfs default since<br>2019). We named it RefluXFS: the write refluxes -- flows backward --<br>from the attacker's own copy into the original file.
The attacker reflink-clones a target file (for example /etc/passwd,<br>or a SUID-root binary such as /usr/bin/su) into a scratch file they<br>own, then races concurrent O_DIRECT writes on that scratch file. A<br>lock-drop window in the kernel's copy-on-write allocation path lets<br>one of those writes land, not in the attacker's own storage, but in<br>the physical block that still backs the original file. The change is<br>made directly on disk, persists across reboot, produces no kernel log<br>output, and does not touch the target file's inode -- so a modified<br>SUID-root binary keeps its SUID bit.
To the best of our knowledge, this vulnerability was introduced in<br>February 2017 (Linux 4.11) by commit 3c68d44a2b49 ("xfs: allocate<br>direct I/O COW blocks in iomap_begin"), and is present in every<br>mainline and stable kernel since. It requires no capability, module,<br>sysctl, or non-default configuration.
Last-minute note: on Thursday, July 16, 2026, the patch for this<br>vulnerability was merged into the Linux kernel source tree (commit<br>2f4acd0, "xfs: resample the data fork mapping after cycling ILOCK").
Am I affected?
You are affected if, and only if, all three of these are true:
1. Your kernel is v4.11 or later (April 2017) and does not carry<br>the fix. Practically every currently-supported Linux kernel.
2. You have an XFS filesystem with reflink=1 in its superblock.
3. That XFS filesystem holds both a file worth attacking (a root-<br>owned configuration file or SUID-root binary) and a directory an<br>unprivileged local user can write to.
Condition 3 is met by every default single-volume install: /var/tmp<br>is world-writable and lives on the root filesystem alongside /etc and<br>/usr/bin.
To check condition 2 on your root filesystem:
$ xfs_info / | grep reflink=<br>= reflink=1 bigtime=1 inobtcount=1 nrext64=1
If that prints "reflink=1", you are exposed. If it prints<br>"reflink=0", or if xfs_info fails because / is not XFS, you are not<br>exposed via the root filesystem -- repeat the check for any other<br>mounted XFS.
Reflink has been the mkfs.xfs default since xfsprogs 5.1.0 (July<br>2019), and Red Hat backported that default into xfsprogs 4.17.0-2.el8<br>for RHEL 8.0 GA (May 2019) ahead of upstream. It is a superblock<br>feature fixed at mkfs time; there is no mount option or sysctl to<br>turn it off...