Qualys’ Threat Research Unit disclosed CVE-2026-64600 — nicknamed RefluXFS — on July 22, a race condition in the Linux kernel’s XFS filesystem that lets an ordinary local user overwrite root-owned files and take full control of the host. The bug has been sitting in mainline since kernel 4.11 shipped in April 2017, meaning it has been exploitable on every default RHEL, Oracle Linux, Amazon Linux, and Fedora Server install for close to a decade. Qualys estimates it affects more than 16.4 million systems worldwide. A patch merged upstream on July 16, six days ahead of public disclosure, and vendor kernels are shipping now — but there is no workaround for anyone who can’t reboot immediately.

What’s Broken

XFS supports reflinks — copy-on-write clones of a file that share underlying disk blocks until one copy is modified. When a process writes to a reflinked file, XFS is supposed to allocate a new private block and remap the file before the write lands, so the original shared data stays untouched.

RefluXFS is a timing flaw in that remap path. Two concurrent O_DIRECT writes targeting the same reflinked file can race: the kernel briefly drops its inode lock while it waits for transaction log space during the copy-on-write allocation, and a second writer can slip into that window, remap the file itself, and drop the reference count out from under the first writer. The end result is a write primitive that lands data in a file the attacker does not own and cannot normally write to — including, with the right target, a root-owned or setuid file, or any privileged file an attacker can merely read.

Because the writes go through O_DIRECT, they bypass the page cache entirely and hit disk directly, leaving nothing in the kernel’s normal write-tracking paths for host-based monitoring to catch. There’s no unusual syscall sequence, no crash, no log entry — just a corrupted target file that the exploit script controls the contents of.

Qualys’ write-up (with an AI-assisted PoC later verified by their engineers) demonstrates a reliable exploit chain: race two O_DIRECT writers against a reflinked copy of a file the target process trusts, win the window, and use the write primitive to plant a root shell or defeat a privilege check. From an unprivileged shell to root takes seconds and is deterministic enough to script.

Impact

Affected: any Linux kernel from 4.11 onward — which is to say essentially every currently supported enterprise distribution. Confirmed affected platforms include RHEL 8 and 9, Oracle Linux, Amazon Linux 2023, Rocky Linux, AlmaLinux, CentOS Stream, and Fedora Server, wherever the root filesystem or a data volume sits on XFS — the default filesystem for RHEL and its downstreams since RHEL 7.

The severity here isn’t the CVSS score for a random workstation — it’s the sheer footprint. XFS-on-RHEL-family is the default storage stack for a huge share of enterprise Linux, cloud VM images, and CI/CD build runners. Qualys and Red Hat both note that SELinux in Enforcing mode does not stop this — the race happens below the LSM hook layer, at the filesystem block-allocation layer, so mandatory access control, container namespace boundaries, and standard hardening profiles all fail to intervene. Red Hat’s advisory (accessible via the Customer Portal) confirms exploitability on default RHEL 8+ installs with no special configuration required beyond having XFS as the backing filesystem.

The container angle matters as much as the bare-metal one: a compromised or malicious workload running inside a container that shares the host’s XFS-backed kernel can use this as a second-stage primitive after an initial foothold — a compromised CI job, a vulnerable web app, or a restricted shell from an unrelated bug — to break out to full host root. There is no container runtime mitigation for a bug this low in the storage stack; the isolation boundary that matters here is the kernel version, not the container boundary.

Mitigation

There is no practical workaround. Reflinks cannot be disabled on an existing XFS filesystem after creation, there’s no sysctl or mount option that closes the race, and restricting O_DIRECT access is not a supported or reliable mitigation — Qualys states plainly that no configuration change meaningfully reduces exposure.

  1. Patch and reboot. This is the only fix. Vendor kernel updates are live or landing now:
    • Red Hat: tracked at access.redhat.com/solutions/7145752 — apply the RHSA for your RHEL 8/9 stream.
    • CloudLinux: a KernelCare live patch is available for supported CloudLinux versions, avoiding a reboot — see CloudLinux’s release status tracker.
    • Amazon Linux 2023, Oracle Linux, Rocky, AlmaLinux, Fedora: check vendor advisories for the equivalent kernel errata; most were shipping within 24-48 hours of disclosure.
  2. Prioritize multi-tenant and shared-kernel hosts first — any box where untrusted or lower-trust code runs alongside privileged processes: shared CI runners, multi-tenant Kubernetes nodes, shell-access jump boxes, and any XFS-backed VM image used as a golden image for autoscaling fleets.
  3. Rebuild golden images and AMIs rather than patching in place where you manage fleets via immutable infrastructure — drain and replace nodes once your cloud provider’s patched image is available.
  4. Don’t rely on detection as a stopgap. Because the write bypasses the page cache and leaves no anomalous syscall footprint, EDR and file-integrity monitoring are unlikely to catch exploitation in progress. Treat this as a patch-now, not a monitor-and-patch-later, issue.

References