Mitigating RefluXFS (XFS Reflink Direct-I/O Race, CVE-2026-64600) on Rocky Linux 8, 9, 10, and LTS Variants
Introduction
RefluXFS, tracked as CVE-2026-64600, is a local privilege escalation (LPE) vulnerability in the Linux kernel's XFS filesystem. A race condition in the copy-on-write (CoW) direct-I/O allocation path lets an unprivileged local user overwrite the on-disk contents of any file they can read, on any XFS filesystem created with reflink support. Because reflink has been the mkfs.xfs default since 2019, this covers the default single-volume install of Rocky Linux 8, 9, and 10 and the CIQ variants built on them.
The upstream fix was merged to the mainline Linux kernel on 2026-07-14, and CIQ has released patched kernels across all affected products. This article covers what is affected, how to check exposure, the interim risk-reduction steps for hosts you cannot reboot immediately, and the patched kernel versions per variant.
The flaw was introduced in Linux 4.11 (February 2017, upstream commit 3c68d44a2b49, "xfs: allocate direct I/O COW blocks in iomap_begin") and is present in every mainline and stable kernel since, until the fix. It requires no capability, kernel module, sysctl, or non-default configuration.
Problem
When a program issues an O_DIRECT write to a reflinked (shared) block, XFS decides whether the block needs a copy-on-write or can be written in place. That decision path drops the inode lock to allocate a transaction, then re-checks whether the block is still shared before writing. The re-check consults the on-disk reference-count btree at the physical block number captured before the lock was dropped, and never re-reads the file's data fork. A second concurrent writer can complete a full CoW cycle inside that window, remapping the file to a new block and dropping the original block's refcount. The first writer then sees "not shared," and its write is submitted in place, to a physical block that no longer belongs to the attacker's file. That block still backs the original target (for example /etc/passwd or a SUID root binary).
The result: the change is written directly to disk, persists across reboot, produces no kernel log output, and never touches the target file's inode, so a modified SUID root binary keeps its SUID bit.
Treat the following systems as affected unless they are running a patched kernel (see Patched Kernels below) and their XFS filesystems are confirmed not to use reflink:
- Rocky Linux 8, 9, and 10 community releases
- RLC Pro LTS variants (8.6, 9.2, 9.6, and related)
- RLC Pro FIPS variants
- RLC Pro variants based on Rocky Linux 8, 9, or 10, including RLC Pro Hardened
- CIQ SIG/Cloud Next and CIQ Linux Kernel LT variants
RefluXFS requires local code execution. It is not a remote unauthenticated vulnerability on its own. However, any system with local shell users, shared application accounts, CI runners, or workloads that let an attacker run code should be treated as exposed until patched.
Am I Affected?
Three conditions must all be true for a system to be exploitable:
- The kernel is 4.11 or later and does not carry the fix. This is effectively every kernel released before 2026-07-14.
- There is an XFS filesystem with
reflink=1in its superblock. - That filesystem holds both a file worth attacking (a root-owned config file or SUID root binary) and a directory an unprivileged user can write to. This is met by every default single-volume install, since
/var/tmpis world-writable and shares the root filesystem with/etcand/usr/bin.
Check condition 2 on your root filesystem:
xfs_info / | grep reflink=
If the output contains reflink=1, the filesystem is exposed. If it shows reflink=0, or xfs_info fails because / is not XFS, the root filesystem is not exposed through this path. Repeat the check for any other mounted XFS filesystem, for example:
xfs_info /home | grep reflink=
Reflink is a superblock feature fixed at mkfs time. There is no mount option or sysctl to turn it off on an existing filesystem, so the xfs_info result cannot be changed without recreating the filesystem. This is why the patched kernel, not a configuration change, is the fix.
CIQ Bridge and CentOS 7.9 systems are not affected in any configuration. The 3.10 kernel predates XFS reflink support entirely, and the shipped xfsprogs (4.5.0) has no reflink option. An in-place CIQ Bridge to Rocky Linux 8 migration that preserves the on-disk superblock is likewise not exploitable; only a fresh Rocky Linux 8-or-later install creates a reflink=1 filesystem.
Status
- A patched kernel is the fix, and patched kernels are now available. CIQ has released patched kernels for all affected CIQ variants. See the Patched Kernels table below. For community Rocky Linux, the fix ships through the Rocky Linux errata (errata.rockylinux.org).
- Recommended action: update to the patched kernel and reboot. Run
sudo dnf update kernel*and reboot. See Resolution for variant-specific steps. - CIQ lab testing confirmed the fix closes the race. A proof-of-concept that wins the race in seconds on an unpatched kernel fails to win within its full budget on the patched kernel.
- There is no reliable runtime mitigation. XFS reflink cannot be disabled on an existing filesystem, so a host cannot be de-risked without either the patched kernel or recreating the filesystem. Until you can reboot into the patched kernel, use the interim measures in the Mitigation section to reduce exposure.
- CIQ Bridge 7.9 and CentOS 7.9 systems are not affected.
- Open a support case if you need help confirming exposure on a specific host or the exact patched kernel version for a specific CIQ variant.
Patched Kernels
Patched kernels were released on 2026-07-18. Update to the version listed for your variant (or newer) and reboot. For the LTS and FIPS variants, the fix ships in the current kernel build in your repository, so dnf update kernel* pulls it.
| Variant | Patched Kernel Version | Repo | Released |
|---|---|---|---|
| RLC Pro LTS 8.6 | 4.18.0-372.32.1+33.1.el8_6_ciq |
rlc-8.6-lts.x86_64 | 2026-07-18 |
| RLC Pro LTS 9.2 | 5.14.0-284.30.1+36.1.el9_2_ciq |
rlc-9.2-lts.x86_64 | 2026-07-18 |
| RLC Pro LTS 9.6 | 5.14.0-570.60.1+19.1.el9_6_ciq |
rlc-9.6-lts.x86_64 | 2026-07-18 |
| RLC Pro FIPS 9.6 | 5.14.0-570.60.1+19.1.el9_6_ciq (same kernel as LTS 9.6) |
rlc-9.6-lts.x86_64 | 2026-07-18 |
| RLC Pro 8 / FIPS 8.10 | 4.18.0-553.144.1+2.1.el8_10_ciq |
rlc-pro-8.x86_64 | 2026-07-18 |
| RLC Pro 8.6 / FIPS 8.6 | 4.18.0-553.144.1+2.1.el8_6_ciq |
rocky-8.6-baseos.x86_64 | 2026-07-18 |
| RLC Pro 9 | 5.14.0-687.26.1+2.1.el9_8_ciq |
rlc-pro-9.x86_64 | 2026-07-18 |
| RLC Pro 10 | 6.12.0-211.34.1+2.1.el10_2_ciq |
rlc-pro-10.x86_64 | 2026-07-18 |
| CIQ Linux Kernel LT 6.12 | clk6.12-6.12.96-1.1.el9_clk |
clk-6.12-el9.x86_64 | 2026-07-18 |
| CIQ Linux Kernel 6.18 | clk6.18-6.18.39-1.1.el9_clk |
clk-6.18-el9.x86_64 | 2026-07-18 |
For Rocky Linux community edition updates, refer to the Rocky Linux errata at errata.rockylinux.org.
Confirm what is running on a given system with:
uname -r
If your system reports the patched version for your variant (or newer), the fix is in place. Otherwise, update and reboot as described in Resolution.
Mitigation
There is no clean runtime mitigation. XFS reflink is a superblock feature set at filesystem creation and cannot be disabled on a live filesystem, and the direct-I/O write path the exploit uses has no toggle. Now that patched kernels are available, the fix is to update and reboot. The measures below only apply as interim risk reduction on a host you cannot reboot immediately; they reduce exposure rather than remove it.
Limit untrusted local code execution (primary interim control)
RefluXFS requires an attacker to run code as a local unprivileged user on a host with an affected XFS filesystem. Until the host is on the patched kernel, treat local access as the exposure boundary:
- Restrict shell and login access on affected hosts to trusted operators.
- Isolate CI runners, batch/HPC job nodes, and shared multi-tenant systems that execute untrusted or user-submitted code. Prioritize those hosts for the patched kernel.
- Review shared application accounts that untrusted users can reach.
Filesystem layout (new builds only)
For systems being provisioned now, placing world-writable scratch space (for example /tmp and /var/tmp) on a filesystem that does not share storage with sensitive targets removes condition 3 on that path. A tmpfs-backed /tmp, or a separate non-reflink XFS or other filesystem, breaks the specific /var/tmp-to-/etc exploitation route. This does not fully protect a system: an attacker with any writable directory on the same reflink XFS as a target can still exploit the race. Treat it as defense in depth on new builds, not as a substitute for the patched kernel.
⚠️ WARNING Changing filesystem layout or recreating an XFS filesystem without reflink is a destructive, offline operation that requires a full backup and a maintenance window. Do not attempt it on a production system as a mitigation. Install the patched kernel instead.
What is not a mitigation
If a target file's first block already has a reflink reference count of 2 or more (for example because it was previously cloned), the race cannot fire against that block. This is incidental and unreliable. Do not treat pre-cloning sensitive files as a defense; it does not generalize across targets (SUID root binaries are unlikely to be pre-cloned) and provides no real protection.
Verification
RefluXFS leaves no kernel log output, no crash, and no change to the target file's inode metadata, so there is no reliable log-based indicator of exploitation. Verification is therefore focused on confirming the patched kernel is running rather than detecting past abuse.
After installing the patched kernel and rebooting, confirm the running kernel matches the patched version listed in the Patched Kernels table:
uname -r
If the running kernel is a patched version (or newer) for your variant, the fix is in place.
If you need to assess whether a specific host with sensitive data may have been targeted before patching, open a support case. Because the modification is written at the block layer and does not update inode metadata, standard file-integrity tooling that reads through the page cache may not detect it until the cache is dropped; CIQ can advise on validating a specific system.
Resolution
The fix is the patched kernel.
RLC Pro LTS and FIPS variants
The patched kernel is available directly from the long-term support repository. No additional repository configuration is required:
sudo dnf update kernel*
sudo reboot
RLC Pro 8, 9, 10 and CIQ SIG/Cloud Next
Refresh DNF metadata and install from the appropriate depot channel for your variant:
sudo dnf clean all
sudo dnf update kernel*
sudo reboot
CIQ Linux Kernel (CLK) variants
For the CIQ Linux Kernel LT 6.12 and 6.18 variants, update the kernel-clk* packages and reboot:
sudo dnf update kernel-clk*
sudo reboot
Community editions
For Rocky Linux 8, 9, and 10 community editions, the patched kernel is delivered through the standard BaseOS repository. Refer to the Rocky Linux errata at errata.rockylinux.org for the advisory and fixed version, then update and reboot:
sudo dnf update kernel*
sudo reboot
After rebooting, confirm the running kernel with uname -r as described in Verification. If you applied the new-build filesystem-layout measures as defense in depth, they remain safe to keep in place after patching; nothing needs to be reverted.
Notes
- Exploitation is fast and quiet, and speed varies by release. On an unpatched kernel a public proof-of-concept wins the race in seconds. On Rocky Linux 9 and 10 the win is near-instant (often a few hundred attempts). On Rocky Linux 8 and LTS 8.6 it can take noticeably longer and more attempts, but it still succeeds. Either way there is no crash, no
dmesgentry, and the target file's mode, owner, and mtime are unchanged, so do not rely on log review to gauge exposure. - Reflink is the default, so most Rocky Linux installs are exposed.
mkfs.xfshas enabled reflink by default since 2019, so the majority of default single-volume Rocky Linux 8, 9, and 10 installs meet the filesystem condition. Use thexfs_infocheck above to confirm per host rather than assuming. - CIQ Bridge and CentOS 7.9 are not affected because their 3.10 kernel and
xfsprogspredate XFS reflink support. - The patched kernel is the durable fix. The interim measures reduce exposure by limiting who can run local code; they do not close the vulnerability.